Auf Englisch lesen

Freigeben über


Direct Routing: Definitionen und RFC-Standards

In diesem Artikel wird beschrieben, wie Teams Telefon Direct Routing Standardprotokolle verwendet, die von rfc (Requests for Comments) der Internet Engineering Task Force definiert werden. Dieser Artikel richtet sich an Sprachadministratoren, die für die Konfiguration der Verbindung zwischen dem lokalen Session Border Controller (SBC) und dem SIP-Proxydienst (Session Initiation Protocol) verantwortlich sind.

Der Kunden-SBC ist mit den folgenden Komponenten im Microsoft Teams-Back-End verknüpft:

  • Der SIP-Proxy für die Signalisierung. Diese Komponente ist die Komponente mit Internetzugriff von Direct Routing, die SIP-Verbindungen (TLS) zwischen den SBCs und Direct Routing verarbeitet.

  • Die Medienprozessoren für Medien. Diese Komponente ist die Komponente mit Internetzugriff von Direct Routing, die Mediendatenverkehr verarbeitet. Diese Komponente verwendet SRTP- und SRTCP-Protokolle.

Weitere Informationen zu Direct Routing finden Sie unter Teams Telefon Direct Routing.

Weitere Informationen zur Implementierung des SIP-Protokolls durch Direct Routing finden Sie unter Direct Routing – SIP-Protokoll.

RFC-Standards

Direct Routing entspricht den RFC-Standards. Der SBC, der mit Direct Routing verbunden ist, muss auch die folgenden RFCs (oder deren Nachfolger) erfüllen.

Standards, die für Geräte gelten, die nicht den Medienumgehungsmodus unterstützen

Die folgenden Standards gelten für Geräte, die nur den Nicht-Medienumgehungsmodus unterstützen:

  • RFC 3261 SIP: Sitzungsinitiierungsprotokoll
  • RFC 3325 Private Erweiterung zum Sitzungsinitiierungsprotokoll für die bestätigten Identitäten in vertrauenswürdigen Netzwerken: Abschnitte zur Behandlung des P-Asserted-Identity-Headers. Direct Routing sendet P-Asserted-Identity mit Datenschutz-ID-Headern.
  • RFC 4244 Eine Erweiterung des Session Initiation Protocol (SIP) für erforderliche Verlaufsinformationen. Weitere Informationen finden Sie auch unter Routing SIP-Protokollbeschreibung.
  • RFC 3892 Der Referred-By-Mechanismus des Sitzungsinitiierungsprotokolls
  • RFC 3891 Der SIP-Header (Session Initiation Protocol) "Replaces"
  • RFC 6337 Sip-Nutzung (Session Initiation Protocol) des Angebots-/Antwortmodells. Weitere Informationen finden Sie im Abschnitt "Abweichungen von RFC".
  • RFC 3711 und RFC 4771. Schützen sie RTP-Datenverkehr mithilfe von SRTP. Der SBC muss in der Lage sein, Schlüssel mithilfe von SDES einzurichten.
  • RFC 8035 SDP-Angebots-/Antwort-Klarstellungen für RTP/RTCP-Multiplexing

Standards für Geräte, die den Medienumgehungsmodus unterstützen

Zusätzlich zu den Als anwendbar aufgeführten Standards für den Nonbypass-Modus werden die folgenden Standards für den Medienumgehungsmodus verwendet:

Normen, die für die Unterstützung der Übermittlung von Standortinformationen an E911-Anbieter gelten

Abweichungen von den RFCs

In der folgenden Tabelle sind die Abschnitte der RFCs aufgeführt, in denen die Implementierung des SIP- oder Medienstapels durch Microsoft vom Standard abweicht:

RFC und Abschnitte Beschreibung Abweichung
RFC 6337, Abschnitt 5.3 Halten und Fortsetzen von Medien RFC ermöglicht die Verwendung von "a=inactive", "a=sendonly", a=recvonly", um einen Aufruf in die Warteschleife zu setzen. Der SIP-Proxy unterstützt nur "a=inactive" und versteht nicht, ob der SBC "a=sendonly" oder "a=recvonly" sendet.
RFC 6337, Abschnitt 5.4 Verhalten beim Empfangen von SDP mit c=0.0.0.0 RFC3264 erfordert, dass ein Agent SDP mit einer Verbindungsadresse von 0.0.0.0 empfangen kann, was angibt, dass RTP oder RTCP nicht an den Peer gesendet werden soll. Der SIP-Proxy unterstützt diese Option nicht.
RFC 3261, Abschnitt 25 Erweiterter BNF für das SIP-Protokoll Das Zeichen "#" sollte als "%23" gesendet werden. Der SIP-Proxy sendet das Zeichen "#" in einem Anforderungs-URI ohne Escapezeichen.
RFC 3264, Abschnitt 8.3.1 Ein Angebot/Antwortmodell mit SDP RFC 3264 enthält einen MAY-Mechanismus (optional) zur Medienretarierung, der das Ändern des Medienports, der IP-Adresse oder des Transports nach dem Festlegen der Sitzung ermöglicht. Optionale Medienneuzuweisungen werden nicht unterstützt. Während eines Anrufs werden SIP-Anforderungen zum Aktualisieren des Medienports, der IP-Adresse oder des Transports nicht unterstützt. Medien werden nicht an das aktualisierte Sitzungsziel gesendet. Medien aus Direct Routing fließen weiterhin zum ursprünglichen Ziel.

