Direct Routing – SIP-Protokoll

• Gilt für::

  Microsoft Teams

In diesem Artikel wird beschrieben, wie Direct Routing das Session Initiation Protocol (SIP) implementiert. Zum Weiterleiten von Datenverkehr zwischen einem Session Border Controller (SBC) und dem SIP-Proxy müssen einige SIP-Parameter bestimmte Werte aufweisen. Dieser Artikel richtet sich an VoIP-Administratoren, die für die Konfiguration der Verbindung zwischen dem lokalen SBC und dem SIP-Proxydienst verantwortlich sind.

Verarbeiten der eingehenden Anforderung: Suchen des Mandanten und Benutzers

Bevor ein eingehender oder ausgehender Anruf verarbeitet werden kann, werden OPTIONS-Nachrichten zwischen DEM SIP-Proxy und dem SBC ausgetauscht. Diese OPTIONS-Nachrichten ermöglichen es dem SIP-Proxy, SBC die zulässigen Funktionen bereitzustellen. Es ist wichtig, dass die OPTIONS-Aushandlung erfolgreich ist (200OK-Antwort), sodass eine weitere Kommunikation zwischen SBC und SIP-Proxy zum Einrichten von Anrufen ermöglicht wird. Die SIP-Header in einer OPTIONS-Nachricht an den SIP-Proxy werden als Beispiel bereitgestellt:

Parametername	Beispiel für den Wert
Anforderungs-URI	OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Über Header	Über: SIP/2.0/TLS sbc1.adatum.biz:5058; Alias; branch=z9hG4bKac2121518978
Max-Forwards-Header	Max-Forwards:68
Aus Kopfzeile	From Header From: sip:sbc1.adatum.biz:5058
An Kopfzeile	Bis: sip:sip.pstnhub.microsoft.com:5061
CSeq-Header	CSeq: 1 INVITE
Kontaktkopfzeile	Kontakt: sip:sbc1.adatum.biz:50588; transport=tls

Hinweis

Die SIP-Header enthalten keine Userinfos im verwendeten SIP-URI. Gemäß RFC 3261, Abschnitt 19.1.1, ist der userinfo-Teil eines URI optional und kann nicht vorhanden sein, wenn der Zielhost keine Vorstellung von Benutzern hat oder wenn der Host selbst die zu identifizierende Ressource ist. Wenn das @-Zeichen in einem SIP-URI vorhanden ist, darf das Benutzerfeld NICHT leer sein. DER SIPS-URI sollte nicht mit Direct Routing verwendet werden, da er 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, für die Replaces-Header definiert sind.

Bei einem eingehenden Anruf muss der SIP-Proxy den Mandanten finden, an den der Anruf bestimmt ist, und den spezifischen Benutzer innerhalb dieses Mandanten suchen. Der Mandantenadministrator kann Nicht-DID-Nummern (z. B. +1001) in mehreren Mandanten konfigurieren. Daher ist es wichtig, den bestimmten Mandanten zu finden, für den die Nummernsuche durchgeführt werden soll, da die Nicht-DID-Nummern in mehreren Microsoft 365- oder Office 365 Organisationen identisch sein können.

In diesem Abschnitt wird beschrieben, wie der SIP-Proxy den Mandanten und den Benutzer findet und die Authentifizierung des SBC für die eingehende Verbindung ausführt.

Es folgt ein Beispiel für die SIP Invite-Nachricht bei einem eingehenden Anruf:

Parametername	Beispiel für den Wert
Anforderungs-URI	INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
Über Header	Über: SIP/2.0/TLS sbc1.adatum.biz:5058; Alias; branch=z9hG4bKac2121518978
Max-Forwards-Header	Max-Forwards:68
Aus Kopfzeile	From Header From: <sip:+17168712781@sbc1.adatum.biz; transport=udp; tag=1c747237679
An Kopfzeile	An: sip:+183338006777@sbc1.adatum.biz
CSeq-Header	CSeq: 1 INVITE
Kontaktkopfzeile	Kontakt: sip:+17168712781@sbc1.adatum.biz:5058; transport=tls

