Freigeben über

Direct Routing: Definitionen und RFC-Standards

  • Artikel
  • Gilt für::
    Microsoft Teams

In diesem Artikel wird beschrieben, wie Teams Telefon Direct Routing RFC-Standardprotokolle implementiert. 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 in der Lage ist, SDP mit der Verbindungsadresse 0.0.0.0 zu empfangen. In diesem Fall bedeutet dies, dass weder RTP noch RTCP an den Peer gesendet werden sollte. 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 3264 beschreibt einen MAY (optional) Medienwiederholungsmechanismus, der das Ändern des Medienports, der IP-Adresse oder des Transports nach der Einrichtung 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

Beim Senden einer SIP-Anforderung (neu oder dialogintern) kann der Microsoft SIP-Proxy eine neue TCP/TLS-Verbindung öffnen oder eine vorhandene Verbindung wiederverwenden, sofern vorhanden.

  • Es gibt maximal zwei TCP/TLS-Verbindungen pro Remote-FQDN/IP pro SIP-Proxy-VM. 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.

  • TCP/TLS-Verbindungen, die vom SIP-Proxy geöffnet werden, bleiben nicht unbedingt geöffnet, solange der Anruf 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.

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: Verwalten Client-Initiated Connections im 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 wird (FIN, ACK) innerhalb von ca. 10 bis 20 Sekunden per SIP-Proxy an den Lieferanten-SBC übertragen.

Hinweise

  • Es wird empfohlen, dass der SBC Verbindungen wie den SIP-Proxy aktiv wiederverwendet. 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

In-Band-DTMF wird vom Medienstapel nicht unterstützt.