Direct Routing in Azure Communication Services: SIP-Details

In diesem Artikel erfahren Sie, wie Direct Routing das Session Initiation-Protokoll (SIP) implementiert, um die richtigen Datenverkehrsrouten zwischen einem Session Border Controller (SBC) und dem SIP-Proxy sicherzustellen. Außerdem wird die Bedeutung bestimmter SIP-Parameter hervorgehoben, die spezifische Werte erfordern. Dieser Artikel richtet sich an VoIP-Administratoren bzw. -Administratorinnen, die für die Konfiguration der Verbindung zwischen dem SBC und dem SIP-Proxydienst verantwortlich sind.

Verarbeiten der eingehenden Anforderung: Suchen der Communication Services-Ressource

Hinweis

In Direct Routing von Azure Communication Services sind SIP-Optionen standardmäßig aktiviert und können nicht deaktiviert werden. Der SBC muss zuerst den OPTIONS-Austausch initiieren, da der SIP-Proxy wartet, bis der SBC den Austausch startet.

Bevor ein eingehender oder ausgehender Anruf verarbeitet werden kann, werden OPTIONS-Nachrichten zwischen SIP-Proxy und SBC ausgetauscht. Diese OPTIONS-Nachrichten ermöglichen es dem SIP-Proxy, die zulässigen Funktionen für den SBC bereitzustellen. Die OPTIONS-Aushandlung muss erfolgreich sein (Antwort vom Typ „200 OK“), um eine weitere Kommunikation zwischen SBC und SIP-Proxy für Anrufe zu ermöglichen. Hier sehen Sie ein Beispiel für die SIP-Header in einer OPTIONS-Nachricht an den SIP-Proxy:

Parametername	Beispielwert
Anforderungs-URI	OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Via-Header	Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Max-Forwards-Header	Max-Forwards:68
From-Header	From: sip:sbc1.contoso.com:5061
To-Header	To: sip:sip.pstnhub.microsoft.com:5061
CSeq-Header	CSeq: 1 INVITE
Contact-Header	Contact: sip:sbc1.contoso.com:5061;transport=tls

Hinweis

Die SIP-Header enthalten keine Benutzerinformationen im verwendeten SIP-URI. Gemäß RFC 3261, Abschnitt 19.1.1 ist der Teil mit den Benutzerinformationen eines URI optional und möglicherweise nicht vorhanden, wenn der Zielhost über kein Benutzerkonzept verfügt oder wenn der Host selbst die identifizierte Ressource ist. Wenn das @-Zeichen in einem SIP-URI enthalten ist, darf das Benutzerfeld nicht leer sein. Beachten Sie, dass der SIPS-URI nicht mit Direct Routing verwendet werden darf, da dies nicht unterstützt wird. Überprüfen Sie Ihre Session Border Controller-Konfiguration, und stellen Sie sicher, dass Sie keine Replaces-Header in SIP-Anforderungen verwenden. Direct Routing lehnt SIP-Anforderungen ab, die über definierte Replaces-Header verfügen.

Bei einem eingehenden Anruf muss der SIP-Proxy die Azure Communication-Ressource finden, für die der Anruf bestimmt ist. In diesem Abschnitt wird beschrieben, wie der SIP-Proxy die Ressource findet und die Authentifizierung des SBC für die eingehende Verbindung durchführt.

Beispiel für die SIP-Einladungsnachricht für einen eingehenden Anruf:

Parametername	Beispielwert
Anforderungs-URI	INVITE sip:+54321@sip.pstnhub.microsoft.com SIP /2.0
Via-Header	Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Max-Forwards-Header	Max-Forwards:68
From-Header	From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811
To-Header	To: sip:+54321@sbc1.contoso.com
CSeq-Header	CSeq: 1 INVITE
Contact-Header	Contact: sip:+12345@sbc1.contoso.com:5061;transport=tls

Wenn die Einladung empfangen wird, führt der SIP-Proxy die folgenden Schritte aus:

1. Er überprüft das Zertifikat. Bei der ersten Verbindung verwendet der Direct Routing-Dienst den im Contact-Header angegebenen FQDN und gleicht ihn mit dem allgemeinen Namen (Common Name) oder dem alternativen Antragstellernamen (Subject Alternative Name) des präsentierten Zertifikats ab. Der SBC-Name muss einer der folgenden Optionen entsprechen:

   • Option 1. Der vollständige FQDN-Name im Contact-Header muss mit dem allgemeinen Namen bzw. mit dem alternativen Antragstellernamen des präsentierten Zertifikats übereinstimmen.

   • Option 2. Der Domänenteil des FQDN aus dem Contact-Header (z. B. „contoso.com“ des FQDN „sbc1.contoso.com“) muss mit dem Platzhalterwert im allgemeinen Namen bzw. im alternativen Antragstellernamen (z. B. „*.contoso.com“) übereinstimmen.

2. Er versucht, mithilfe des vollständigen FQDN aus dem Contact-Header einen Microsoft 365-Mandanten zu finden.

   Er überprüft, ob der FQDN aus dem Contact-Header (sbc1.contoso.com) als DNS-Name in einer Microsoft 365- oder Office 365-Organisation registriert ist. Ist die Suche erfolgreich, wird die Benutzersuche in dem Mandanten durchgeführt, der den SBC-FQDN als Domänennamen registriert hat. Andernfalls gilt Schritt 3.

3. Er versucht, mithilfe des vollständigen FQDN aus dem Contact-Header eine Azure Communication-Ressource zu finden.

   Er überprüft, ob der FQDN aus dem Contact-Header (sbc1.contoso.com) als SBC-FQDN in einer Azure Communication-Ressource registriert ist. Ist die Suche erfolgreich, wird der Anruf an die entsprechende Ressource gesendet. Andernfalls gilt Schritt 4.

4. Schritt 4 gilt nur, wenn die Schritte 2 und 3 nicht erfolgreich waren.

   Er entfernt den Hostteil aus dem FQDN des Contact-Headers (FQDN: sbc1.contoso.com; nach Entfernen des Hostteils: contoso.com) und überprüft, ob dieser Name in einer Microsoft 365- oder Office 365-Organisation als DNS-Name registriert ist. Ist die Suche erfolgreich, wird die Benutzersuche in diesem Mandanten durchgeführt. Andernfalls ist der Anruf nicht erfolgreich.

5. Schritt 5 gilt nur, wenn die Schritte 2, 3 und 4 nicht erfolgreich waren.

   Er entfernt den Hostteil aus dem FQDN des Contact-Headers (FQDN: sbc1.contoso.com; nach Entfernen des Hostteils: contoso.com) und überprüft, ob dieser Name in einer in einer Azure Communication-Ressource als SBC-FQDN registriert ist. Ist die Suche erfolgreich, wird der Anruf an die entsprechende Ressource gesendet. Andernfalls ist der Anruf nicht erfolgreich.

6. Wenn der Ressource eine Dynamics Omnichannel-Bereitstellung zugeordnet ist, wird nach der Telefonnummer aus dem Anforderungs-URI gesucht. Die präsentierte Telefonnummer wird mit einem Omnichannel-Benutzer bzw. mit einer Omnichannel-Benutzerin (Warteschlange) abgestimmt, der bzw. die im vorherigen Schritt gefunden wurde.

7. Schritt 7 gilt nur, wenn Schritt 6 nicht erfolgreich war.

   Falls keine Omnichannel-Bereitstellung für die Communication-Ressource vorhanden ist oder die Nummer im Anforderungsheader keiner konfigurierten Omnichannel-Nummer entspricht, wird der Anruf an eine Event Grid-Instanz gesendet.

8. Schritt 8 gilt nur, wenn Schritt 7 nicht erfolgreich war.

   Falls Event Grid nicht konfiguriert ist oder keine Regeln für die Verwaltung des eingehenden Anrufs vorhanden sind, wird der Anruf verworfen.

Detaillierte Anforderungen für den Contact-Header und für den Anforderungs-URI

Contact-Header

Bei allen SIP-Nachrichten, die beim Microsoft SIP-Proxy eingehen (OPTIONS, INVITE), muss der Contact-Header den gekoppelten SBC-FQDN im URI-Hostnamen enthalten:

Syntax: Contact: <sip:phone or sip address@FQDN of the SBC;transport=tls>