Beim Empfang der Einladung führt der SIP-Proxy die folgenden Schritte aus:

1. Überprüfen Sie das Zertifikat. Bei der ersten Verbindung verwendet der Direct Routing-Dienst den im Kontaktheader angezeigten FQDN-Namen und gleicht ihn mit dem allgemeinen Namen oder alternativen Antragstellernamen des angezeigten Zertifikats ab. Der SBC-Name muss mit einer der folgenden Optionen übereinstimmen:

   • Option 1. Der vollständige FQDN-Name, der im Contact-Header angezeigt wird, muss mit dem allgemeinen Namen bzw. alternativen Antragstellernamen des angezeigten Zertifikats übereinstimmen.

   • Option 2. Der Domänenteil des FQDN-Namens, der im Contact-Header angezeigt wird (z. B. adatum.biz des FQDN-Namens sbc1.adatum.biz) muss mit dem Wert in Allgemeiner Name/Alternativer Antragstellername (z. B. *.adatum.biz) übereinstimmen.

2. Versuchen Sie, einen Mandanten zu finden, indem Sie den vollständigen FQDN-Namen verwenden, der im Contact-Header angezeigt wird.

   Überprüfen Sie, ob der FQDN-Name aus dem Kontaktheader (sbc1.adatum.biz) als DNS-Name in microsoft 365 oder Office 365 organization registriert ist. Falls gefunden, wird die Suche des Benutzers in dem Mandanten durchgeführt, in dem der SBC-FQDN als Domänenname registriert ist. Wenn sie nicht gefunden wird, gilt Schritt 3.

3. Schritt 3 gilt nur, wenn Schritt 2 fehlgeschlagen ist.

   Entfernen Sie den Hostteil aus dem FQDN, der im Kontaktheader (FQDN: sbc12.adatum.biz nach dem Entfernen des Hostteils: adatum.biz) angezeigt wird, und überprüfen Sie, ob dieser Name als DNS-Name in microsoft 365 oder Office 365 organization registriert ist. Falls gefunden, wird die Benutzersuche in diesem Mandanten durchgeführt. Wenn sie nicht gefunden wird, schlägt der Aufruf fehl.

4. Verwenden Sie die im Anforderungs-URI angegebene Telefonnummer, und führen Sie die umgekehrte Nummernsuche innerhalb des Mandanten aus, der in Schritt 2 oder 3 gefunden wurde. Zuordnen der angezeigten Telefonnummer zu einem SIP-URI des Benutzers innerhalb des Mandanten, der im vorherigen Schritt gefunden wurde.

5. Wenden Sie Trunkeinstellungen an. Suchen Sie die Parameter, die vom Mandantenadministrator für diesen SBC festgelegt wurden.

   Microsoft unterstützt nicht die Verwendung eines SIP-Proxys oder Benutzer-Agent-Servers eines Drittanbieters zwischen dem Microsoft SIP-Proxy und dem gekoppelten SBC, wodurch der vom gekoppelten SBC erstellte Anforderungs-URI geändert werden kann.

   Die Anforderungen für die beiden Nachschlagevorgänge (Schritte 2 und 3), die für das Szenario erforderlich sind, in dem ein SBC mit vielen Mandanten (Netzbetreiberszenario) verbunden ist, werden weiter unten in diesem Artikel behandelt.

Detaillierte Anforderungen für Kontaktheader und Anforderungs-URI

Kontaktkopfzeile

Für alle eingehenden SIP-Nachrichten (OPTIONEN, INVITE) an den Microsoft SIP-Proxy muss der Contact-Header den gekoppelten SBC-FQDN im URI-Hostnamen wie folgt aufweisen:

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

Gemäß RFC 3261, Abschnitt 11.1, kann ein Kontaktheaderfeld in einer OPTIONS-Nachricht vorhanden sein. In Direct Routing ist der Kontaktheader erforderlich. Bei INVITE-Nachrichten im obigen Format kann für OPTIONS-Nachrichten die Userinfo aus dem SIP-URI entfernt werden, und nur der FQDN wird im folgenden Format gesendet:

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