Hinweis von RFC, der die Auswahl unterstützt; Der Anbieter MUSS darauf vorbereitet sein, Medien sowohl am alten als auch am neuen Port zu empfangen, sobald das Angebot gesendet wird. Der Anbieter SOLLTE nicht aufhören, auf Medien am alten Port zu lauschen, bis die Antwort empfangen wird und Medien am neuen Port eintreffen.|

Überlegungen zum TCP/TLS-Transport

Wenn der SIP-Proxy von Microsoft eine SIP-Anforderung (neu oder dialogintern) sendet, kann er eine neue TCP/TLS-Verbindung öffnen oder eine vorhandene Verbindung wiederverwenden, sofern vorhanden.

  • Pro Remote-FQDN/IP sind pro SIP-Proxy-VM maximal zwei TCP/TLS-Verbindungen zulässig. Vor dem Senden einer SIP-Anforderung überprüft der SIP-Proxy aktive TCP-Verbindungen mit der aufgelösten IP-Adresse des Ziel-SBC/Trunk-FQDNs. Wenn zwei Verbindungen vorhanden sind, werden sie wiederverwendet. Wenn keine zwei Verbindungen vorhanden sind, wird eine neue Verbindung geöffnet.

    • Diese Logik gilt pro virtuellem SIP-Proxycomputer.

    • SIP-Proxy-IP-Adressen werden von mehreren virtuellen Computern pro Region gewartet.

    • Aus Sicht des SBC können mehrere eingehende Proxyverbindungen aus allen SIP-Proxyregionen vorhanden sein.

  • Die TCP/TLS-Verbindungen, die vom SIP-Proxy geöffnet werden, bleiben nicht unbedingt geöffnet, solange der Aufruf dies tut. Die Verbindung wird jedoch nicht sofort nach einer Antwort auf eine SIP-Anforderung geschlossen. Wenn für eine Verbindung kein Timeout besteht, wird sie möglicherweise für andere SIP-Anforderungen wiederverwendet.

  • Der SIP-Proxy unterstützt kein Verbindungsaliasing, wie in RFC 5923: Connection Reuse in the Session Initiation Protocol (SIP) beschrieben.

    • Ausgehende SIP-Proxy-TCP-Verbindungen verarbeiten nur ausgehende SIP-Proxyanforderungen (an SBCs) und zugehörige Antworten.

    • Eingehende SIP-Proxy-TCP-Verbindungen (von SBCs) verarbeiten nur eingehende SIP-Anforderungen und zugehörige Antworten.

Beachten Sie, dass in bestimmten Situationen Gateways/SBCs von Drittanbietern tls-Verbindungszurücksetzungen für O365-Dienste kennzeichnen können. Das Verhalten der Verbindungszurücksetzung ist zu erwarten, da neue Verbindungen dynamisch erstellt werden, ohne die Benutzererfahrung zu beeinträchtigen.

Timeoutrichtlinien

  • Das TCP-Leerlauftimeout des SIP-Proxys beträgt zwei Minuten. Der Timer wird zurückgesetzt, wenn eine SIP-Transaktion über die Verbindung erfolgt.

  • Der SIP-Proxy sendet die Anwendung CRLF keep-alive gemäß RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP).

    • Keep-Alive setzt den TCP-Leerlauftimer nicht zurück.

    • CRLF Keep-Alive, das vom Lieferanten-SBC gesendet wird, setzt den TCP-Leerlauftimer zurück.

  • Aufgrund der zuvor erwähnten Aliasingeinschränkung darf der Anbieter-SBC keine DIALOG-SIP-Anforderungen verwenden, um den Timer bei Verbindungen zurückzusetzen, die vom SIP-Proxy ausgehend an den Lieferanten-SBC erstellt wurden.

  • Nach zwei Minuten Leerlauf (FIN, ACK) wird innerhalb von ca. 10 bis 20 Sekunden per SIP-Proxy an den Lieferanten-SBC übertragen.

Hinweise

  • Der SBC sollte Verbindungen wie sip proxy aktiv wiederverwenden. Diese Methode spart Zeit, die für TCP- und TLS-Verbindungen benötigt wird.

  • Der SBC sollte die Verbindung mindestens einmal pro Stunde erneuern.

  • Wenn ein neues SBC-Zertifikat hochgeladen wird, muss der SBC alle Verbindungen erneuern.

  • Wenn Domänenkonfigurationen aktualisiert werden, wird empfohlen, dass die SBC-Verbindungen erneuert werden. Andernfalls wird eine neue Konfiguration angewendet, nachdem der interne SIP-Proxycache erneuert wurde – bis zu vier Stunden.

Betriebsmodi

Es gibt zwei Betriebsmodi für Direct Routing:

  • Ohne Medienumgehung , bei der der gesamte RTP-Datenverkehr zwischen dem Teams-Client, den Medienprozessoren und dem SBC fließt.

  • Mit Medienumgehung , bei der alle RTP-Medien zwischen den Teams-Endpunkten und dem SBC fließen.

SIP-Datenverkehr fließt immer über den SIP-Proxy.

MFV

Der Medienstapel unterstützt keine In-Band-DTMF.