ICE-Lite

ICE-Lite beschreibt ein Verfahren, wie ein Client gegenüber einem STUN-Server seine für die Gegenseite sichtbare IP-Adresse und Port verrät. Damit können unter bestimmten Bedingungen Clients sich auch per NAT erreichen. Ich beschreibe dies hier, da die Funktion Direct Routing - Telefonie mit eigener SIP-Anbindung in Verbindung mit Direct Routing und Media Bypass zum Einsatz kommt. Auch den "Verbindungscheck" von RTP Portcheck sollten sie kennen.

ICE, und ICE-Lite

Wenn zwei VoIP-Clients miteinander direkt Sprache, Video aber auch Daten austauschen wollen, müssen Sie einen Kanal zueinander aufbauen. Das ist eine ganz andere Anforderung als der Zugriff auf einen Server mit einem bekannten Namen und zugeordneten IP-Adresse und Port. Die Clients müssen sich finden und dazu ermittelt jeder Client eine Liste von möglichen Kandidaten, die dann über SIP oder HTTP über den zentralen Server (Skype for Business, Microsoft Teams o.ä.) ausgetauscht werden. Als Kandidaten sind direkte IP-Adressen, STUN-Adressen hinter einem NAT-Router oder TURN-Adressen durch ein Relay möglich. Jeder Client kommt dabei auf mehrere Adressen die alle im N:M-Verfahren durchprobiert werden und dann die beste Paarung je Richtung ausgewählt wird.

Für die weitere Betrachtung gehe ich davon aus, dass Sie ICE an sich kennen. Ansonsten sollten sie die folgende Seite vorab lesen.
ICE, Kandidaten, STUN und TURN

Dieser ganze Handshake ist natürlich aufwändig und gerade die Nutzung von STUN und TURN kann komplexer sein als sie eigentlich sein müsste. Für TURN und STUN ist die Mithilfe eines TURN-Servers erforderlich, der erreichbar ist und Relay-Dienste anbietet. Da dies etwas "kostet", erfordern alle TURN-Server auch eine Anmeldung. So eine Mithilfe erfordert eine entsprechende Konfiguration auf dem Client mit dem Namen dieses Servers und vor allem entsprechenden Anmeldeinformationen.

Das Ganze ist aber nicht erforderlich, wenn eine Seite öffentlichen IP-Adressen und frei zugängliche Ports hat. Dann muss er nämlich gar nicht erst über verschiedene "Traversal-Technologien" gehen. Er bietet dem Gegenüber einfach von seiner öffentlichen IP-Adresse einen Port an. Die andere Seite kann weiterhin das "voll ICE" fahren. Beim Handshake fallen dann auch einige Paare von vorneherein weg. In der Regel reicht der anderen Seite dann aber der Zugang per NAT. "ICE Lite" hat nur das Ziel, dass ein Client seine PublicIP bekommt, um diese anbieten zu können:

However, certain agents will always be connected to the public Internet and have a public IP address at which it can receive packets from any correspondent. To make it easier for these devices to support ICE, ICE defines a special type of implementation called LITE (in contrast to the normal FULL implementation). A lite implementation doesn't gather candidates; it includes only host candidates for any media stream. Lite agents do not generate connectivity checks or run the state machines, though they need to be able to respond to connectivity checks.
Quelle: https://tools.ietf.org/html/rfc5245

Damit wird ICE deutlich einfacher und auch schneller. Voraussetzung ist eine per Routing ohne Firewall für RTP erreichbare IP-Adresse.

For media bypass, the Teams client must have access to the public IP address of the SBC even from an internal network. If direct media is not desired, the media can flow via Transport Relays.
Quelle: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass

Wenn Sie über den Weg auch Anwender im Home-Office unterstützen sollen, dann ist eine öffentliche routbare IP-Adresse wünschenswert aber auch Carrier Grade NAT (CGN) ist möglich

ICE-Lite und Direct Routing

In einer klassischen Skype for Business Welt ist natürlich ICE für die Clients vorgeschrieben. Aber schon die Verbindung zwischen einem lokalen VoIP-Gateway zum Mediation Server hat schon ICE etwas "optimiert" genutzt. Natürlich wurden hier ebenfalls Kandidaten ermitteln und über das SDP - Session Description Protocol in einem SIP-Paket ausgetauscht. Allerdings waren auch da nur direkte Kandidaten mit einer überschaubaren Codec-Auswahl enthalten. Umwege über STUN und TURN waren mit Skype Media Bypass nicht erforderlich.

Media bypass leverages protocols called Interactive Connectivity Establishment (ICE) on the Teams client and ICE light on the SBC. These protocols enable Direct Routing to use the most direct media path for optimal quality. ICE and ICE light are WebRTC standards. For detailed information about these protocols, see RFC 5245.
Quelle: Plan for media bypass with Direct Routing https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass

Mit Microsoft Teams ändert sich diese Herausforderung, da die "Server" nur in der Cloud von Microsoft betrieben werden und die Clients aus Sicht des Servers auch "extern" stehen. Der Weg zum Telefonnetz über einen eigenen SIP-Trunk ist daher nicht mehr zwingend "intern". Damit ergeben sich aber nun folgende  mögliche RTP-Verbindungen für Audio.

Farbe Szenario Beschreibung

Rot

Client im Internet direkt

Ein Client im Internet oder Home-Office ohne allzu strenge Firewall kann direkt die öffentlichen IP-Adresse des SBCs erreichen. Allerdings sollten Sie sich genau überlegen, ob Sie dies aus Sicherheitsüberlegungen wollen. Auch Microsoft schreibt dazu:

For media optimization purposes, Microsoft recommends opening the public IP address of the SBC only to Teams Transport Relays. For clients outside of the corporate network, Microsoft recommends using Transport Relays instead of reaching the public IP address of the SBC directly.
Quelle: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass

Grün

Interner Client

Auch ein Client im Firmennetzwerk kann eine quasi "schnelle interne" Verbindung aufbauen. Das gilt natürlich nur, wenn der Client die öffentlichen IP-Adresse des SBCs erreichen kann und auch der Rückweg des SBC zum Client möglich ist. Diese Option ist natürlich für Firmen sehr interessant, da damit die RTP-Verbindung komplett im LAN bleiben kann.

Blau

Client über TURN

Als letzte Option gibt es natürlich immer noch den Weg, dass der Client die "Relay"-Dienste des TURN-Servers von Office 365 nutzt. Das sollte immer gehen aber die Qualität kann aufgrund der längeren Wegs natürlich darunter leiden und ist ineffektiv.

Beachten Sie, dass je Richtung unterschiedliche Wege verhandelt werden können. Es ist also gar nicht mal ungewöhnlich, wenn ein Client im Home-Office zwar direkt den SBC per NAT des DSL-Routers erreichen kann aber der Rückweg dennoch über die Office 365 TURN-Server geroutet wird.

Allen Fällen gemeinsam ist aber, dass der SBC selbst einfach nur seine öffentlichen IP-Adressen als Kandidaten verwendet.

SDP mit ICE-Lite im SIP-Trace

Ich habe natürlich damit auch mal rausfinden wollen, was hier bei einem INVITE passiert. Ich habe daher erst mal auf dem SBC einen Trace mitgeschnitten, wenn ein Anruf vom Amt über Direct Routing zum Teams PSTN-Gateway sende. Der Anruf erfolgt von meinem Mobiltelefon auf einen Teams-Anwender

2019-03-27 22:29:55 <133>[S=11130695] [SID=359b21:26:1252438]  INVITE sip:+495251304xxx@sipgw.uclabor.de;user=phone SIP/2.0 
Via: SIP/2.0/TLS sipgw.uclabor.de:5067;alias;branch=z9hG4bKac1918791682 
Max-Forwards: 69 
From: <sip:+49160xxxxxxxx@sipgw.uclabor.de>;tag=1c117598140 
To: <sip:+495251304xxx@sipgw.uclabor.de;user=phone> 
Call-ID: 14600730222732019222954@sipgw.uclabor.de 
CSeq: 1 INVITE 
Contact: <sip:+49160xxxxxxxx@sipgw.uclabor.de:5067;transport=tls> 
Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat 
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE 
User-Agent: Mediant 1000 - MSBR/v.7.20A.204.222 
Content-Type: application/sdp 
Content-Length: 458 
 
v=0 
o=AudiocodesGW 1496893926 2122093353 IN IP4 80.66.20.26 
s=Phone-Call 
c=IN IP4 80.66.20.26 
t=0 0 
m=audio 9060 RTP/SAVP 8 0 101 13 
a=ptime:20 
a=sendrecv 
a=rtpmap:8 PCMA/8000 
a=rtpmap:0 PCMU/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-15 
a=rtpmap:13 CN/8000 
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:jiQffvJO8664A1HSC8YjM0CqvWGZKGwvr490xSlF|2^31
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:vhQ7VW3xokn/HTuXDk7bQaVg99oNMTsxSsql4SmP|2^31

In dem INVITE sehe ich ein "m=audio" aber keine expliziten Kandidaten. Das ist für einen normalen SIP-Trunk auch in Ordnung, wenn die RTP-Kandidaten mit dem "C="-Feld identisch sind. Nun schalte ich aber einmal "ICE Lite" auf dem Mediant im IP Profil des Direct Routing SIP-Trunks ein.

Beim nächsten Anruf ist dann sofort zu sehen, dass hier ganz andere Kandidaten angeboten werden.

