Direct Routing – Medienprotokolle

In diesem Artikel wird beschrieben, wie Direct Routing die Medienumgehung mit einem für ICE Lite aktivierten Session Border Controller (SBC) unterstützt, wie in RFC 5245 beschrieben. Dieser Artikel richtet sich an VoIP-Administratoren, die für die Konfiguration der Verbindung zwischen dem lokalen SBC und dem SIP-Proxydienst verantwortlich sind.

Dieser Artikel bietet eine Übersicht über die ICE Lite-Szenarien und Anforderungen an die Interoperabilität. In diesem Artikel werden die Nachrichtenformate und die erforderlichen Zustandsautomatenübergänge beschrieben, um einen zuverlässigen Anruf- und Medienfluss sicherzustellen.

Terminologie

  • First Hello – Die ersten Wörter, die vom Aufrufer und Angerufenen gesprochen werden. Es ist wichtig, dass alle Anstrengungen unternommen werden, um sicherzustellen, dass die ersten Pakete von den Endpunkten für die meisten Anwendungsfälle zuverlässig übermittelt werden.

  • Forking: Das Angebot des Anrufers kann an mehrere aufgerufene Endpunkte übermittelt werden, wenn der Angerufene auf mehreren Geräten verfügbar ist (z. B. kann ein Teams-Benutzer bei Teams für Windows und Teams für Android oder iPhone angemeldet sein).

  • Vorläufige Antwort (183): Die aufgerufenen Endpunkte für eine schnellere Anrufeinrichtung senden eine Antwort mit den Kandidaten und Schlüsseln, die zum Einrichten des Medienflusses erforderlich sind. Diese Antwort erfolgt in Der Erwartung, dass der Benutzer den Anruf (200OK) von diesem spezifischen angerufenen instance annehmen kann. Beim Forking sollte der Aufrufer bereit sein, mehrere vorläufige Antworten zu erhalten.

  • Re-Invite – Angebot mit endgültigen Kandidaten, die vom ICE-Steuerungsendpunkt ausgewählt wurden. Dieses Angebot verfügt über das Attribut a=remote-candidate, um alle Racebedingungen aus der Behandlung mehrerer Forks zu beheben.

  • Teams-Endpunkt: Dieser Endpunkt kann entweder ein Server (Medienprozessor, Transportrelay) oder der Teams-Client sein.

Nachrichtenformat

Die Teams-Infrastruktur folgt RFC 5245 für ICE-Lite. Alle STUN-Nachrichten sind mit RFC 5389 kompatibel.

Die SBCs müssen gemäß RFC 5389 alle STUN-Attribute ignorieren, die sie nicht erkennen, und die Nachrichten weiterhin mit den bekannten Attributen verarbeiten.

Wenn falsch formatierte Pakete empfangen werden, müssen die Pakete verworfen werden, ohne die Einrichtung der Mediensitzung zu beeinträchtigen.

ICE Lite-Anforderungen

In diesem Abschnitt werden die Anforderungen für ICE Lite kurz erfasst.

Kandidatensammlung

Der SBC darf nur einen Kandidaten anbieten. Derzeit werden nur IPV4-Kandidaten unterstützt.

Konnektivitätsprüfungen

Die ICE Lite-Implementierung muss auf alle empfangenen Konnektivitätsprüfungen reagieren. Der ICE Lite-Endpunkt darf keine Anforderungen zur Konnektivitätsprüfung senden. (Wenn Konnektivitätsprüfungen als Verstoß gesendet werden, reagiert die vollständige Implementierung, was dazu führen kann, dass unerwartete peer-abgeleitete Kandidaten erkannt werden und möglicherweise zu Anruffehlern führen.)

Nominierungen

Der Endpunkt der vollständigen ICE-Implementierung ist der Endpunkt controlling und folgt den "regulären" Nominierungen für die Auswahl der endgültigen Kandidaten, die für den Medienfluss verwendet werden sollen. Der ICE Lite-Endpunkt kann die Nominierungen verwenden, um den Weg zu schließen, der für medien- und vollständige Anrufeinrichtung verwendet werden soll.

Wenn das Forking mit Peerendpunkten 183 vorläufige Antworten sendet, muss der SBC bereit sein, auf Überprüfungen von mehreren Endpunkten und auch auf Nominierungen von mehreren Endpunkten zu reagieren, wenn die Nominierungen vor 200OK erfolgen. Abhängig von der Konvergenz der ICE-Zustandsmaschine auf dem endgültigen Pfad und dem Zeitpunkt, zu dem der Benutzer antwortet, können die Nominierungen vor oder nach 200OK erfolgen. Der SBC muss in der Lage sein, beide Fälle zu verarbeiten.