Dieser Name (FQDN) muss sich auch in den Feldern Allgemeiner Name oder Alternativer Antragstellername des angezeigten Zertifikats enthalten. Microsoft unterstützt die Verwendung von Wildcardwerten der Namen in den Feldern Allgemeiner Name oder alternativer Antragstellername des Zertifikats.

Die Unterstützung für Wildcards wird in RFC 2818, Abschnitt 3.1 beschrieben. Speziell:

"Namen können das Wildcardzeichen * enthalten, das als mit einer einzelnen Domänennamenkomponente oder einem Komponentenfragment übereinstimmt. *.a.com entspricht beispielsweise foo.a.com, aber nicht bar.foo.a.com. f*.com entspricht foo.com, aber nicht bar.com."

Wenn mehr als ein Wert im Contact-Header, der in einer SIP-Nachricht angezeigt wird, vom SBC gesendet wird, wird nur der FQDN-Teil des ersten Werts des Contact-Headers verwendet.

Für Direct Routing ist es wichtig, dass der FQDN zum Auffüllen des SIP-URI anstelle der IP-Adresse verwendet wird. Eine eingehende INVITE- oder OPTIONS-Nachricht an den SIP-Proxy mit Kontaktheader, bei der der Hostname durch ip und nicht durch FQDN dargestellt wird, wird die Verbindung mit 403 Forbidden abgelehnt.

Anforderungs-URI

Für alle eingehenden Anrufe wird der Anforderungs-URI verwendet, um die Telefonnummer einem Benutzer zuzuordnen.

Derzeit muss die Telefonnummer ein Pluszeichen (+) enthalten, wie im folgenden Beispiel gezeigt.

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

Aus Kopfzeile

Für alle eingehenden Anrufe wird der From-Header verwendet, um die Telefonnummer des Anrufers mit der Liste der blockierten Telefonnummern des Angerufenen abzugleichen, und wird verwendet, um eine umgekehrte Nummernsuche durchzuführen, um den Namen des Anrufers aus vorhandenen Mandanten- und Benutzerdatensätzen zu finden.

Damit diese Nachschlagevorgänge funktionieren, muss die Telefonnummer ein + enthalten, wie im folgenden Beispiel gezeigt.

From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679

Überlegungen zu Kontakt- und Record-Route-Headern

Der SIP-Proxy muss den FQDN des nächsten Hops für neue In-Dialog-Clienttransaktionen (z. B. Bye oder Erneutes Einladen) und beim Antworten auf SIP-Optionen berechnen. Es werden Entweder Kontakt oder Record-Route verwendet.

Gemäß RFC 3261, Abschnitt 8.1.1.8, ist der Kontaktheader in jeder Anforderung erforderlich, die zu einem neuen Dialog führen kann. Die Record-Route ist nur erforderlich, wenn ein Proxy den Pfad zukünftiger Anforderungen in einem Dialog beibehalten möchte. Wenn ein Proxy-SBC mit der Optimierung lokaler Medien für Direct Routing verwendet wird, muss eine Datensatzroute konfiguriert werden, da der Proxy-SBC in der Route bleiben muss.

Microsoft empfiehlt, nur den Kontaktheader zu verwenden, wenn kein Proxy-SBC verwendet wird:

• Gemäß RFC 3261, Abschnitt 20.30, wird Record-Route verwendet, wenn ein Proxy auf dem Pfad zukünftiger Anforderungen in einem Dialogfeld bleiben möchte. Dies ist nicht wichtig, wenn kein Proxy-SBC konfiguriert ist, da der gesamte Datenverkehr zwischen dem Microsoft SIP-Proxy und dem gekoppelten SBC erfolgt.