Gemäß RFC 3261, Abschnitt 11.1 KANN ein Feld des Contact-Headers in einer OPTIONS-Nachricht vorhanden sein. Bei Verwendung von Direct Routing ist der Contact-Header zwingend erforderlich. Bei OPTIONS-Nachrichten können die Benutzerinformationen vom SIP-URI ausgeschlossen werden, und es kann nur der FQDN im folgenden Format gesendet werden:

Syntax: Contact: <sip:FQDN of the SBC;transport=tls>

Dieser Name (FQDN) muss sich auch im Feld für den allgemeinen Namen bzw. im Feld für den alternativen Antragstellernamen des präsentierten Zertifikats befindet. Microsoft unterstützt die Verwendung von Platzhalterwerten der Namen in den Feldern für den allgemeinen Namen bzw. im Feld für den alternativen Antragstellernamen des Zertifikats. Die Unterstützung von Platzhaltern wird in RFC 2818, Abschnitt 3.1 beschrieben. Speziell:

Namen können das Platzhalterzeichen * enthalten, das für eine beliebige Domänennamenkomponente oder für ein beliebiges Komponentenfragment steht. Beispielsweise entspricht „*.a.com“dem Wert „foo.a.com“, aber nicht dem Wert „bar.foo.a.com“. „f*.com“ entspricht „foo.com“, aber nicht „bar.com“.

Wenn im präsentierten Contact-Header einer SIP-Nachricht des SBC mehrere Werte enthalten sind, wird nur der FQDN-Teil des ersten Werts des Contact-Headers verwendet. Wichtige Faustregel für Direct Routing: Zum Auffüllen des SIP-URI muss der FQDN (anstelle der IP-Adresse) verwendet werden. Wenn bei einer eingehenden INVITE- oder OPTIONS-Nachricht für den SIP-Proxy mit Contact-Header der Hostname durch die IP-Adresse und nicht durch den FQDN dargestellt wird, wird die Verbindung mit „403 Verboten“ abgelehnt.

Anforderungs-URI

Bei allen eingehenden Anrufen wird der Anforderungs-URI verwendet, um einen Angerufenen bzw. eine Angerufene zu identifizieren. Derzeit muss die Telefonnummer ein Pluszeichen (+) enthalten, wie im folgenden Beispiel gezeigt:

INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0

From-Header

Bei allen eingehenden Anrufen wird der From-Header für den Abgleich mit der Telefonnummer des Anrufers bzw. der Anruferin verwendet.

Die Telefonnummer ein Pluszeichen enthalten, wie im folgenden Beispiel gezeigt:

From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811

Überlegungen zu Record-Route-Headern

Der SIP-Proxy muss den FQDN des nächsten Hops für neue dialoginterne Clienttransaktionen (z. B. Verabschiedung oder erneute Einladung) sowie beim Antworten auf SIP OPTIONS berechnen. Dazu kann entweder Contact oder Record-Route verwendet werden. Gemäß RFC 3261, Abschnitt 8.1.1.8 ist in jeder Anforderung, die zu einem neuen Dialogfeld führen kann, ein Contact-Header erforderlich. Record-Route ist nur erforderlich, wenn ein Proxy den Pfad zukünftiger Anforderungen in einem Dialogfeld beibehalten möchte.

Um den nächsten Hop zu berechnen, verwendet der SIP-Proxy Folgendes:

• Priorität 1: Record-Route der obersten Ebene. Wenn Record-Route der obersten Ebene den FQDN enthält, wird dieser verwendet, um die ausgehende dialoginterne Verbindung herzustellen.

• Priorität 2: Contact-Header. Ist Record-Route nicht vorhanden, sucht der SIP-Proxy den Wert des Contact-Headers, um die ausgehende Verbindung herzustellen. (Empfohlene Konfiguration.)

Bei gleichzeitiger Verwendung von Contact und Record-Route muss der SBC-Administrator bzw. die SBC-Administratorin die Werte identisch halten, was mit einem gewissen Verwaltungsaufwand verbunden ist.

Verwenden des FQDN in Contact oder Record-Route

Die Verwendung einer IP-Adresse wird weder in Record-Route noch in Contact unterstützt. Die einzige unterstützte Option ist ein FQDN, der entweder dem allgemeinen Namen oder dem alternativen Antragstellernamen des SBC-Zertifikats entspricht. (Platzhalterwerte im Zertifikat werden unterstützt.)