Konvergend zum Forking

Wenn das Angebot von den SBC-Forks an mehrere Teams-Endpunkte gesendet wird, antworten die Teams-Endpunkte möglicherweise mit einer vorläufigen Antwort und starten Konnektivitätsprüfungen. Der SBC muss darauf vorbereitet sein, Konnektivitätsprüfungen zu empfangen und auf Konnektivitätsprüfungen von mehreren Peerendpunkten zu reagieren. Beispielsweise kann der Teams-Benutzer sowohl auf einem Desktop als auch auf einem Mobiltelefon angemeldet sein. Beide Geräte werden über den eingehenden Anruf benachrichtigt und versuchen, die Konnektivität mit dem SBC zu überprüfen.

Schließlich beantwortet nur einer der Endpunkte den Anruf (200OK). Beim Empfang des 200OK kann der SBC den richtigen Kontext für die Verarbeitung der Medienpakete einrichten.

Szenarien

Eingehender Anruf von SBC

Für dieses Szenario gibt es mehrere mögliche Peerendpunkte, die der SBC verarbeiten muss:

  • Serverendpunkte reagieren in der Regel direkt mit 200OK. Diese ICE Full-Endpunkte sind in der Regel in Szenarien wie Voicemail, Anrufwarteschleife und automatische Telefonzentrale beteiligt.

  • Clientendpunkte können mehrere vorläufige Antworten mit unterschiedlichen From/To-Tags (183) senden, gefolgt von einer 200OK vom Endpunkt, der den Anruf entgegen antwortet. Diese ICE Full-Endpunkte stellen in der Regel Endbenutzerclients dar.

  • Andere SBC-Endpunkte. Diese ICE Lite-Endpunkte sind in der Regel am Szenario beteiligt, in dem Clientendpunkte und andere Telefonnummern gleichzeitig klingeln.

Der SBC muss auf alle gültigen Konnektivitätsprüfungsanforderungen reagieren, die von den ICE Full-Endpunkten empfangen werden. Pro RFC werden die ICE Full-Endpunkte zu Steuernden Endpunkten. Die Teams-Endpunkte (Client/Server) führen "Reguläre" Nominierungen aus, um Konnektivitätsprüfungen abzuschließen. Die letzten 200Ok können entweder von einem Endpunkt stammen, der frühe Medien gesendet hat, oder von einem anderen Endpunkt. Beim Empfang der 200Ok muss der SBC den richtigen Kontext für den Medienfluss einrichten.

Frühe Medien

Wenn ein früher Medienfluss vorhanden ist, muss der SBC an den ersten Endpunkt latchen, der mit dem Streamen von Medien beginnt. Der Medienfluss kann beginnen, bevor Kandidaten nominiert werden. Der SBC sollte in dieser Phase über Unterstützung für das Senden von DTMF verfügen, um IVR-/Voicemailszenarien zu ermöglichen. Der SBC sollte den Pfad mit der höchsten Priorität verwenden, auf dem er Überprüfungen erhalten hat, wenn die Nominierungen noch nicht abgeschlossen wurden.

Ausgehender Aufruf an SBC

Die Teams-Endpunkte sind der Anrufer für dieses Szenario und der steuernde Endpunkt. Beim Empfang einer vorläufigen Antwort (183) oder einer endgültigen Antwort (200OK) startet der Teams-Endpunkt die Konnektivitätsüberprüfungen und fährt mit den "regulären" Nominierungen fort, um die Konnektivitätsprüfungen abzuschließen.

Hinweis: Wenn der SBC eine vorläufige Antwort (183) sendet, muss der SBC bereit sein, Anforderungen zur Konnektivitätsprüfung zu empfangen und möglicherweise die Nominierungen abzuschließen, bevor er die 200OK sendet. Wenn Überprüfungen und/oder Nominierungen abgeschlossen sind, bevor die 200OK eingegangen ist, werden die Überprüfungen und/oder Nominierungen nach Erhalt von 200OK nicht mehr durchgeführt. Der SBC darf ICE-Kandidaten, Kennwort und UFRAG (Benutzernamesfragment) zwischen 183 und 200 nicht ändern.