• Der Microsoft SIP-Proxy verwendet nur den Contact-Header (nicht Record-Route), um den nächsten Hop beim Senden von Optionen für ausgehende Pings zu bestimmen. Das Konfigurieren von nur einem Parameter (Contact) anstelle von zwei Parametern (Contact und Record-Route) vereinfacht die Verwaltung, wenn kein Proxy-SBC verwendet wird.

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

• Priorität 1. Record-Route der obersten Ebene. Wenn der Record-Route der obersten Ebene den FQDN-Namen enthält, wird der FQDN-Name verwendet, um die ausgehende In-Dialog-Verbindung herzustellen.

• Priorität 2. Kontaktheader. Wenn Record-Route nicht vorhanden ist, sucht der SIP-Proxy den Wert des Contact-Headers, um die ausgehende Verbindung herzustellen. (Dies ist die empfohlene Konfiguration.)

Wenn sowohl Contact als auch Record-Route verwendet werden, muss der SBC-Administrator seine Werte identisch halten, was zu Verwaltungsaufwand führt.

Verwendung des FQDN-Namens in Kontakt oder Record-Route

Die Verwendung einer IP-Adresse wird in Record-Route oder Kontakt nicht unterstützt. Die einzige unterstützte Option ist ein FQDN, der entweder mit dem allgemeinen Namen oder dem alternativen Antragstellernamen des SBC-Zertifikats übereinstimmen muss (Die Im Zertifikat enthaltenen Wildcardwerte werden unterstützt).

• Wenn eine IP-Adresse unter Datensatzroute oder Kontakt angezeigt wird, schlägt die Zertifikatüberprüfung fehl, und der Anruf schlägt fehl.

• Wenn der FQDN nicht mit dem Wert des allgemeinen oder alternativen Antragstellernamens im angezeigten Zertifikat übereinstimmt, schlägt der Aufruf fehl.

Eingehender Anruf: Beschreibung des SIP-Dialogfelds

In der folgenden Tabelle sind die Anrufflussunterschiede und -ähnlichkeiten zwischen Nichtumgehungs- und Umgehungsmodi zusammengefasst:

Parametername	Nicht-Umgehungsmodus	Umgehungsmodus
Medienkandidaten in 183 und 200 Nachrichten von	Medienprozessoren	Clients
Anzahl von 183 Nachrichten, die SBC empfangen kann	Eine pro Sitzung	Mehrere
Anruf kann mit vorläufiger Antwort sein (183)	Ja	Ja
Anruf kann ohne vorläufige Antwort erfolgen (183)	Ja	Ja

Nicht-Medienumgehungsfluss

Ein Teams-Benutzer verfügt möglicherweise über mehrere Endpunkte gleichzeitig. Beispielsweise Teams für Windows-Client, Teams für iPhone-Client und Teams Telefon (Teams Android-Client). Jeder Endpunkt kann einen HTTP-Rest wie folgt signalisieren:

• Anrufstatus – wird vom SIP-Proxy in die SIP-Nachricht 180 konvertiert. Beim Empfang der Nachricht 180 muss der SBC lokales Klingeln generieren.

• Medienantwort– wird vom SIP-Proxy in die Nachricht 183 mit Medienkandidaten im Session Description Protocol (SDP) konvertiert. Beim Empfang der Nachricht 183 erwartet der SBC, eine Verbindung mit den Medienkandidaten herzustellen, die in der SDP-Nachricht empfangen wurden.

  Hinweis

  In einigen Fällen wird die Medienantwort möglicherweise nicht generiert, und der Endpunkt kann mit der Meldung "Anruf akzeptiert" antworten.

• Anruf akzeptiert: Vom SIP-Proxy in die SIP-Nachricht 200 mit SDP konvertiert. Beim Empfang der Nachricht 200 wird erwartet, dass der SBC Medien an und von den bereitgestellten SDP-Kandidaten sendet und empfängt.

  Hinweis

  Direct Routing unterstützt keine verzögerte Angebotseinladung (Invite without SDP).

Mehrere Endpunkte klingeln mit vorläufiger Antwort