• Wenn in Record-Route oder Contact eine IP-Adresse präsentiert wird, tritt bei der Zertifikatüberprüfung ein Fehler auf, und der Anruf ist nicht erfolgreich.

• Wenn der FQDN nicht dem Wert des allgemeinen Namens oder des alternativen Antragstellernamens im präsentierten Zertifikat entspricht, ist der Anruf nicht erfolgreich.

Anrufkontextheader

Anrufkontextheader sind derzeit nur für das Call Automation SDK verfügbar. Das Call Automation SDK unterstützt User-To-User-Header und bis zu fünf benutzerdefinierte SIP-Header. Diese Header werden in INVITE- und REFER-Methoden unterstützt.

User-To-User-Header

Der User-To-User-Header (UUI-Header) von SIP ist ein Branchenstandard für die Übergabe kontextbezogener Informationen im Rahmen einer Anrufeinrichtung. Die maximale Länge eines UUI-Headerschlüssels beträgt 64 Zeichen. Die maximale Länge eines UUI-Headerwerts beträgt 256 Zeichen. Der UUI-Headerwert kann aus alphanumerischen Zeichen und einigen ausgewählten Symbolen bestehen. Hierzu zählen =, ;, ., !, %, *, _, +, ~, -.

Benutzerdefinierter Header

Azure Communication Services unterstützt auch bis zu fünf benutzerdefinierte SIP-Header. Der Schlüssel des benutzerdefinierten SIP-Headers muss zwingend mit dem Präfix X-MS-Custom- beginnen. Die maximale Länge eines SIP-Headerschlüssels beträgt 64 Zeichen, einschließlich des Präfix X-MS-Custom-. Der SIP-Headerschlüssel kann aus alphanumerischen Zeichen und einigen ausgewählten Symbolen bestehen. Hierzu zählen ., !, %, *, _, +, ~, -. Die maximale Länge des SIP-Headerwerts beträgt 256 Zeichen. Der SIP-Headerwert kann aus alphanumerischen Zeichen und einigen ausgewählten Symbolen bestehen. Hierzu zählen =, ;, ., !, %, *, _, +, ~, -.

Details zur Implementierung finden Sie unter Übergeben von Kontextdaten zwischen Aufrufen.

Eingehender Anruf: Beschreibung des SIP-Dialogs

Hier sind die Details dazu, wie der SIP-Proxy eingehende Anrufe verarbeitet.

Parametername	Wert
Medienkandidaten in Nachrichten vom Typ „183“ und „200“ von folgender Quelle	Medienprozessoren
Anzahl der Nachrichten vom Typ 183, die der SBC empfangen kann	Eine pro Sitzung
Anruf mit vorläufiger Antwort möglich (183)	Ja
Anruf ohne vorläufige Antwort möglich (183)	Ja

Eine Azure Communication Services-Identität kann gleichzeitig in mehreren Endpunkten (Anwendungen) verwendet werden. Beispielsweise in einer Web-App, in einer iPhone-App und in einer Android-App. Jeder Endpunkt signalisiert möglicherweise ein HTTP-REST-Element wie folgt:

• Anrufstatus: Vom SIP-Proxy in die SIP-Nachricht 180 konvertiert. Wenn die Nachricht 180 empfangen wird, muss der SBC lokales Klingeln generieren.

• Medienantwort: Vom SIP-Proxy konvertiert in die Nachricht 183 mit Medienkandidaten im Session Description-Protokoll (SDP). Wenn die Nachricht 183 empfangen wird, erwartet der SBC die Herstellung einer Verbindung mit den Medienkandidaten, die in der SDP-Nachricht empfangen wurden.

  Hinweis

  In manchen Fällen wird die Medienantwort möglicherweise nicht generiert, und der Endpunkt antwortet ggf. mit der Nachricht „Anruf angenommen“.

• Anruf angenommen: Vom SIP-Proxy konvertiert in die SIP-Nachricht 200 mit SDP. Wenn die Nachricht 200 empfangen wird, wird erwartet, dass der SBC Medien an die bereitgestellten SDP-Kandidaten sendet und von ihnen empfängt.

  Hinweis

  Direct Routing unterstützt keine verzögerte Angebotseinladung (Einladung ohne SDP).

Klingeln mehrerer Endpunkte mit vorläufiger Antwort