Um frühe Medien zu unterstützen, kann der SBC damit beginnen, die Medien an den Ice-Kandidaten mit der höchsten Priorität basierend auf empfangenen Konnektivitätsprüfungen zu streamen, noch bevor die Nominierungen vom Teams-Endpunkt abgeschlossen werden. Der SBC sollte Medien von Teams zu jedem Kandidaten erwarten, bis die Nominierungen abgeschlossen sind. Sobald ein Kandidat nominiert wurde, muss der SBC auf den richtigen Kontext zurückgesetzt werden, um Medienpakete zu senden und zu empfangen.

Verarbeiten von M-Linien in SDP

In einigen Anrufszenarien können andere Medienmodalitäten in einem Anruf an das PSTN angeboten werden. Beispiel: m=video, wenn ein Teams-Videoanruf an das PSTN weitergeleitet wird. Wenn der Kunden-SBC mit Medienumgehung konfiguriert ist, werden diese Zeilen nicht vom Dienst entfernt und müssen vom SBC verarbeitet werden, der RFC3264 folgt: Für jede Zeile, die nicht "m=audio" im Angebot ist, muss der SBC eine entsprechende "m="-Zeile in der Antwort enthalten, und die Portnummer in dieser Zeile sollte auf Null festgelegt werden. effektiv alle Nicht-Audiodatenströme ablehnen.

SRTP-Supportanforderungen

Der SBC muss die SRTP-Verschlüsselungsverschlüsselung AES_CM_128_HMAC_SHA1_80 für Angebot und Antwort im folgenden Format unterstützen:

"inline:" <key||salt> ["|" lifetime]

Es folgt ein Beispiel für das Krypto-Attribut im SDP-Angebot des SBC:

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:V/Lr6Lsvhad/crSB9kCQ28jrYDxR2Yfk5bXryH5V|2^31

MKI- und Length-Parameter sind nicht erforderlich.

Weitere Informationen finden Sie unter RFC 4568, Abschnitt 6.1.

SDES-Supportanforderungen

Das Gerät muss SDES im folgenden Format anbieten können. Microsoft-Medienprozessoren bevorzugen immer SDES.

  • Selbst wenn ein Client nur DTLS unterstützt, werden die Medienprozessoren bei Umgehung von Nicht-Medien in SDES konvertiert.

  • Bei der Medienumgehung fügt Direct Routing einen MP in den Pfad ein, wenn ein Client nur DTLS ist (zukünftiger Google Chrome-Zustand), und der Anruf wird von der Medienumgehung in die Nicht-Medienumgehung konvertiert. Zwischen der SBC- und Medienprozessorkomponente von Direct Routing wird immer SDES verwendet.

Derzeit gibt es keinen Teams-Client, der nur DTLS anbietet. Google kündigte jedoch an, dass sie zu einem bestimmten Zeitpunkt die Unterstützung von SDES einstellen werden.

Formatieren des Angebots aus SBC im Umgehungsmodus

Das Angebot muss SDES enthalten und kann DTLS optional im folgenden Format enthalten:

m=audio 54056 UDP/TLS/RTP/SAVP 0 8 76 77 18 9 101 13
a=rtcp:54056
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:krXco0QRglwErMqtbMs2zSw29tBdmdgXpEYZhQmp|2^31
a=fingerprint:sha-256 AE:24:07:15:5C:B7:45:1A:E4:45:60:C1:1E:68:0E:CC:8D:A6:78:3B:76:65:BB:B0:77:88:07:F8:98:18:62:34
a=setup:actpass
a=rtcp-mux

Format für Die Antwort, die SDES an SBC enthält

m=audio 54056 RTP/SAVP 111 103 104 9 0 8 description 106 13 110 112 113 126
a=rtcp:54056
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:fBc61ikv1kMy0sF85DblNqTzVAbFa7hJQ9GKb6Yj|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:O1qT9tWbs/NwJVwhfrgF5tCrbNOxnVDqkIqTx4rz|2^31
a=rtcp-mux

Format für das Angebot von Teams zu SBC

Format für SDES-Angebot nur für SBC

m=audio 52884 RTP/SAVP 111 103 104 9 0 8 106 13 110 112 113 126
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:Hr4D2cgUu9+Uza5Igz/JkVx59DAxDbaxJg862ibQ|2^31
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JPEaIxHegfuv53ykBPZk8hV0GO8kTiiqRMfHimEE|2^31
a=rtcp:52884
a=rtcp-mux