1. Beim Empfang der ersten Einladung vom SBC sendet der SIP-Proxy die Meldung "SIP SIP/2.0 100 Trying" und benachrichtigt alle Endbenutzerendpunkte über den eingehenden Anruf.

2. Nach der Benachrichtigung beginnt jeder Endpunkt zu klingeln und "Anrufstatus"-Meldungen an den SIP-Proxy zu senden. Da ein Teams-Benutzer über mehrere Endpunkte verfügen kann, empfängt der SIP-Proxy möglicherweise mehrere Anrufstatusmeldungen.

3. Für jede Von den Clients empfangene Anrufstatusmeldung konvertiert der SIP-Proxy die Anrufstatusmeldung in die SIP-Nachricht "SIP SIP/2.0 180 Klingeln". Das Intervall für das Senden solcher Nachrichten wird durch das Intervall der empfangenden Nachrichten vom Anrufcontroller definiert. Im folgenden Diagramm werden zwei 180 Nachrichten vom SIP-Proxy generiert. Diese Nachrichten stammen von den beiden Teams-Endpunkten des Benutzers. Die Clients 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 "An" ist anders). Ein Endpunkt generiert jedoch möglicherweise nicht die Nachricht 180 und sendet die Nachricht 183 nicht sofort, 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 Meldung "SIP 183-Sitzungsstatus", wobei die SDP vom Client durch die SDP des Medienprozessors ersetzt wird. Im folgenden Diagramm hat der Endpunkt aus Fork 2 den Anruf angenommen. Wenn der Trunk nicht umgangen wird, wird die 183-SIP-Nachricht nur einmal generiert (entweder RingBot oder ClientEndpunkt). Die 183 kann auf einen vorhandenen Fork kommen oder einen neuen Fork starten.

5. Eine Anrufannahmenachricht wird mit den endgültigen Kandidaten des Endpunkts gesendet, der den Anruf angenommen hat. Die Anrufannahmenachricht wird in die SIP-Nachricht 200 konvertiert.

Mehrere Endpunkte klingeln ohne vorläufige Antwort

1. Beim Empfang der ersten Einladung vom SBC sendet der SIP-Proxy die Meldung "SIP SIP/2.0 100 Trying" und benachrichtigt alle Endbenutzerendpunkte über den eingehenden Anruf.

2. Nach der Benachrichtigung beginnt jeder Endpunkt zu klingeln und sendet die Meldung "Anrufstatus" an den SIP-Proxy. Da ein Teams-Benutzer mehrere Endpunkte haben kann, empfängt der SIP-Proxy möglicherweise mehrere Anrufstatusmeldungen.

3. Für jede von den Clients empfangene Anrufstatusmeldung konvertiert der SIP-Proxy die Anrufstatusmeldung in die SIP-Nachricht "SIP SIP/2.0 180 Trying". Das Intervall zum Senden der Nachrichten wird durch das Intervall für den Empfang der Nachrichten vom Anrufcontroller definiert. Im folgenden Diagramm werden zwei 180 Nachrichten vom SIP-Proxy generiert, was bedeutet, dass sich der Benutzer bei drei Teams-Clients angemeldet hat und jeder Client den Anrufstatus sendet. Jede Nachricht ist eine separate Sitzung (Der Parameter "tag" im Feld "An" unterscheidet sich).

4. Eine Anrufannahmenachricht wird mit den endgültigen Kandidaten des Endpunkts gesendet, der den Anruf angenommen hat. Die Anrufannahmenachricht wird in die SIP-Nachricht 200 konvertiert.

Medienumgehungsfluss

Die gleichen Nachrichten (100 Trying, 180, 183) werden im Medienumgehungsszenario verwendet.

Das folgende Schema zeigt ein Beispiel für den Umgehungsaufrufflow.

Hinweis

Die Medienkandidaten können von verschiedenen Endpunkten stammen.

Option "Replaces"

Der SBC muss Invite with Replaces unterstützen.

Überlegungen zur Größe von SDP

