PSTN Call mit MediaBypass
Diese Seite ist entstanden, weil ich nach einem Fehler gesucht habe, warum ein Telefonanruf von Microsoft Teams mit SIP-Trunk bei mir nicht ankommt. Ich habe mich dabei selbst aufs Glatteis geführt, weil ich einen Fehler gefunden haben wollte, so keiner ist. Ich konnte mir einfach das Fehlen von bestimmten Kandidaten im SDP nicht auf Anhieb erklären.
Umgebung
Es handelt sich wieder um ein einfaches Setup mit einem Audiocodes Gateway, welches als Session Border Controller einen SIP-Trunk zu Microsoft Teams und einen zweiten SIP-Trunk zu einer Skype for Business On-Premises Umgebung bedient. Auch wenn hier Teams und Skype in einem Satz stehen, sind es komplett getrennte Tenants und Umgebungen. Für die weitere Analyse reicht es zu wissen, dass "irgendwie" ein eingehender Anruf über das Gateway zum Skype for Business Mediation Server kommt, der dann über den Frontend Server beim Skype for Business Client gemeldet wird.
Audio beim PSTN-Call
Hierbei gibt es zwei Optionen, wie die Sprache ausgehandelt wird
- Ohne MediaBypass
Dies kommt immer zum tragen, wenn der Client nicht im LAN ist, Skype Sites eine WAN-Verbindung abbilden oder der Client über einen Edge-Server von extern arbeitet. Die Sprache wird dabei einmal zwischen Gateway und Mediation Server übertragen. Der Mediation Server übernimmt dann eine Transcodierung und baut seinerseits eine Verbindung zum Client auf. Je nach Netzwerkstandort bieten sowohl der Mediation Server als auch der Client ihre entsprechenden Kandidaten an. Der Mediation Server nutzt dazu neben seiner eigenen internen IP-Adresse auch die TURN/STUN-Funktion des Edge-Servers. Auch der Client nutzt neben der direkten IP-Adresse auch die STUN/TURN-Funktionen des Edge Servers.
- Mit
Media
Bypass
Hierbei ist davon auszugehen, dass der Client direkt mit dem Gateway sprechen kann und der Mediation Server nur die Signalisierung übernimmt. Die RTP-Daten werden direkt übermittelt. Das Gateway kennt dabei natürlich nichts vom Skype for Business Edge Server und bietet daher meist nur seine direkten Kandidaten an. Der Client hingegen könnten schon neben den direkten IP-Adressen auch STUN/TURN anbieten, auch wenn die Verbindung gar nicht genutzt werden sollte.
Mit der Erwartungshaltung habe ich also einen UCCAPILOG-Trace auf dem Client geöffnet, um den Fehler zu suchen.
SIP Messages
Interessant sind hier der INVITE vom Frontend Server zu meinen Client und der 183 Session Progress
Eingehender INVITE
Es war eingehender Anruf von einem Teams-User per SIP-Trunk, was sich aber nicht von einem normalen Telefonanruf unterscheidet. Das Gateway bzw. der SBC verbergen die "andere Seite". Der Anruf kommt per SIP beim Mediation Server und mit aktivem Media Bypass, so dass der Mediation Server den Anruf erst mal weiter meldet. Im Trace sehe ich dazu das SIP-Paket mit dem INVITE, aus dem ich schon mal auslesen kann, dass der Mediation Server "Media Bypass"! erlaubt" und in welchem Netzwerk der Server steht.
Das ist aber noch nicht weiter aussagekräftig. Im gleichen Paket sind auch die SDP-Kandidaten enthalten. Auf den ersten Blickt sehen Sie einen Abschnitt, der verwirrt. Sie finden z.B.: hier STUN und TURN-Kandidaten auf eine öffentlichen IP-Adresse eines Skype for Business Edge-Servers. Ich wüsste nicht, welches Gateway sich per TURN solche Kandidaten vom Edge Server besorgen kann. Zudem ist "msrta" als gültiger Codec im Angebot mit enthalten und auch die IP-Adressen passen natürlich nicht zum Gateway.
Aber wenn Sie im Snopper weiter scrollen, dann finden sie noch einen zweiten SDP-Datensatz. Gleich am Anfang sehen Sie auch einen Wert im Feld "x-bypassid":
Dies sind dann die Kandidaten, die vom Gateway über den Mediation Server zum Client mit übermittelt werden. Lassen Sie sich also nicht vom ersten SDP irritieren, der natürlich ebenfalls mit gesendet wird. Der Mediation Server kann zu dem Zeitpunkt ja noch nicht wissen, welche Clients wo im Netzwerk angebunden sind und sendet daher neben den Angeboten des Gateways auch noch mal seine Gegenstelle mit.
Mit aktiviertem Media-Bypass müssen Sie auf dem gleichen daher beide SDP-Angebote sehen.
183 Session Progress des Clients
Der oder die Clients senden in der Regel irgendwann einen "183 Session progress" zurück, wenn Sie Early Media unterstützen. Hier sehen Sie dann das Angebot des Clients. Ohne Early Media kommen diese SDP Kandidaten erst mit dem "200 OK" zurück. Da ich hier das UCCAPILOG auf dem Client analysiere, sehe ich nur meine eigenen Antworten.
Der Client hat erkannt, dass er auch im "Intranet" ist, was er über das Feld "ms-endpoint-location-data" verrät. Für die Aushandlung des Medienkanals ist aber der SDP-Inhalt maßgeblich. Hier sehen Sie, dass der Client einfach nur seine direkte IP-Adresse anbietet. Zusätzlich steht auch ein "a=x-bypass" im SDP.
Ergebnis
Ich habe ihnen nun erspart, auch noch den ReINVITE und das 200OK abzudrucken und am Ende das BYE und den QoE-Datensatz. Für die Analyse, ob eine "Media Bypass"-Verbindung überhaupt möglich ist und versucht wird, sind die beiden Pakete maßgeblich.
Und lassen Sie sich nicht davon irritieren, dass der INVITE auch noch mal die Kandidaten des Mediation Servers enthalten. Das muss so sein und scrollen sie einfach weiter nach unten, damit Sie auch den zweiten SDP sehen.