1. Wenn die erste Einladung vom SBC empfangen wird, sendet der SIP-Proxy die Nachricht „SIP SIP/2.0 100 Trying" und benachrichtigt alle Endbenutzer-Endpunkte über den eingehenden Anruf.

2. Im Anschluss an die Benachrichtigung beginnen alle Endpunkte zu klingeln und Nachrichten vom Typ „Anrufstatus“ an den SIP-Proxy zu senden. Da die Azure Communication Services-Identität von mehreren Endpunkten verwendet wird, empfängt der SIP-Proxy möglicherweise mehrere Anrufstatusnachrichten.

3. Jede von den Endpunkten empfangene Anrufstatusnachricht wird vom SIP-Proxy in die SIP-Nachricht „SIP SIP/2.0 180 Ringing“ konvertiert. Das Sendeintervall solcher Nachrichten korreliert mit dem Intervall der Empfangsnachrichten vom Anrufcontroller. Das folgende Diagramm zeigt zwei 180-Nachrichten, die vom SIP-Proxy generiert werden. Diese Nachrichten stammen von den beiden SDK-Endpunkten. Die Endpunkte verfügen jeweils über eine eindeutige Tag-ID. Jede Nachricht, die von einem anderen Endpunkt stammt, ist eine separate Sitzung. (Der Parameter „tag“ im Feld „To“ unterscheidet sich.) Ein Endpunkt generiert jedoch möglicherweise keine Nachricht vom Typ „180“ und sendet sofort eine Nachricht vom Typ „183“, wie im folgenden Diagramm dargestellt.

4. Sobald ein Endpunkt eine Medienantwortnachricht mit den IP-Adressen der Medienkandidaten des Endpunkts generiert, konvertiert der SIP-Proxy die empfangene Nachricht in eine Nachricht vom Typ „SIP 183 Session Progress“ und ersetzt dabei das SDP des Endpunkts durch das SDP des Medienprozessors. Im folgenden Diagramm hat der Endpunkt von Fork 2 den Anruf angenommen. Die SIP-Nachricht 183 wird nur einmal generiert. Die Nachricht 183 kann über eine bereits vorhandene Verzweigung eingehen oder eine neue Verzweigung beginnen.

5. Eine Anrufakzeptanznachricht wird an den SIP-Proxy mit den endgültigen Kandidaten des Endpunkts gesendet, der den Anruf akzeptiert hat. Die Anrufakzeptanznachricht wird in eine SIP-Nachricht vom Typ „200“ konvertiert.

   

Klingeln mehrerer Endpunkte ohne vorläufige Antwort

1. Wenn die erste Einladung vom SBC empfangen wird, sendet der SIP-Proxy die Nachricht „SIP SIP/2.0 100 Trying" und benachrichtigt alle Endbenutzer-Endpunkte über den eingehenden Anruf.

2. Im Anschluss an die Benachrichtigung beginnen alle Endpunkte zu klingeln und die Nachricht „Anrufstatus“ an den SIP-Proxy zu senden. Da die gleiche Azure Communication Services-Identität in mehreren Anwendungen verwendet werden kann, empfängt der SIP-Proxy möglicherweise mehrere Anrufstatusnachrichten.

3. Jede von den Endpunkten empfangene Anrufstatusnachricht wird vom SIP-Proxy in die SIP-Nachricht „SIP SIP/2.0 180 Ringing“ konvertiert. Das Sendeintervall der Nachrichten korreliert mit dem Intervall des Empfangs der Nachrichten vom Anrufcontroller. Das Bild zeigt, dass der SIP-Proxy zwei 180-Nachrichten generiert. Das bedeutet, dass der Anruf an zwei verschiedene Clients verzweigt wird und jeder Client den Anrufstatus sendet. Jede Nachricht ist eine separate Sitzung. (Der Parameter „tag“ im Feld „To” unterscheidet sich.)

4. Eine Anrufakzeptanznachricht wird an den SIP-Proxy mit den endgültigen Kandidaten des Endpunkts gesendet, der den Anruf akzeptiert hat. Die Anrufakzeptanznachricht wird in eine SIP-Nachricht vom Typ „200“ konvertiert.

   

Replaces-Option

Der SBC muss INVITE mit „Replaces“ unterstützen.

Überlegungen zur SDP-Größe