Die Direct Routing-Schnittstelle sendet möglicherweise eine SIP-Nachricht, die 1.500 Byte überschreitet. Dies ist in erster Linie durch die Größe von SDP verursacht. Wenn sich jedoch ein UDP-Trunk hinter dem SBC befindet, kann er die Nachricht ablehnen, wenn sie vom Microsoft SIP-Proxy unverändert an den Trunk weitergeleitet wird. Microsoft empfiehlt, beim Senden der Nachricht an die UDP-Trunks einige Werte in SDP auf dem SBC zu entfernen. Beispielsweise können die ICE-Kandidaten oder nicht verwendeten Codecs entfernt werden.

Anrufweiterleitung

Direct Routing unterstützt zwei Methoden für die Anrufübertragung:

• Option 1. SIP-Proxyprozesse Beziehen Sie sich lokal vom Client und fungiert als Referee, wie in Abschnitt 7.1 von RFC 3892 beschrieben.

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

• Option 2. Der SIP-Proxy sendet den Verweis auf den SBC und fungiert als Transferor, wie in Abschnitt 6 von RFC 5589 beschrieben.

  Bei dieser Option sendet der SIP-Proxy einen Verweis auf den SBC und erwartet, dass der SBC die Übertragung vollständig verarbeitet.

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 Option 2 für Anrufübertragungen.

Im Folgenden finden Sie ein Beispiel für einen SBC, der die Meldung 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 Als unterstützte Methode bezeichnet wird, verwendet Direct Routing Option 1 (SIP-Proxy fungiert als Referee). Der SBC muss auch signalisieren, dass er die Notify-Methode unterstützt:

Beispiel für SBC, der angibt, dass die Refer-Methode nicht unterstützt wird:

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

SIP-Proxyprozesse Beziehen Sie sich vom Client lokal und fungiert als Referee.

Wenn der SBC angibt, dass die Refer-Methode nicht unterstützt wird, fungiert der SIP-Proxy als Referee.

Die Refer-Anforderung, die vom Client stammt, wird auf dem SIP-Proxy beendet. Die Referenzanforderung vom Client wird im folgenden Diagramm als "Anrufübertragung an Dave" angezeigt. Weitere Informationen finden Sie in Abschnitt 7.1 von RFC 3892.

DER SIP-Proxy sendet den Verweis auf den SBC und fungiert als Transferor.

Dies ist die bevorzugte Methode für Anrufübertragungen und obligatorisch für Geräte, die eine Medienumgehungszertifizierung anfordern. Die Anrufübertragung, ohne dass der SBC "Refer" verarbeiten kann, wird im Medienumgehungsmodus nicht unterstützt.

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

• SIP-Anrufsteuerung (Session Initiation Protocol) – Übertragung

• Sip-Header (Session Initiation Protocol) "Replaces"

• Sip-Mechanismus (Session Initiation Protocol) "Verwiesen von"

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

• Der Anruf wird an einen externen PSTN-Teilnehmer übertragen.
• Der Anruf wird von einem Teams-Benutzer an einen anderen Teams-Benutzer im gleichen Mandanten über den SBC übertragen.

Wenn der Anruf von einem Teams-Benutzer über den SBC an einen anderen weitergeleitet wird, wird erwartet, dass der SBC eine neue Einladung (starte einen neuen Dialog) für das Übertragungsziel (den Teams-Benutzer) unter Verwendung der in der Refer-Nachricht empfangenen Informationen ausgibt.

Um die Felder an/Transferor für die Transaktion der Anforderung intern aufzufüllen, muss der SIP-Proxy diese Informationen in den REFER-TO/REFER-BY-Headern übermitteln.

Der SIP-Proxy bildet refer-to als SIP-URI, der aus einem SIP-Proxy-FQDN im Hostnamen und einem der folgenden Komponenten besteht:

• Eine E.164-Telefonnummer im Benutzernamenteil des URI für den Fall, dass das Übertragungsziel eine Telefonnummer ist, oder

• x-m- und x-t-Parameter, die die vollständige MRT- und Mandanten-ID des Übertragungsziels codieren

