---
title: "Leistungsbeschreibung yuuconnect SIP Trunk, yuuconnect für MS Teams, yuuconnect für Genesys Cloud CX, yuuconnect für Twilio BYOC, yuuconnect FQDN"
canonical: "https://dokucenter.yuutel.at/space/Dokucenter/2238492545/Leistungsbeschreibung%20yuuconnect%20SIP%20Trunk%2C%20yuuconnect%20f%C3%BCr%20MS%20Teams%2C%20yuuconnect%20f%C3%BCr%20Genesys%20Cloud%20CX%2C%20yuuconnect%20f%C3%BCr%20Twilio%20BYOC%2C%20yuuconnect%20FQDN"
format: markdown
---
###### Christian Rupitsch / Roland Kahlhofer / Markus Scherer, Version 7.2, 27.08.2026

  
  


# Einleitung

Der  Trunk stellt die IP-basierte Verbindung zwischen einer Vermittlungslogik (PBX, Microsoft Teams, Genesys Cloud CX, Twilio und FQDN) auf Kundenseite und dem öffentlichen Telefonnetz (PSTN) her. Der  Trunk ist in vier verschiedenen Ausprägungen verfügbar:

- SIP Trunk zur Verbindung von SIP-fähigen Nebenstellenanlagen mit dem PSTN
- für Microsoft Teams zur Verbindung von Microsoft Teams mit dem PSTN
- <span style="color: #ff285a">*** ***</span>für Genesys zur Verbindung von Genesys Cloud CX mit dem PSTN
- yuuConnect<span style="color: #ff285a">*** ***</span>für Twilio BYOC mit dem PSTN
- yuuconnect FQDN für statische Anbindungen von bspw. Kundendomains/IP Adressen