Die Direct Routing-Schnittstelle sendet ggf. eine SIP-Nachricht mit einer Größe von mehr als 1.500 Bytes. Ein solches Verhalten wird in erster Linie durch die SDP-Größe verursacht. Wenn sich hinter dem SBC allerdings ein UDP-Trunk befindet, wird die Nachricht möglicherweise abgelehnt, falls sie unverändert vom Microsoft-SIP-Proxy an den Trunk umgeleitet wird. Microsoft empfiehlt, auf dem SBC einige Werte in SDP zu entfernen, wenn die Nachricht an die UDP-Trunks gesendet wird. Beispielsweise können die ICE-Kandidaten oder nicht verwendete Codecs entfernt werden.

Anrufweiterleitung

Direct Routing unterstützt zwei Methoden für die Anrufweiterleitung:

• Option 1. Der SIP-Proxy verarbeitet „Refer“ vom Client lokal und fungiert als Weitergegebener, wie in Abschnitt 7.1 von RFC 3892 beschrieben.

  Mit dieser Option beendet der SIP-Proxy die Weiterleitung und fügt eine neue Einladung hinzu.

• Option 2. Der SIP-Proxy sendet „Refer“ an den SBC und fungiert als Weitergeber, wie in Abschnitt 6 von RFC 5589 beschrieben.

  Mit dieser Option sendet der SIP-Proxy „Refer“ an den SBC und erwartet, dass der SBC die Weiterleitung vollständig abwickelt.

Der SIP-Proxy wählt die Methode basierend auf den vom SBC gemeldeten Funktionen aus. Wenn der SBC angibt, dass er die Methode „Refer“ unterstützt, verwendet der SIP-Proxy die zweite Option für Anrufweiterleitungen. Beispiel eines SBC, der die Nachricht sendet, dass die Refer-Methode unterstützt wird:

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Wenn der SBC nicht angibt, dass „Refer“ eine unterstützte Methode ist, verwendet Direct Routing die erste Option (SIP-Proxy als Weitergegebener). Der SBC muss auch signalisieren, dass er die Notify-Methode unterstützt: Beispiel eines SBC, der angibt, dass die Refer-Methode nicht unterstützt wird:

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

SIP-Proxy verarbeitet „Refer“ vom Client lokal und fungiert als Weitergegebener

Wenn der SBC angibt, dass die Refer-Methode nicht unterstützt wird, fungiert der SIP-Proxy als Weitergegebener. Die vom Client stammende Refer-Anforderung endet beim SIP-Proxy. Die Refer-Anforderung vom Client ist im folgenden Diagramm als Anrufweiterleitung an Dave enthalten. Weitere Informationen finden Sie im Abschnitt 7.1 von RFC 3892.

SIP-Proxy sendet „Refer“ an den SBC und fungiert als Weitergeber

SIP-Proxy als Weitergeber ist die bevorzugte Methode für Anrufweiterleitungen.

Der Standard wird im Abschnitt 6 von RFC 5589 erläutert. Die zugehörigen RFCs sind:

• Session Initiation Protocol (SIP) Call Control - Transfer

• Session Initiation Protocol (SIP) "Replaces" Header

• Session Initiation Protocol (SIP) "Referred-By" mechanism

Bei dieser Option wird davon ausgegangen, dass der SIP-Proxy als Weitergeber fungiert und eine Refer-Nachricht an den SBC sendet. Der SBC fungiert als Weitergegebener und verarbeitet „Refer“, um ein neues Angebot für die Weitergabe zu generieren. Es gibt zwei mögliche Fälle:

• Der Anruf wird an einen externen PSTN-Teilnehmer bzw. an eine externe PSTN-Teilnehmerin weitergeleitet.
• Der Aufruf wird über den SBC zwischen zwei SDK-Endpunkten in der gleichen Ressource weitergeleitet.

Wenn der Anruf über den SBC zwischen zwei SDK-Endpunkten in der gleichen Ressource weitergeleitet wird, wird erwartet, dass der SBC unter Verwendung der Informationen aus der Refer-Nachricht eine neue Einladung für das Weiterleitungsziel ausgibt (also einen neuen Dialog startet). Um die Felder „To“ bzw. „Transferor“ für die Transaktion der Anforderung intern aufzufüllen, muss der SIP-Proxy diese Informationen innerhalb des REFER-TO- bzw. REFERRED-BY-Headers übermitteln. Der SIP-Proxy erstellt „REFER-TO“ als SIP-URI, der sich aus einem SIP-Proxy-FQDN im Hostnamen und einer der folgenden Optionen zusammensetzt:

• Eine E.164-Telefonnummer im Benutzernamenteil des URI, falls das Übertragungsziel eine Telefonnummer ist. Oder:

• Die Parameter „x-m“ und „x-t“, die die vollständige Weiterleitungsziel-MRI bzw. die Kommunikationsressourcen-ID codieren.

Der REFERRED-BY-Header verfügt über einen SIP-URI mit darin codierter Weitergeber-MRI sowie über die Weitergeberressourcen-ID und andere Übertragungskontextparameter, wie in der folgenden Tabelle gezeigt:

Parameter	Wert	Beschreibung
x-m	MRI	Vollständige MRI des Weitergebers bzw. Weitergabeziels (gemäß Auffüllung durch CC)
x-t	Mandanten-ID	x-t-Ressourcen-ID: Optionale Ressourcen-ID (gemäß Auffüllung durch CC)
x-ti	Korrelations-ID für den Weitergeber	Korrelations-ID des Anrufs für den Weitergeber
x-tt	Anruf-URI für das Weitergabeziel	Codierter Anrufersatz-URI

Die Größe des Refer-Headers kann in diesem Fall bis zu 400 Symbole betragen. Der SBC muss die Behandlung von Refer-Nachrichten mit einer Größe von bis zu 400 Symbolen unterstützen.

Anrufumleitung

Ein Azure Communication Services Call Automation SDK kann eingehende Anrufe an eine andere Nummer oder an ein anderes SDK bzw. an einen anderen Teams-Endpunkt umleiten, parallel bei einem anderen Benutzer bzw. bei einer anderen Benutzerin oder bei anderen Benutzern bzw. Benutzerinnen klingeln (gleichzeitiges Klingeln) oder bei einer Gruppe von Benutzern bzw. Benutzerinnen oder Nummern klingeln. Ziehen Sie Folgendes in Betracht:

• Der Anforderungs-URI in der INVITE-Anforderung des SIP-Proxys für den Benutzer C bzw. die Benutzerin C enthält den Parameter cause.

• Der History-Info-Header ist aufgefüllt.

• Wenn Benutzer A bzw. Benutzerin A ein anderer PSTN-Benutzer bzw. eine andere PSTN-Benutzerin ist, generiert der SIP-Proxy die vorläufige Antwort „SIP SIP/2.0 181 Call is being forwarded“ für den Benutzer A bzw. für die Benutzerin A.

• Falls Benutzer A bzw. Benutzerin A und Benutzer C bzw. Benutzerin C PSTN-Benutzer bzw. PSTN-Benutzerinnen ist, behält der SIP-Proxy die vorläufige Antwort „SIP SIP/2.0 181 Call is being forwarded“ bei.

• Der History-Info-Header sollte für die Verhinderung von Schleifen verwendet werden.

Sitzungszeitgeber

Der Sitzungszeitgeber wird vom SIP-Proxy unterstützt (immer angeboten). Die Verwendung des Sitzungszeitgebers durch den SBC ist nicht obligatorisch.

Verwendung des Anforderungs-URI-Parameters „user=phone“

Der SIP-Proxy analysiert den Anforderungs-URI. Ist der Parameter „user=phone“ vorhanden, behandelt der Dienst den Anforderungs-URI als Telefonnummer und gleicht sie mit einem Benutzer bzw. mit einer Benutzerin ab. Ist der Parameter nicht vorhanden, wendet der SIP-Proxy Heuristik an, um den Benutzertyp des Anforderungs-URI (Telefonnummer oder SIP-Adresse) zu ermitteln.

Microsoft empfiehlt, immer den Parameter „user=phone“ anzuwenden, um den Anrufeinrichtungsprozess zu vereinfachen.

History-Info-Header

Hinweis

In Direct Routing von Azure Communication Services ist der History-Info-Header standardmäßig aktiviert und kann nicht deaktiviert werden.