Der REFERRED-BY-Header ist ein SIP-URI, in dem die Übertragungs-MRI und die Übertragungsmandanten-ID und andere Übertragungskontextparameter codiert sind, wie in der folgenden Tabelle dargestellt:

Parameter	Wert	Beschreibung
x-m	MRI	Vollständige MRT des Übertragungs-/Übertragungsziels, wie von CC aufgefüllt
x-t	Mandanten-ID	x-t Mandanten-ID Optionale Mandanten-ID, wie von CC aufgefüllt
x-ti	Korrelations-ID des Übertragungsanbieters	Korrelations-ID des Aufrufs des Übertragungsanbieters
x-tt	Zielaufruf-URI übertragen	Codierter Aufrufersetzungs-URI

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

Anrufweiterleitung

Ein Teams-Benutzer kann eingehende Anrufe an eine andere Nummer oder einen Anderen Teams-Benutzer weiterleiten, andere Benutzer oder Benutzer parallel anrufen (gleichzeitig klingeln) oder eine Gruppe von Benutzern oder Nummern anrufen. Berücksichtigen Sie dabei Folgendes:

• Der Anforderungs-URI in der INVITE-Anforderung vom SIP-Proxy an Benutzer C enthält den Cause-Parameter .

• Basierend auf Trunkkonfigurationen (ForwardCallHistory-Parameter ) wird der History-Info-Header aufgefüllt.

• Wenn Benutzer A ein anderer PSTN-Benutzer ist, generiert der SIP-Proxy die vorläufige Antwort "SIP SIP/2.0 181 Anruf wird weitergeleitet" an Benutzer A.

• Wenn Benutzer A und Benutzer C PSTN-Benutzer sind, behält der SIP-Proxy die vorläufige Antwort "SIP SIP/2.0 181 Anruf wird weitergeleitet" bei.

• Der History-Info-Header sollte für die Schleifenverhinderung verwendet werden.

Sitzungszeitgeber

Der SIP-Proxy unterstützt (bietet immer) den Sitzungszeitgeber für Anrufe ohne Umgehung, bietet ihn aber nicht bei Umgehungsanrufen an. Die Verwendung des Sitzungszeitgebers durch den SBC ist nicht obligatorisch.

Verwendung des Request-URI-Parameters user=phone

Der SIP-Proxy analysiert den Anforderungs-URI. Wenn der Parameter user=phone vorhanden ist, verarbeitet der Dienst den Anforderungs-URI als Telefonnummer, wobei die Nummer einem Benutzer zugeordnet wird. Wenn der Parameter nicht vorhanden ist, wendet der SIP-Proxy Heuristiken an, um den Anforderungs-URI-Benutzertyp (Telefonnummer oder SIP-Adresse) zu bestimmen.

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

History-Info-Header

Der History-Info-Header wird verwendet, um SIP-Anforderungen neu zuzuordnen und "einen Standardmechanismus zum Erfassen der Anforderungsverlaufsinformationen bereitzustellen, um eine Vielzahl von Diensten für Netzwerke und Endbenutzer zu ermöglichen". Weitere Informationen finden Sie unter RFC 4244 – Abschnitt 1.1. Für Microsoft Phone System wird dieser Header in Simulring- und Anrufweiterleitungsszenarien verwendet.

Beim Senden wird die History-Info wie folgt aktiviert:

• Der SIP-Proxy fügt einen Parameter mit der zugeordneten Telefonnummer in einzelne History-Info Einträge ein, die den an den PSTN-Controller gesendeten History-Info-Header bilden. Der PSTN-Controller erstellt einen neuen History-Info-Header neu und übergibt ihn über den SIP-Proxy an den SIP-Trunkanbieter.

• History-Info-Header wird für fälle der gleichzeitigen Anruf- und Anrufweiterleitung hinzugefügt.

• History-Info-Header wird für Anrufübertragungsfälle nicht hinzugefügt.