Die yuutel GmbH konfiguriert ausschließlich den erwünschten Trunk in der <span style="color: #003366">yuutel</span> Cloud (SBC<=>PSTN). Der Kunde hat den Nachweis eines bestehenden [Netzabschlusspunkts](https://yuutel.atlassian.net/wiki/spaces/Dokucenter/pages/2239562097) zu erbringen. Der Nachweis kann mittels bestehender Internetanbindung mit einer statischen IP-Adresse erfolgen. Alternativ kann bei yuutel ein VoIP-Anschlussbezogen werden. Der Kunde erhält im Zuge der Einrichtung die Parameter zur Anschaltung an den Session Border Controller (SBC) von <span style="color: #003366">yuutel</span>. Nachfolgend werden die technischen Eigenschaften der Ausprägungen des  Trunks beschrieben. Die Ausprägungen  für Microsoft Teams und  für Genesys Cloud CX sowie  für Twilio BYOC sind in den jeweiligen Abschnitten erläutert.

# Basis und wichtigste Leistungsmerkmale zu  SIP Trunk,  für MS Teams,  für Genesys Cloud CX, für Twilio BYOC und FQDN

Die Basis der vier Ausprägungen ist der  SIP Trunk. Die wichtigsten Leistungsmerkmale sind:

- Anrufrouting
- Mehrere Rufnummernbereiche oder Einzelrufnummern auf einem SIP Trunk
- Mehrfachregistrierungen im Modus redundant oder lastverteilt (gilt nur für SIP Trunk)
- Konfigurierbare Einstellungen wie z.B. Rufnummernformate für ein- und ausgehende Gespräche
- Vordefinierte, erweiterbare Profile
- Sperrklassen / Rufprofile
- Fraud Detection

## Zielgruppe  SIP Trunk

Das Produkt richtet sich ausschließlich an Unternehmen.  SIP Trunk dient dazu, Unternehmen eine Möglichkeit zur Verfügung zu stellen, die ausgehenden Telefongespräche ins öffentliche Telefonnetz (PSTN), weltweit zu terminieren. Auch eingehende Anrufe aus dem PSTN kommend können über  zum Kunden zugeführt werden. Dabei stellt <span style="color: #003366">yuutel</span> Ihrem Unternehmen ein Cloud-Service mit den notwendigen Komponenten (SBC) zur Verfügung. Dieses ist üblicherweise von Ihrem SIP-Gateway (siehe Kapitel Sicherheit) via Internet zum <span style="color: #003366">yuutel </span>System erreichbar. Sie benötigen keinen Telefonanschluss, keine zusätzliche Hardware oder ähnliches. Ihr SIP-Gateway registriert sich (Standard RFC3261) am<span style="color: #ff285a">* *</span><span style="color: #003366">yuutel</span><span style="color: #003366">*** ***</span>System und übermittelt anschließend einzelne Outbound-Telefonate lt. Spezifikationsdokument. Die klassischen Telefonanlageneinstellungen liegen weiterhin in der Hoheit Ihres Unternehmens. (Bsp.: Halten, Makeln, Dreierkonferenz, etc.).  ist keine Carrier-Anbindung, sondern entspricht einer typischen Konfiguration eines Teilnehmeranschlusses.

## Zielgruppe  für Microsoft Teams

Wenn Ihr Unternehmen MS Teams bereits für die interne Zusammenarbeit und Kommunikation nutzt und die derzeitige Telefonielösung durch ausschließliche Verwendung von Teams ablösen möchten, können Sie  für Microsoft Teams als Verbindung zwischen Teams und dem öffentlichen Telefonnetz (PSTN) verwenden.  für Microsoft Teams wird durch eine einmalige Freischaltung als exklusiver Microsoft Teams Direct-Routing Trunk aktiviert.

### Benötigte Microsoft Lizenzen für MS Teams Direct Routing

Ihr Unternehmen benötigt für jeden Benutzer, der in das PSTN telefonieren können soll, eine Add-On Lizenz (MS Teams Phone Standard).

> ⚠️ Die Microsoft Lizenzen können **nicht **von der yuutel GmbH bezogen werden. Bitte wenden Sie sich an Microsoft oder an Ihren Microsoft Partner.

Die Konfiguration des Microsoft Teams Accounts erfolgt durch Ihren Administrator bzw. einen durch ihn beauftragten Microsoft Partner.

## Zielgruppe  für Genesys Cloud CX oder Twilio BYOC

Wenn Ihr Unternehmen die Callcenter-Lösung Genesys Cloud CX oder Twilio einsetzt, kann yuutel einen dazu passenden, vor konfigurierten SIP Trunk zum Einsatz bringen. Dabei sind ein,- und ausgehende Gespräche möglich.

## Zielgruppe für FQDN Trunk

Der Trunk mit statischem Routing auf IP Adressen oder Kundendomains richtet sich vornehmlich an Unternehmen die Ihre Inbound Calls auf statische Cloudsysteme mit bspw. FQDN adressieren wollen. Häufig unterstützen diese Systeme keine SIP Registrierungen. Outbound Calls sind mittels Authentifizierung möglich.

## Notrufe Allgemein

Notrufe werden den Notrufzentralen auf Basis der übermittelt Kopfnummer zugestellt. Notrufe werden im Netz von yuutel gesondert behandelt und gegenüber herkömmlichen Gesprächen bevorzugt. Ein Notruf wird nur dann als solcher behandelt, wenn keine Vorwahl vor den Notruf gestellt wird (Richtig: 112 oder 133). Wird ein Notruf dennoch mit Vorwahl gewählt, wird dieser an die Notrufzentrale zugestellt, die der Vorwahl zugeordnet ist.

> ⚠️ Der Kunde hat immer dann sicherzustellen, dass der vom Teilnehmer gewählten Notrufnummer die Vorwahl vorangestellt wird, sofern sich der Teilnehmer nicht an jenem Standort befindet (VPN) dem die Kopfnummer örtlich zugeordnet wird.

## Notrufe bei  für Microsoft Teams

Damit yuutel einen Notruf aus MS Teams jedenfalls korrekt routen kann, ist der gewählten Nummer (z.B. 112) die Ortsvorwahl dann voran zu setzen, wenn der Teilnehmer sich nicht an jenem Standort befindet, dem seine Netznummer zugeordnet ist.

> ⚠️ Die dafür notwendigen Konfigurationen in MS Teams ("Network Site" und "Emergency Call Routing") sind von Ihrem Unternehmen bzw. Ihrem Microsoft Partner durchzuführen und liegen in Ihrem Verantwortungsbereich.

Alternativ kann eine standortunabhängige Rufnummer (z.B. 0720 in Österreich) als Netznummer und somit als für Notrufe relevante Rufnummer für MS Teams verwendet werden. Eine allenfalls verwendete geografische Rufnummer kann dem Angerufenen mittels CLIP-no-screening angezeigt werden.

# Übersicht  SIP Trunk

## Allgemein

 wird zwischen Ihrem Unternehmen als Endkunde und <span style="color: #003366">yuutel</span> laut nachfolgender Spezifikation konfiguriert und kann nach erfolgreicher Registrierung unmittelbar genutzt werden. Die Richtung der Anrufe ist dabei als ausgehend von Ihrem Unternehmen in das öffentliche Telefonnetz (PSTN) definiert. Die Anzahl der technisch möglichen gleichzeitigen Telefonate wird von <span style="color: #003366">yuutel</span><span style="color: #ff285a"> </span>laut Auftrag vor konfiguriert und kann, falls notwendig, angepasst werden. Kundenindividuelle Konfigurationen sind mit Absprache möglich.

> ✅ Im [Dokument Cookbook](https://yuutel.atlassian.net/wiki/spaces/Dokucenter/pages/2238492632)  SIP Trunk finden Sie Beispiele und Anleitungen zur Inbetriebnahme.

## Übersicht über die wichtigsten Konfigurationsinformationen

- Es können maximal zwei gleichzeitige Registrierungen erfolgen (Load Balancing).
- Es werden q-Values bei der Registrierung unterstützt.
- Der AoR (Address of Record) hat das Format: 00ccndcsn@bt.siptel.at (cc= country code, ndc=national destination code, sn=subscriber number)
- Es werden nur Header im "Long Format" unterstützt.
- <span style="color: #003366">yuutel</span> spielt zu keiner Zeit eine Halte-Musik ein.
- Der höchst-priorisierte Sprachcodec ist G.711 A-Law.
- Outboundproxy wenn beim Kunden NAT verwendet wird: bt.siptel.at:5060
- Outboundproxy wenn beim Kunden KEIN NAT verwendet wird: bt.siptel.at:5084
- Outboundproxy bei Verwendung von Verschlüsselung bt.siptel.at:5061 (TLS)

## Firewall Freigaben

- IP-Adresse: <span style="color: #303330">193.84.65.0/24 und 91.237.65.0/24</span>
- <span style="color: #303330">SIP Signalisierung: 5060</span>
- <span style="color: #303330">SIPS (TLS) Signalisierung: 5061</span>
- <span style="color: #303330">(S)RTP: any Port</span>

# Allgemeine Sicherheit des Trunks

## Ausprägung bei  SIP Trunk

Die Call-Signalisierung **muss** mit Username und Passwort authentifiziert werden.  muss eine aktive Registrierung aufweisen, um ein abgehendes Gespräch durchführen zu können. Dies ist aufgrund der gesetzlichen Vorgaben zur Rückrufbarkeit verpflichtend!  

## Ausprägung mit Microsoft Teams

Hier ist keine Registrierung des Trunks erforderlich. Die Identifizierung erfolgt über die Customer Tenant Domain. Signalisierung und Sprache sind ausschließlich verschlüsselt.

## Ausprägung mit Genesys Cloud CX

Hier ist keine Registrierung des Trunks erforderlich. Die Identifizierung erfolgt über den eindeutigen FQDN von Genesys. Signalisierung und Sprache sind ausschließlich verschlüsselt.

## Ausprägung mit Twilio BYOC

Hier ist keine Registrierung des Trunks erforderlich. Die Identifizierung erfolgt über die eindeutige Twilio Account Sid. Signalisierung und Sprache sind ausschließlich verschlüsselt.

## Ausprägung mit FQDN

Hier ist keine Registrierung des Trunks erforderlich. Die Identifizierung erfolgt über den eindeutigen FQDN (oder IP Adresse) des Kunden. Signalisierung und Sprache sind optional verschlüsselt.

### Beispielregistrierung

> ℹ️ Hier finden Sie eine [Beispiel-Registrierung](https://dokucenter.yuutel.at/space/Dokucenter/2238492545/Leistungsbeschreibung+yuu+Connect+SIP+Trunk,+yuu+Connect+f%C3%BCr+MS+Teams+und+yuu+Connect+f%C3%BCr+Genesys+Cloud+CX#Registrierung).

## Sicherheit bei ausgehenden Gesprächen mit  SIP Trunk und  für Genesys Cloud CX

Um ausgehende Gespräche durchführen zu können, müssen folgende Bedingungen erfüllt sein:

- Der Trunk muss registriert sein. (Siehe Kapitel "Registrierung"). Dies gilt für  SIP.
- Jedes Gespräch muss authentifiziert werden. Dabei wird ebenfalls die Digest Authentication (MD5) mit QOP verwendet. Die Authentifizierung bezieht sich auf die Hauptnummer und ist, unabhängig von Durchwahlen, immer dieselbe.  
Nonce Count und Responses müssen mit dem verwendeten Nonce übereinstimmen. Bei jeder neuen Nonce muss der Nonce Count zurückgesetzt werden.
- Der Authentifizierungsbenutzer, mit welchem das Gespräch authentifiziert wird, muss mit dem Userpart im "From:" Feld übereinstimmen. Hierbei darf der Userpart im "From:" Feld länger als der Authentifizierungsbenutzer sein.  
Der Authentifizierungsbenutzer (und "From:" Userpart) kann ein alphanumerischer Alias oder die entsprechende Rufnummer sein. <span style="color: #ff285a">*** ***</span>ersetzt diese durch die in <span style="color: #ff285a">*** ***</span>provisionierte Kopfnummer („Network Provided Number").

## Sicherheit bei ausgehenden Gesprächen mit  für MS Teams

Die Identifizierung erfolgt über die Customer Tenant Domain. Signalisierung und Sprache sind ausschließlich verschlüsselt.

## Sicherheit bei ausgehenden Gesprächen mit  für Twilio BYOC

Die Identifizierung erfolgt über die eindeutige Twilio Account Sid und einem speziellen X-Header. Signalisierung und Sprache sind ausschließlich verschlüsselt.  

## Sperrklassen / Rufprofile

Sperrklassen dienen dazu, dem Teilnehmer nur bestimmte Länder und Netze anrufen zu lassen beziehungsweise die Weiterleitungen dorthin zu erlauben. yuutel hat folgende Standardsperrklassen definiert.

| Name | Beschreibung | Bemerkung |
| --- | --- | --- |
| 00_int_eu_national | Sperrklasse 9 (Sperre International nicht Europa und Mehrwertnummern) | Rufe innerhalb Europas sind möglich. Rufe auf österreichische Mehrwertnummern (+439x) sind geblockt. |
| 01_int_mobil | Sperrklasse 2 (Mehrwertnummernsperre) | Weltweite Rufe sind möglich. Rufe auf österreichische Mehrwertnummern (+439x) sind geblockt. |
| 02_int_mobil_prem | Sperrklasse 1 (Dialersperre) | Rufe innerhalb Europas sind möglich. Rufe auf österreichische Dialernummern (+43939x) sind geblockt. |
| 03_int_mobil_prem_dialer | Sperrklasse 0 (keine Einschränkungen) | Keine Einschränkungen |
| 04_nat_prem_mobil_dialer | Sperrklasse 3 (Sperre International) | Internationale Rufe sind geblockt. Nur Rufe auf österreichische Rufnummern (+43x) und UIFN-Nummern (+800) sind möglich. |
| 05_nat_prem_mobil | Sperrklasse 4 (Sperre International, Dialersperre) | Rufe auf österreichische Rufnummern (+43) und UIFN Nummern (+800) sind möglich. Rufe auf österreichische Dialernummern (+43939x) sind geblockt. |
| 06_nat_mobil | Sperrklasse 5 (Sperre International, Mehrwertnummern) | Rufe auf österreichische Rufnummern (+43x) und UIFN Nummern (+800) sind möglich. Rufe auf österreichische Mehrwertnummern (+439x) sind geblockt. |
| 07_nat_prem | Sperrklasse 6 (Sperre International, national Mobil, Dialersperre) | Rufe auf österreichische Festnetznummern und UIFN-Nummern (+800) sind möglich. Rufe auf österreichische Dialernummern (+43939x) sind geblockt. |
| 08_nat | Sperrklasse 7 (Sperre International, national Mobil, Mehrwertnummern) | Rufe auf österreichische Festnetznummern und UIFN-Nummern (+800) sind möglich. Rufe auf österreichische Mehrwertnummern (+439x) sind geblockt. |
| 09_local | Sperrklasse 8 (Sperre International, national Mobil, national Festnetz, Mehrwertnummern) | Rufe auf österreichische Festnetznummern sind möglich. |
| 15_bloecked | Sperrklasse 15 (Komplettsperre) | Komplettsperre. Rufe auf österreichische Free Call-Nummern (+43800) und UIFN Nummern (+800) sind möglich. |
| 16_blocked_fraud | Sperrklasse 16 (Komplettsperre Limitüberschreitung) | Komplettsperre. Systembedingte Sperre aufgrund von Betrugsverdacht. Rufe auf österreichische Free Call-Nummern (+43800) und UIFN Nummern (+800) sind möglich. |
| 17_blocked_admin | Sperrklasse 17 (Komplettsperre Administrator) | Komplettsperre. Interne Anrufe sind möglich. |

Die Sperrklasse "00_int_eu_national" ist der Standard. Beim Produkt  und  für Microsoft Teams ist eine Umstellung der Sperrklasse nur per Service Ticket möglich.

## Fraud Detection ( SIP Trunk,  für Microsoft Teams,  für Genesys Cloud CX,  für Twilio BYOC und FQDN) 

Es ist möglich am  Trunk ein Kostenlimit zu setzen. Dies erfolgt automatisiert durch yuutel bei der Anlage des Trunks. Die Kosten jedes Anrufs werden in Echtzeit akkumuliert und bei Erreichen des Limits erfolgt ein interner Alarm an das yuutel Service Team. Dieser Alarm wird während der Öffnungszeiten der yuutel GmbH überprüft und ggf. mit dem Kunden besprochen. Sollte unerwünschtes Verhalten vorliegen, kann eine sofortige Sperrung erfolgen.

Die Zeitintervalle, in denen kumuliert wird, sind: pro Stunde / pro Tag / pro Woche / pro Monat.

Auf Kundenwunsch kann diese Sperre auch automatisch (24/7/365) erfolgen. Wenden Sie sich dazu bitte an [service@yuutel.at](mailto:service@yuutel.at).

## Weitere Sicherheitsmaßnahmen ( SIP Trunk und  für Genesys Cloud CX)

- Im Domain Part der REQUEST/To/From/PAID/PPID URI im SIP-Header können nur die von <span style="color: #003366">yuutel</span> bereitgestellten Domainnamen verwendet werden. IP-Adressen werden nicht unterstützt!
- Der Authentifizierungsbenutzer muss jenem Format übermittelt werden, indem er im <span style="color: #ff285a">*** ***</span>konfiguriert wurde. Die möglichen Formate sind:
  - nationale Rufnummer
  - Rufnummer in E.164
  - Alias
  - <span style="color: #000000">random (Bei „random“ wird gleichzeitig der IP-Filter deaktiviert; dies gilt jedoch nur für den Business Trunk)</span>
- Der für Registrierung und Gespräche notwendige Outbound Proxy mit dazugehörigem Port ist:
  - Outboundproxy wenn beim Kunden NAT verwendet wird: bt.siptel.at:5060
  - Outboundproxy wenn beim Kunden KEIN NAT verwendet wird: bt.siptel.at:5084
- Verschlüsselung (siehe Kapitel "Verschlüsselung (SIPS, SDES)")

# Abgehende Gespräche

Das IP zu PSTN-Routing wird immer über einen Outbound Proxy realisiert. Ausgehende Gespräche werden immer authentifiziert, autorisiert und danach geroutet.

## Abgehende Gespräche bei Ausprägung  SIP Trunk

Bereitgestellte Funktionen sind:

- Authentifizierung des Gesprächs (siehe "Sicherheit bei ausgehenden Gesprächen").
- Mapping (Umsetzung) von SIP-Parametern wie "abgehender Rufnummer" oder "kundeneigene Rufnummer" (CLIP-no-screening) ins PSTN.
- Spezielle Behandlung von Notrufen.
- Fax Unterstützung mit T.38 (udptl) und G.711 A-Law Fallback.
- Unterstützung verschiedenster Codecs: siehe Kapitel "Unterstütze Codecs".

## Abgehende Gespräche bei Ausprägung MS Teams

Bereitgestellte Funktionen sind:

- Mapping (Umsetzung) von SIP-Parametern wie "abgehende Rufnummer" oder "kundeneigene Rufnummer" (CLIP-no-screening) ins PSTN.
- Spezielle Behandlung von Notrufen.

## Abgehende Gespräche bei Ausprägung für Genesys Cloud CX

Bereitgestellte Funktionen sind:

- Mapping (Umsetzung) von SIP-Parametern wie "abgehender Rufnummer" oder "kundeneigene Rufnummer" (CLIP-no-screening) ins PSTN.
- Spezielle Behandlung von Notrufen.
- Fax wird nur mittels G.711 unterstützt

## Abgehende Gespräche bei Ausprägung Twilio BYOC

Bereitgestellte Funktionen sind:

- Mapping (Umsetzung) von SIP-Parametern wie "abgehender Rufnummer" oder "kundeneigene Rufnummer" (CLIP-no-screening) ins PSTN.
- Spezielle Behandlung von Notrufen.

## Abgehende Gespräche bei Ausprägung FQDN

Bereitgestellte Funktionen sind:

- Mapping (Umsetzung) von SIP-Parametern wie "abgehender Rufnummer" oder "kundeneigene Rufnummer" (CLIP-no-screening) ins PSTN.
- Spezielle Behandlung von Notrufen.

# Ankommende Gespräche von PSTN oder SIP-Teilnehmer

## Ankommende Gespräche bei Ausprägung  SIP Trunk und FQDN

PSTN zu IP-Routing wird immer auf den registrierten Kontakt durchgeführt. Um einen Teilnehmer zu erreichen, muss dieser dem Registrar zuvor seine IP-Adresse via SIP REGISTER mitteilen.  
Statisches Routing auf eventuelle fixe IP-Adressen wird nicht unterstützt! Die Zielrufnummer wird in der Request URI übertragen. Das Format des To: Header-Feldes ist nicht definiert und kann vom Kunden für eigene Routingzwecke verwendet werden.

- Durchwahlfähigkeit (DDI), wobei die Durchwahl an die Kopfnummer angehängt wird.
- Nur Blockwahl (En-bloc dialling)
- Unterstützung von geographischen, nomadischen und portierten Rufnummern.
- Fax Unterstützung mit T.38 (udptl) und G.711 A-Law fallback
- Unterstützung verschiedenster Codecs inklusive G.723.1 und G.729a (siehe Kapitel "Unterstütze Codecs").

Die Reihenfolge der Codecs ist nicht veränderbar! Als höchste Priorität wird immer G.711 A-Law vorgeschlagen.

Im Fall einer Erkennung eines Fax muss die Kunden-PBX den Wechsel auf T.38 initiieren (falls dieser gewünscht ist). Ist ein Wechsel auf T.38 nicht möglich, so muss die Kunden-PBX den  
Wechselwunsch der Gegenstelle mit 488 ablehnen und das Gespräch mit dem zuvor ausgehandelten Codec weiterführen.

## Ankommende Gespräche bei Ausprägung MS Teams

- Durchwahlfähigkeit (DDI), wobei die Durchwahl an die Kopfnummer angehängt wird.
- Nur Blockwahl (En-bloc dialling)
- Unterstützung von geographischen, nomadischen und portierten Rufnummern.
- Unterstützung G.711 A-Law bzw. G.722 auf Anfrage

## Ankommende Gespräche bei Ausprägung Genesys Cloud CX

Für das PSTN zu IP-Routing kommt, im Gegensatz zu , eine statische Route (yuutel Cloud → Genesys Cloud) zum Einsatz. Die Zielrufnummer wird in der Request URI übertragen. Das Format des To: Header-Feldes ist nicht definiert und kann vom Kunden für eigene Routingzwecke verwendet werden.

- Durchwahlfähigkeit (DDI), wobei die Durchwahl an die Kopfnummer angehängt wird.
- Nur Blockwahl (En-bloc dialling)
- Unterstützung von geographischen, nomadischen und portierten Rufnummern.
- Fax Unterstützung nur mit G.711 A-Law
- Unterstützung G.711 A-Law bzw. G.722 und OPUS auf Anfrage

## Ankommende Gespräche bei Ausprägung Twilio BYOC

- Durchwahlfähigkeit (DDI), wobei die Durchwahl an die Kopfnummer angehängt wird.
- Nur Blockwahl (En-bloc dialling)
- Unterstützung von geographischen, nomadischen und portierten Rufnummern.
- Unterstützung G.711 A-Law

## Load Balancing und q-value (SIP Trunk)

Der q-value bestimmt die Präferenz einer Registrierung. Wird bei mehrfacher Registrierung kein q-value angegeben, so ist der Defaultwert einer Registrierung gleich "1.0".  
Gespräche zu einem SIP Trunk mit Mehrfach-Registrierung werden entsprechend ihrer Präferenz verteilt. Zuerst werden die Gespräche der Registrierung mit dem höchsten q-value zugestellt. Ist dieser nicht erreichbar, erfolgt ein Failover auf den nächstniedrigeren q-value.

Die q-value Werte liegen im Bereich von 0.1 ... 1.0.

Beispiel:

> ℹ️ Hier finden Sie eine [Beispiel-Registrierung](https://dokucenter.yuutel.at/space/Dokucenter/2238492545/Leistungsbeschreibung+yuu+Connect+SIP+Trunk,+yuu+Connect+f%C3%BCr+MS+Teams+und+yuu+Connect+f%C3%BCr+Genesys+Cloud+CX#Registrierung).

Per Default ist der SIP Trunk mit dem Feature "Registrierte Kontakte ersetzen" konfiguriert. Kontakte mit gleichem q-value ersetzen dabei andere (alte) Registrierungen.

Ist ein Load-Balancing erwünscht, muss der SIP Trunk mit der Load-Balancing Option konfiguriert geordert werden.

> ✅ Der Trunk erlaubt im Standard unmittelbar 2 gleichzeitige Registrierungen. Bei weiteren Registrierungen ist dies an yuutel bekannt zu geben.
> ✅ 
> ✅ Folgende Balancing Möglichkeiten stehen zur Verfügung:
> ✅ 
> ✅ - Redundant
> ✅ - Redundant NAT
> ✅ - Load Balancing
> ✅ - Load Balancing NAT

## Load Balancing und q-value (für Genesys Cloud CX,  für Microsoft Teams , für Twilio BYOC und FQDN)

Hier erfolgt das Load Balancing automatisch innerhalb der Systeme

# NAT und IP-Fragmentierung (SIP Trunk)

## NAT/Firewall Unterstützung

Es werden sowohl NAT als auch Firewalls auf Kundenseite unterstützt. Die volle Funktionalität kann aber erst nach einer Prüfung der Gegebenheiten sichergestellt werden. Soll die NAT-Unterstützung auf Providerseite geschehen, so muss das kundenseitige, NAT-ausübende Gerät, sämtliche Informationen im SIP-Protokoll unverändert durchreichen!  
Ist ein SIP-aware NAT-ALG (Application Layer Gateway) kundenseitig im Einsatz, dann muss dieses ALG sämtliche SIP NAT-Funktionen bereitstellen.  
Im Falle einer Erkennung von NAT werden providerseitig sog. Keep Alives mit Hilfe von SIP-OPTIONS periodisch gesendet, um etwaige Firewalls und NAT-Endgeräte daran zu hindern, die Verbindung nach einer Zeit zu unterbrechen (UDP Timeout).

Outboundproxy wenn beim Kunden NAT verwendet wird: bt.siptel.at:5060  
Outboundproxy wenn beim Kunden KEIN NAT verwendet wird: :bt.siptel.at:5084

## IP-Fragmentierung

Die Kunden-PBX sowie eine vorgeschaltete Firewall oder ein Router müssen fragmentierte IP-Pakete zulassen und verarbeiten können. SIP-Nachrichten können größer als 1500 Byte werden und werden dann über fragmentierte IP/UDP Pakete übertragen. Eine Firewall oder ein NAT Device muss die Fragmente entsprechend erkennen können und auch zulassen.

# Provisional Responses, Session Timer, Private Header Extensions, ISDN Clear Channel, ISDN Suspend/Resume (SIP Trunk)

## Provisional Responses

Provisional Responses entsprechend RFC 3262 werden unterstützt, falls sie im Gesprächsaufbau von der Gegenstelle angefordert werden.  
Provisional Responses werden jedoch nie aktiv angefordert!

Provisional Responses stehen jedoch ungetestet zur Verfügung, es wird aber keine Garantie über deren korrekte Funktion gegeben (z.B. Gesprächsabbrüche, etc.).

## Session Timer

Session Timer entsprechend RFC 4028 werden unterstützt, falls sie im Gesprächsaufbau von der Gegenstelle angefordert werden.  
Session Timer werden jedoch nie aktiv angefordert!

Session Timer stehen jedoch ungetestet zur Verfügung, es wird aber keine Garantie über deren korrekte Funktion gegeben (z.B. Gesprächsabbrüche, etc.).

## Private Header Extensions

Aus technischen Gründen kann es vorkommen, dass sogenannte private SIP-Header vorkommen. Diese beginnend mit “X-“.  Die Kunden-PBX muss diese Felder ignorieren.

## ISDN Clear Channel (64 kb/s unrestricted)

Als einzige Datenübertragung wird der ISDN-Dienst „64 kb/s Unrestricted“ oder der sog. „Clear Channel“ unterstützt. Dabei muss die Kunden-PBX den Codec X-CCD verwenden und in der P-Preferred-Identity den URI Parameter „;x-sin=700“ hinzufügen (private Option für „Service Indicator“).

Beispiel:

P-Preferred-Identity: <sip:+4359999@demo.domain;x-sin=700>  
Anmerkung: Es muss ein URI-Parameter, und nicht Header-Parameter, sein! Ein Header-Parameter wäre bspw. P-Preferred-Identity: <sip:x@y>;header-param=123 (auch ohne <..> wäre es ein Header-Parameter).

## ISDN Suspend/Resume

ISDN Suspend/Resume (bspw. bei Vermittlung in ISDN TK-Anlagen) wird nicht an die Kunden-PBX weitergegeben, sondern im Betreibernetz abgefangen. Ein SIP-Teilnehmer erhält dadurch die Wartemusik des ISDN-Teilnehmers.  
Ein reInvite einer Session mit Media IP-Adresse 0.0.0.0 oder „sendonly“ wird ins ISDN als „Suspend“ übertragen. Ein darauffolgendes reInvite mit gültiger Media IP-Adresse oder „sendrecv“ wird ins ISDN mit „Resume“ übertragen.

Die Kunden-PBX muss ausgehend die Wartemusik entsprechend mit “sendonly” übertragen. yuuutel spielt keine Wartemusik ein!

Anmerkung: Es wird empfohlen, Wartemusik bei Kunden-PBX-internem Transfer ohne weitere SIP-Signalisierung im bestehenden Audio-Stream einzuspielen.  
D.h. externe Teilnehmer sollen nach Möglichkeit keine Signalisierungsinformation bei Kunden-PBX-internen Vorgängen erhalten.

# SIP-Header Spezifikation (SIP Trunk)

## Allgemeine Voraussetzungen

- Es wird nur der RFC3261 unterstützt (RFC2543 wird NICHT unterstützt). Die Kunden-PBX muss „loose routing“ nach RFC3261 unterstützen. Weiters müssen unterstützt sein:
  - Multiple Record-Route
  - Route and Via header
  - Korrekte Request URI
  - Route-Set Operationen bei in-Dialog requests
- Ein vollständiger Contact URI im Request URI muss für Session-Updates bei reInvites verwendet werden. Dabei müssen alle Route-Header des aktuellen Route-Sets inkludiert sein, sowie die vollständige Liste der Via Header. Der Contact URI, welcher für reInvites verwendet wird, muss auch alle URI-Parameter verwenden! (Contact URI ist alles zwischen <...> im Contact: Header).
- Unterstützte SIP-Methoden sind: INVITE, CANCEL, BYE, ACK, INFO, OPTIONS.
- Aktive Gespräche werden mit Hilfe von in-dialog INFO-Messages periodisch geprüft. Die Kunden-PBX muss auf diese in irgendeiner Form antworten! Bei 481 Responses, 480 Responses bzw. keine Antwort wird das Gespräch vom Proxy automatisch beendet (Wichtig bei Firewalls, die diese SIP-Messages nach x Minuten blockieren!).
- Domainnamen (anstelle von IP-Adressen) sind vorgeschrieben im Request URI (REGISTER und initial INVITE), sowie im Domain-Part im From: und To: Header. Eine Zuordnung über mit IP-Adressen ist nicht möglich. (siehe "Weitere Sicherheitsmaßnahmen")
- Ein Outbound Proxy bestimmt lediglich die Route zum ersten Hop. Keinesfalls darf der Outbound Proxy als Domainname in jeglichen SIP-Header oder im Request URI verwendet werden (siehe RFC3261).
- Request URI, To URI und From URI sollen nach Möglichkeit keine Information des benutzen Ports enthalten (siehe RFC3261).
- Der Contact Header im initial INVITE oder REGISTER muss den (UDP oder TCP) Port enthalten, wenn der Standard-Port (5060) nicht verwendet wird (siehe RFC3261).

## IP zu PSTN Nummer Mapping

Bei Kunden-PBX zu PSTN-Gesprächen werden die SIP-Header Informationen wie nachfolgend beschrieben, übersetzt.

Dabei ist der <domainname> der Name der Domain des SIP-Accounts! (also weder der Outbound Proxy noch eine beliebige Domainname, siehe auch Kapitel "Weitere Sicherheitsmaßnahmen")

### Request URI

Die Request URI im initial INVITE muss die Zielrufnummer im folgenden Format aufweisen:

sip:<+E.164>@<domainname>

Ausschließlich die Request URI wird zum Routing verwendet (nicht der To: Header)! Die Zielrufnummer kann mit oder ohne Vorwahl gewählt werden.

### From, P-Preferred-Identity and P-Asserted-Identity Header

P-Preferred-Identity (PPID) und P-Asserted-Identity (PAID) Header dienen der Signalisierung der sog. CLIP-no-screening Funktionalität, sowie der Anzeige der Durchwahl, wenn diese nicht an den From Header angefügt wird (oder werden kann).

yuutel übernimmt keine Garantie dafür, dass die gewünschte Rückrufnummer beim Endteilnehmer angezeigt wird, da dies auch von anderen Netzbetreibern beeinflusst werden kann! Auch die Übertragung der „User Provided Number“ ins Ausland kann nicht gewährleistet werden (i.d.R. wird diese Nummer innerhalb Europas  jedoch angezeigt).

#### Business Trunk Profil 1 (Standard)> Macro (anchor)



Dieses Profil übermittelt die Accountdaten im P-Asserted-Identity Header. Anonymous und User Provided Nummern sind im FROM Header zu senden.

- From Header User part im Format +E.164
  - eigene Rufnummer
  - eigene Rufnummer + angehängte DW
  - andere Rufnummer, wie dem TN angezeigt werden soll
  - Wird als sog. „User Provided Number“ (Additional Calling Party ID, user provided, not verified) übertragen.
- PAID im Format +E.164
  - eigene Rufnummer
  - eigene Rufnummer + angehängte DW
- PPID im Format +E.164
  - eigene Rufnummer
  - eigene Rufnummer + angehängte DW

Die PPID dient hier allerdings nur zur Verifizierung der eigenen Rufnummer (falls z.B. PAID nicht vorhanden ist) und wird nicht zur Signalisierung an den B Teilnehmern übermittelt.

Beispiele:

> ℹ️ Hier finden Sie [Beispiele](https://dokucenter.yuutel.at/space/Dokucenter/2238492632/Cookbook+yuu+Connect+SIP+Trunk#Business-Trunk-Profil-1-(Standard)).


#### Business Trunk Profil 2

Dieses Profil übermittelt die die Accountdaten im FROM Header. Durchwahlinformationen, Anonymous und User Provided Nummern befinden sich im P-Preferred-Identity Header.

Durchwahlen können optional im FROM Header angefügt werden, sofern das Account Format “international” ist.

- FROM Header User part im Format +E.164
  - eigene Rufnummer
  - eigene Rufnummer + angehängte DW
- PAID im Format +E.164
  - eigene Rufnummer
  - eigene Rufnummer + angehängte DW
- PPID im Format +E.164
  - eigene Rufnummer
  - eigene Rufnummer + angehängte DW
  - andere Rufnummer welche dem TN angezeigt werden soll

Wird als sog. „User Provided Number“ (Additional Calling Party ID, user provided, not verified) übertragen.

Beispiele:

> ℹ️ Hier finden Sie [Beispiele](https://dokucenter.yuutel.at/space/Dokucenter/2238492632/Cookbook+yuu+Connect+SIP+Trunk#Business-Trunk-Profil-2).

### Privacy header (Unterdrückung der Rufnummernanzeige)

Die Unterdrückung der Rufnummernanzeige pro Gespräch (CLIR-T) kann mit Hilfe des Privacy Headers entsprechend RFC3323 durchgeführt werden.  
Die unterstützen Token sind “none” und “id”. Wenn privacy auf “id” gesetzt ist (Privacy:id), werden alle Rufnummern laut Kapitel "From, P-Preferred-Identity and P-Asserted-Identity Header" “unterdrückt” ins PSTN gesendet und bei Rufen zu anderen SIP-Teilnehmern durch anonymous@anonymous.invalid ersetzt.

Soll die Rufnummernanzeige unterdrückt werden, muss trotzdem die Rufnummer (oder der Account) des Teilnehmers im From Header mitgesendet werden! Ein anonymous@anonymous.invalid im From wird nicht unterstützt!

Generell gilt: Soll die Rufnummernanzeige unterdrückt werden, so werden alle übermittelten Rufnummern gleichermaßen unterdrückt.

### Anlagen-unterstützte Rufumleitung im Netz (Partielle Rufumleitung - nur  SIP Trunk)

Die Kunden-PBX kann ein Gespräch pro Anruf umleiten, indem sie vor der Final Response ein 302 Moved Temporary mit der neuen Zielrufnummer im Contact Header sendet.  
Das Gespräch wird dann im Netz weitergeleitet, wobei die Rufnummer des Anrufers erhalten bleibt. Die Rufnummer der Kunden-PBX wird als Redirecting Number (Diversion oder als sog. C Rufnummer) hinzugefügt und die Weiterleitung dem Account der Kunden-PBX gemäß Tarifbestimmungen für die Zielrufnummer verrechnet.

## PSTN zu IP Number Mapping

Bei PSTN zu Kunden-PBX-Gesprächen werden die SIP-Header Informationen wie folgt übersetzt:

### Calling Party ID and Additional Calling Party ID

Die Calling Party ID (A-Rufnummer) wird unabhängig vom “Screening Indicator” im From Feld als nationale Rufnummer übertragen. „National“ ist dann der Fall, wenn A- und B-Rufnummer die gleiche Landesvorwahl (bspw. +43) haben.  
Nationales Format bedeutet, dass eine Rufnummer mit einer "0" beginnt. Internationale A-Rufnummern werden im „nationalen Format“ beginnend mit „00“ übertragen.  
Ist eine weitere Rufnummer (“User Provided Number” oder “additional calling party ID”) vorhanden, so wird diese ebenfalls im From Feld übertragen. Die Kopfnummer („Network Provided Number“) wird in diesem Fall als zusätzliche Rufnummer im P-Preferred-Identity Header im internationalen Format beginnend mit „+“ hinzugefügt.  
Allgemein gilt:

- Wenn beide, “network provided” und “user provided”, Nummern vorhanden sind:  
”user provided” im nationalen Format im Userpart des From Headers, und ”network provided” im internationalen Format im Userpart des P-Preferred-Identity Headers.
- Wenn nur „network provided“ Nummer vorhanden ist:  
“network provided“ im nationalen Format im Userpart des From Headers
- Alle nationalen (z.B. österreichischen) Rufnummern beginnen mit einer führenden „0“, internationale Rufnummernwerden mit zwei führenden Nullen „00“ übertragen.

### Privacy (Unterdrückung der Rufnummernanzeige)

Wünscht der Anrufer eine Unterdrückung der Anzeige seiner Rufnummer, so wird keine Rufnummer mehr gesendet. Im From Feld wird anonymous@anonymous.invalid oder <anonymisierte, zufällige Zeichen>@anonymous.invalid (bspw. From: „Unterdrueckt“ <sip:kUjdkUUh67U@anonymous.invalid>) übertragen.

### Umgeleitete Anrufe

Wird der Teilnehmer über eine Umleitung (indirekt) angerufen, so wird der SIP-Header „Diversion“ entsprechend draft-levy-sip-diversion-08.txt hinzugefügt.

## Response Code Mapping

Das Response Code Mapping ist nicht Teil dieser Spezifikation und wird bei Bedarf separat zur Verfügung gestellt. yuutel versucht dabei, ein möglichst sinnvolles Mapping entsprechend den Spezifikationen durchzuführen.

Da jedoch relativ wenig spezielle Response Codes im SIP zur Verfügung stehen, werden 5xx Response Codes (500 und 503) auf sehr viele ISDN Response Codes gemappt. Hierbei gilt im Besonderen „Gassenbesetzt“ zu erwähnen, welches im Unterschied zu „Teilnehmer besetzt“ nicht mit 486, sondern ebenfalls mit einem 503 beantwortet wird. Am häufigsten werden sicherlich 484 (Zielrufnummer zu kurz), 486 (Teilnehmer besetzt) und 404 (Unbekannter Teilnehmer) auftreten. Bei 404 und484 werden jedoch entsprechende Ansagen mit einem Status Response Code 183/SDP gespielt und am Ende mit 486 (Teilnehmer Besetzt) beendet. Das bedeutet, dass kein 404 oder 484 zur Kunden-PBX übertragen wird, sondern stattdessen 183 Progress mit einer Ansage (SDP)

### Übertragung von Ansagen aus dem PSTN

Eine status indication „no indication“ wird auf 183 Progress übersetzt.  
Eine status indication „Subscriber free“ wird auf 180 Ringing übersetzt.

Wird vom PSTN auch “In-band information is now available” gesetzt, hat die 1xx Status Information auch SDP-Parameter. Im Allgemeinen wird 183/SDP gesendet, aber es kann vorkommen, dass 180/SDP bei „Subscriber free“/“In-band information is now available“ übertragen wird. Ein explizites Beispiel sind Tarifansagen bei Rufnummernportierung wie sie bei Mobilrufnummern vorkommen. Die Kunden-PBX ist dafür verantwortlich, auch bei 180/SDP die entsprechende Ansage dem Teilnehmer durchzuschalten. Eine Haftung durch nicht durchgeschaltete Tarifansagen und den daraus resultierenden Kosten durch „Unwissenheit“ bei Gesprächen zu Mehrwertnummern oder Mobilteilnehmern ist ausgeschlossen.

### Übertragung von Ansagen in das PSTN

Es wird keine Garantie für die Übertragung von 183/SDP („Text vor Melden“) in das PSTN gegeben. Um sicherzustellen, dass Ansagen ins PSTN übertragen werden, muss die Kunden-PBX die Verbindung herstellen (200 OK, Connect / „Text nach Melden“). Verbindungen im Zustand 180 Ringing oder 183 Progress/SDP werden nach 120 Sekunden getrennt.

### DTMF (Dual Tone Multi Frequency)

DTMF wird inband mittels RFC2833 oder als RTP-Audio entsprechend der Aushandlung über RFC 3264 übertragen. Der DTMF payload type ist 101.

## Fax Unterstützung

Fax-Übertragungen werden entweder mittels G.711 A-law (Bypass oder Fallback) oder T.38 (udptl) unterstützt.

Voraussetzung für eine fehlerfreie Fax-Übertragung ist eine entsprechende IP-Anbindung mit IP-Quality of Service mit einem Packet Loss < 0,1% und einem Jitter < 20ms. Wird T.38 als Fax-Übertragung eingesetzt, muss das vom Kunden bereitzustellende CPE oder der T.38 Software Stack (bspw. in modernen Fax Server-Lösungen) die Kompatibilität zu seinen eingesetzten Fax Geräten garantieren. yuutel kann in dem Fall keine Garantie für eine fehlerfreie Übertragung zu allen Faxgeräten geben.

Eine Fax-Übertragung muss immer mit einem Sprach-Codec beginnen und mit Hilfe von reInvite auf T.38 wechseln. Ein direkter Aufbau einer Verbindung mit der Übertragung durch T.38 wird nicht unterstützt. Die Methode UPDATE kann nicht verwendet werden!

Die maximal unterstützte Geschwindigkeit ist 14400 bps. Super G3 bzw. V.34 Faxgeräte (33600 bps) werden nicht unterstützt. Diese Geräte müssen auf eine maximale Geschwindigkeit von 14400 bps eingestellt werden, da ein ggfs. erfolgreicher Handshake mit 33600 bps am Anfang der Verbindung in Folge zu Abbrüchen führt.

### Fax-Übertragung mit T.38 von Kunden-PBX ins PSTN

Die Übertragung von Fax mittels T.38 in Richtung PSTN wird in drei Arten unterstützt:

1. T.38 passive mode: Dieser (default) Mode erlaubt den Wechsel auf T.38 innerhalb einer Session. Allerdings bietet das PSTN-Gateway den Wechsel nicht aktiv an. Die Kunden-PBX muss den Wechsel initiieren.
2. T.38 active mode: In diesem Fall bietet das PSTN-Gateway einen Codec Change auf T.38 an, wenn ein Faxton erkannt wird. Dazu muss von der Kunden-PBX entweder eine 2nd SDP Line mit „t38 image udptl“ gesendet, oder der Zielrufnummer ein „**1“ angefügt werden. Dabei gilt zu beachten, dass dieses „**1“ auch wirklich gesendet wird und nicht durch die Kunden-PBX „verschluckt“ wird.
3. T.38 inactive mode: Wird der ATA so eingestellt, dass er immer eine 2nd SDP Line mit „t38 image udptl“ sendet, aber eine erfolgreiche Übertragung nicht möglich ist, so kann man für dieses eine Gespräch den Fax Mode mit „**0“ gezielt auf G.711 A-law Bypass setzen.

In Richtung anderer SIP-Teilnehmer hängt eine erfolgreiche T.38 Übertragung vom verwendeten Endgerät auf der anderen Seite ab. Will die Kunden-PBX auf T.38 wechseln, und lehnt die Gegenstelle dies mit dem Response Code 488 ab, so muss die Kunde-PBX das Gespräch mit dem zuvor eingesetzten Codec weiterführen, oder einen Fallback auf einen anderen auszuhandelnden Codec durchführen (vorzugsweise G.711 A-Law Fallback).

### Fax-Übertragung mit T.38 von Provider-Seite und G.711 A-law Bypass in Richtung Kunden-PBX

Die Übertragung von Fax aus dem PSTN mittels T.38 in Richtung Kunden-PBX wird auf folgende Art unterstützt:  
T.38 passive mode: Dieser (default) Mode erlaubt den Wechsel auf T.38 innerhalb einer Session. Allerdings muss die PBX von sich aus den Codec wechseln. Das Gateway wird nie aktiv einen Wechsel auf T.38 vorschlagen. Kommt der Anruf von einem anderen SIP-Teilnehmer und will dieser einen Wechsel auf T.38 vornehmen, so muss die Kunden-PBX diesen – sofern gewollt – mit einem Response Code 488 oder 415 ablehnen. Die Gegenstelle, sowie die Kunden-PBX, müssen sodann das Gespräch mit dem zuvor ausgehandelten Codec fortsetzen oder einen neuen gemeinsamen Codec (vorzugsweise G.711 A-Law) aushandeln (Fallback).

## Unterstützte Codecs

Die folgenden Codecs werden unterstützt. Die Kunden-PBX muss entsprechend RFC3264 mit der Liste von Codecs im INVITE umgehen können. Der Standardwert des Packetization Intervalls ist 20 ms (ptime 20), sofern möglich.

- G.711 A-Law
- G.722 auf Anfrage

Bei Bedarf zusätzlich unterstütze Codecs:

- G.723r63
- G.729ar8

Definierte Codec Payload Types (PT)werden entsprechend RFC3551 übertragen.

# Verschlüsselung (SIPS, SDES für yuuconnect )

Die Sprachverbindung und die zugehörige Signalisierung können verschlüsselt werden. Für die Signalisierung (SIPS) wird TLS (analog zum HTTPS Protokoll) eingesetzt und für den Medienpfad wird SDES zur symmetrischen Verschlüsselung der RTP-Ströme (SRTP) eingesetzt. Die Signalisierung muss dabei über TCP erfolgen, da die TLS-Verbindung dies zwingend voraussetzt!

Bei der Verwendung von Verschlüsselung ist der  Port 5061 zu verwenden.

### Zertifikate

Es werden seitens yuutel ausschließlich offizielle Zertifikate eingesetzt, die gegen eine aktuelle Liste der Certificate Authorities (CA) geprüft werden können.

### Beispiel eines korrekten REGISTER und INVITE

> ℹ️ Hier finden Sie [Beispiele](https://dokucenter.yuutel.at/space/Dokucenter/2238492632/Cookbook+yuu+Connect+SIP+Trunk#INVITE).

# Unterstütze Standards und RFCs (und Genesys Cloud CX)

- RFC3261SIP Session Initiation Protocol
- RFC3262 Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
- RFC3263 Session Initiation Protocol (SIP): Locating SIP Servers
- RFC3264 An Offer/Answer Model with the Session Description Protocol (SDP)
- RFC3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)
- RFC3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
- RFC2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
- RFC3550 RTP A Transport Protocol for Real-Time Applications
- RFC3551 RTP Profile for Audio and Video Conferences with Minimal Control
- RFC4028 Session Timers in the Session Initiation Protocol (SIP)
- draft-levy-sip-diversion-08.txt Diversion Indication in SIP
- RFC4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information
- RFC4317 Session Description Protocol (SDP) Offer/Answer Examples
- RFC4566 SDP Session Description Protocol
- ITU-TQ.1912.5 Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control Protocol or ISDN User Part

# Unterstütze Endgeräte (SIP Trunk)

Es gibt eine Reihe von Endgeräten, die vom Hersteller und/oder yuutel ausgetestet bzw. zertifiziert sind:

- <span style="color: #000000">Audiocodes Mediant 500L (Business Trunk Profil 1) – autoprovisionierbar über yuutel</span>
- <span style="color: #000000">Audiocodes Mediant 800 (Business Trunk Profil 1) – autoprovisionierbar über yuutel</span>
- <span style="color: #000000">SiemensOpenScape 4000 (Business Trunk Profil 2) – autoprovisionierbar über yuutel</span>
- <span style="color: #000000">Starface (Business Trunk Profil 1) – Es gibt ein funktionierendes Profil in den Starfaceanlagen (6.5.1 Revision 77), welches allerdings je nach Outboundproxy zusätzliche Einstellungen benötigt.</span>
- <span style="color: #000000">Teles BRI/PRI VoIP Boxen (BusinessTrunk Profil 1) – Konfiguration kommt von yuutel</span>


Beispiel Konfigurationen

> ℹ️ Hier finden Sie [Beispiele](https://dokucenter.yuutel.at/space/Dokucenter/2238492632/Cookbook+yuu+Connect+SIP+Trunk#Konfigurations-Files).

# Nicht unterstützte Funktionen

Derzeit werden folgende Funktionen nicht unterstützt:

- Modemcalls: Alle Arten von Modemübertragungen werden nicht unterstützt. Modemübertragungen via G.711 A-Law geschehen auf eigenes Risiko!
- OverlapSending: Wird ein INVITE gesendet, so wird dieses Ziel verwendet. Die Kunden-PBX ist dafür zuständig, die Rufnummer vollständig zu erfassen und danach im Block zu senden.
- SMS: wird nicht angeboten
- RTT: wird nicht angeboten
- Super-G3 Fax oder Faxübertragung mit einer Geschwindigkeit größer 14,4 kb/s werden nicht unterstützt
- RFC2543 wird nicht unterstützt. Alle Gespräche müssen “loose routed” gesendet werden, „Strict routing“ wird nicht mehr unterstützt (nur RFC3261). Insbesondere gilt dies bei reInvites nach Session Timers und bei Codec-Wechseln!
- Nicht unterstützte SIP-Methoden sind REFER, UPDATE, SUBSCRIBE, NOTIFY

# Glossar

|  |  |
| --- | --- |
| ALG | Application Layer Gateway |
| ATA | Analogue Telephone Adapter |
| DDI | Direct Dial Inward |
| MD5 | Message-Digest Algorithm |
| NAT | Network Address Translation |
| PAID | SIP-Header P-Asserted-Identity |
| PBX | Private Branch Exchange |
| PPID | SIP-Header P-Preferred-Identity |
| PSTN | Public Switched Telephone Network |
| RTT | Real Time Text |
| QOP | Quality-Of-Protection |
| URI | Uniform Ressource Locator |