Der History-Info-Header wird zur Neuzuweisung von SIP-Anforderungen verwendet und „stellt einen Standardmechanismus zum Erfassen der Anforderungsverlaufsinformationen bereit, um ein breites Spektrum von Diensten für Netzwerke und Endbenutzer bzw. Endbenutzerinnen zu ermöglichen.“ Weitere Informationen finden Sie im Abschnitt 1.1 von RFC 4244. Für Direct Routing wird dieser Header in Szenarien mit gleichzeitigem Klingeln und Anrufumleitung verwendet.

History-Info wird wie folgt aktiviert:

• Der SIP-Proxy fügt einen Parameter ein, der die zugeordnete Telefonnummer in einzelnen History-Info-Einträgen enthält, aus denen sich der an den PSTN-Controller gesendete History-Info-Header zusammensetzt. Der PSTN-Controller erstellt unter Verwendung von Einträgen, die nur den Telefonnummerparameter enthalten, einen neuen History-Info-Header und übergibt ihn über den SIP-Proxy an den SIP-Trunkanbieter.

• Der History-Info-Header wird für Anwendungsfälle mit gleichzeitigem Klingeln und Anrufumleitung hinzugefügt.

• Für Anwendungsfälle mit Anrufumleitung wird der History-Info-Header nicht hinzugefügt.

• Ein einzelner Verlaufseintrag im neu erstellten History-Info-Header enthält den bereitgestellten Telefonnummernparameter – kombiniert mit dem Direct Routing-FQDN (sip.pstnhub.microsoft.com), der als Hostteil des URI festgelegt wird. Ein Parameter vom Typ „user=phone“, der als Teil des SIP-URI hinzugefügt wird. Beliebige andere Parameter, die dem ursprünglichen History-Info-Header zugeordnet sind (mit Ausnahme von Telefonkontextparametern), die über den neu erstellten History-Info-Header übergeben werden.

  Hinweis

  Private Einträge (gemäß den in Abschnitt 3.3 von RFC 4244 definierten Mechanismen) werden unverändert weitergeleitet, da der SIP-Trunkanbieter ein vertrauenswürdiger Peer ist.

• Eingehende History-Info-Header werden zur Verhinderung von Schleifen beibehalten.

Hier sehen Sie das Format des History-Info-Headers, der vom SIP-Proxy gesendet wird:

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

Wenn der Anruf mehrmals umgeleitet wurde, werden Informationen zu jeder Umleitung in chronologischer Reihenfolge in einer durch Trennzeichen getrennten Liste mit dem entsprechenden Grund eingeschlossen.

Headerbeispiel:

History-Info:
  <sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+113579@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

Der SIP-URI im History-Info-Header wird gemäß Abschnitt 25 von RFC 3261 formatiert (siehe Definition von addr-spec). Im vorherigen Beispiel hat der URI-Header Reason ursprünglich den Text SIP;cause=496;text="User Busy". Die Zeichen ;, " und = werden allerdings mit Escapezeichen versehen, um die entsprechenden ASCII-Hexadezimalwerte %3B, %22 und 3D zu erhalten.

Der History-Info-Header wird durch einen obligatorischen TLS-Mechanismus geschützt.

SBC-Verbindung mit Direct Routing und Failovermechanismus

Weitere Informationen finden Sie unter Anforderungen an die Infrastruktur für direktes Azure-Routing im Abschnitt „Failovermechanismus für die SIP-Signalisierung“.

Retry-After

Wenn ein Direct Routing-Rechenzentrum ausgelastet ist, kann der Dienst eine Retry-After-Nachricht mit einem Intervall von einer Sekunde an den SBC senden. Wenn der SBC eine 503-Nachricht mit einem Retry-After-Header als Reaktion auf eine INVITE-Nachricht empfängt, muss der SBC diese Verbindung beenden und das nächste verfügbare Microsoft-Rechenzentrum verwenden.

Behandeln von Wiederholungen (603-Antwort)

Wenn ein Endbenutzer bzw. eine Endbenutzerin mehrere verpasste Anrufen für einen Anruf feststellt, nachdem der eingehende Anruf abgelehnt wurde, ist der Wiederholungsmechanismus des SBC- oder PSTN-Trunkanbieters falsch konfiguriert. Der SBC muss neu konfiguriert werden, um die Wiederholungsversuche für die 603-Antwort zu beenden.