• Ein einzelner Verlaufseintrag im rekonstruierten History-Info-Header verfügt über den angegebenen Telefonnummernparameter in Kombination mit dem direct routing-FQDN (sip.pstnhub.microsoft.com), der als Hostteil des URI festgelegt ist. Der Parameter "user=phone" wird als Teil des SIP-URI hinzugefügt. Alle anderen Parameter, die dem ursprünglichen History-Info-Header zugeordnet sind, mit Ausnahme von Telefonkontextparametern, werden im neu erstellten History-Info-Header übergeben.

  Hinweis

  Einträge, die privat sind (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 werden beibehalten, wenn der ForwardCallHistory-Parameter aktiviert ist. Beibehaltene History-Info können zur Schleifenverhinderung verwendet werden.

Es folgt das Format des Vom SIP-Proxy gesendeten History-info-Headers:

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

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

Headerbeispiel:

History-Info:
  <sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+14257123456@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 ist gemäß Abschnitt 25 von RFC 3261 formatiert (siehe Definition von addr-spec). Im vorherigen Beispiel ist SIP;cause=496;text="User Busy"der ursprüngliche Text des URI-Headers Reason , der die ;Zeichen , "und = mit Escapezeichen zu ihren ASCII-Hexadezimwerten %3B, %22bzw3D. mit Escapezeichen versehen wird.

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

SBC-Verbindung mit Direct Routing und Failovermechanismus

Weitere Informationen finden Sie im Abschnitt Failovermechanismus für SIP-Signalisierung in Plan for Direct Routing( Plan for Direct Routing).

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 als Reaktion auf eine INVITE eine 503-Nachricht mit einem Retry-After-Header empfängt, muss der SBC diese Verbindung beenden und das nächste verfügbare Microsoft-Rechenzentrum ausprobieren.

Behandeln von Wiederholungen (Antwort 603)

Wenn ein Endbenutzer mehrere verpasste Anrufe für einen Anruf beobachtet, nachdem er den eingehenden Anruf abgelehnt hat, bedeutet dies, dass der Wiederholungsmechanismus des SBC- oder PSTN-Trunkanbieters falsch konfiguriert ist. Der SBC muss neu konfiguriert werden, um die Wiederholungsversuche für die Antwort 603 zu beenden.

ICE-Neustart: Medienumgehungsaufruf, der an einen Endpunkt übertragen wird, der keine Medienumgehung unterstützt

Der SBC muss ICE-Neustarts unterstützen, wie in RFC 5245, Abschnitt 9.1.1.1 beschrieben.

Der Neustart in Direct Routing wird gemäß den folgenden Absätzen des RFC implementiert:

Um ICE neu zu starten, MUSS ein Agent sowohl ice-pwd als auch ice-ufrag für den Medienstream in einem Angebot ändern. Es ist zulässig, ein Attribut auf Sitzungsebene in einem Angebot zu verwenden, aber dasselbe ice-pwd oder ice-ufrag als Attribut auf Medienebene in einem nachfolgenden Angebot bereitzustellen. Dies ist keine Änderung des Kennworts, nur eine Änderung der Darstellung und führt nicht zu einem ICE-Neustart.

Ein Agent legt die restlichen Felder im SDP für diesen Medienstream wie in einem ersten Angebot dieses Medienstreams fest (siehe Abschnitt 4.3). Daher kann die Gruppe der Kandidaten einige, keine oder alle der vorherigen Kandidaten für diesen Stream enthalten, und KANN eine neue Gruppe von Kandidaten enthalten, die wie in Abschnitt 4.1.1 beschrieben gesammelt wurden.

Wenn der Anruf ursprünglich mit Medienumgehung eingerichtet wurde und der Anruf an einen Skype for Business-Client übertragen wird, muss Direct Routing einen Medienprozessor einfügen. Dies liegt daran, dass Direct Routing nicht mit einem Skype for Business-Client mit Medienumgehung verwendet werden kann. Direct Routing startet den ICE-Neustartprozess, indem ice-pwd und ice-ufrag geändert und neue Medienkandidaten in einer Wiedereinladung angeboten werden.