13:13:05.000  ---- Outgoing SIP Message to 52.114.75.24:5061 from SIPInterface #4 (UcLab-Extern) TLS TO(#978) SocketID(3210) ---- 

INVITE sip:+495251304xxx@sipgw.uclabor.de;user=phone SIP/2.0
Via: SIP/2.0/TLS sipgw.uclabor.de:5067;alias;branch=z9hG4bKac1775782574
Max-Forwards: 69
From: <sip:+49160xxxxxxxx@sipgw.uclabor.de>;tag=1c50622230
To: <sip:+495251304xxx@sipgw.uclabor.de;user=phone>
Call-ID: 789380453293201913135@sipgw.uclabor.de
CSeq: 1 INVITE
Contact: <sip:+49160xxxxxxxx@sipgw.uclabor.de:5067;transport=tls>
Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
User-Agent: Mediant 1000 - MSBR/v.7.20A.250.273
Content-Type: application/sdp
Content-Length: 891

v=0
o=AudiocodesGW 194724158 1763899963 IN IP4 80.66.20.26
s=Phone-Call
c=IN IP4 80.66.20.26
t=0 0
a=ice-lite
m=audio 9030 RTP/SAVP 8 0 101 13
a=ptime:20
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=ice-ufrag:cG1NnWITGEtjeB8U
a=ice-pwd:sEtz3YWmQXcOsy+tz18NkQZc
a=candidate:1242229980 1 udp 2130706431 80.66.20.26 9030 typ host
a=candidate:1242229980 2 udp 2130706430 80.66.20.26 9031 typ host
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WbKciodcLyHVtxlDQpDXWwUJvNMeB6npnlTlXmGM|2^31
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:lsvCBFF7p0fmILHRZdjw71273xr5FoUjIjWxqaMO|2^31
a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:lLc/Arn4V3PgQAfE0o5wuYmr0iPxHlXSF5z6LorNVkh4Zg351GWGYsSklPf04a|2^31
a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:xqgLDICrEUaersOE1DpCv1fWVKEgBOtkZ8LbbFf4x0gzPOUS8F/8hg/AGjGyCh|2^31

Genau genommen sind es aber auch nur die gleichen IP-Adressen, die aber nun als ICE-Kandidaten unten addiert werden. Da das Gateway kein STUN oder TURN mit dem Trunk zu Teams nutzt, fehlen natürlich Einträge vom Typ "srflx " und "relay". Das ist aber auch gar nicht erforderlich, da das Gateway ja unter einer öffentlichen IP-Adresse erreichbar ist und andere öffentliche Adressen erreichen kann.

SDP-IP hinter NAT nutzen

Nun gibt es natürlich Firmen, die generell keinen Betrieb eines Systems mit einer Public IP am Internet erlauben und daher alle eingehenden Verbindungen per NAT auf das Zielsystem umsetzen. Das ist auch hier möglich, wenn Sie die Konfiguration entsprechend anpassen.

Per Default wertet der SBC natürlich die Public-IP seines Interface aus, über den die SIP-Anfrage ankommt. Bei eigentlich jedem SBC können Sie aber die IP-Adressen für Audio auch manuell vorgeben bzw. überschreiben.

Bei einem Audiocodes kann dies über "NAT translations rules", z.B.: hier eingestellt werden:

In der Weboberfläche sieht das dann wie folgt aus:

Diese Regel konfiguriert im Audioodes kein NAT sondern sagt ihm, dass auf dem Interface "Voice" die Pakete per NAT ankommen und er im SDP-Angebot diese öffentlichen Adressen und Ports verwenden muss. Allerdings müssen Sie natürlich per Firewall und Reverse-NAT sicherstellen, dass die RTP-Daten an diesen Port mit einer 1:1 Umsetzung auch auf der internen IP-Adresse des SBCs ankommen. Im gleichen Zug müssen Sie natürlich auch SIP entsprechend per Reverse-NAT veröffentlichen.

ICE Lite und STUN 3478/UDP

Bei der Analyse der Netzwerkverkehre ist mir dann aber aufgefallen, dass Office 365 sehr wohl per UDP auch eine eingehende Verbindung auf meinen SBC versucht und der Mediant hat sogar darauf geantwortet. Ich habe daher auch noch mal genauer nachgeschaut, was ICE LITE aus Sicht von Audiocodes bedeutet und wurde in der Beschreibung fündig:


Quelle https://www.audiocodes.com/media/13261/sip-gateways-sbcs-release-notes-ver-70.pdf

Das Gateway macht demnach zwar selbst keine ICE-Anfragen aber unterstützt zumindest andere Clients beim Ermitteln ihrer eigenen öffentlichen IP-Adresse, indem es auf ICE-Anfragen antwortet.

Weitere Links