Teams ComfortNoise

Auf der Seite beschreibe ich eine Fehlersituation, die meine Kollegen bei Kunden erst nach einiger Zeit in Verbindung mit T-Mobile-Verträgen "Stille" und dingfest machen konnten. Bei der Recherche haben wir aber viel mehr über SIP-Trunks, RTP-Timeouts Comfort Noise u.a. herausgefunden.

Fehlerbild

Unsere Kunden und wir bei Net at Work nutzen schon sehr viele Monate die Teams Telefonie mit Direct Routing. Der Fehler ist also lange unbemerkt geblieben und hat und scheinbar nicht gestört. Aber Sie sollten mal folgenden Test durchführen.

  • Teams-Teilnehmer wartet auf Anrufer
  • Die TK-Anbindung erfolgt über einen SIP-Trunk und eigenen SBC (ohne Transcoding)
  • Teilnehmer mit T-Mobile Vertrag ruft Teams-Teilnehmer an
  • Verbindung kommt zustande
  • Teams-Teilnehmer ist ca. 12 Sekunden "ruhig"
    d.h. er sagt einfach nichts mehr oder schaltet sich stumm.
  • Ergebnis: T-Mobile beendet den Anruf nach 12 Sekunden

Der Smartphone-Teilnehmer sieht ein "Anruf fehlgeschlagen" und der Teams Teilnehmer sieht, dass der T-Mobile Teilnehmer aufgelegt hat.

Test-Serie mit Mobilfunk

Da wir an unserem SIP-Trunk auf die Schnelle nichts ändern konnten, haben wir erst einmal mit verschiedenen Gegenstellen gearbeitet. Der Teams Client war ohne VPN im Homeoffice, so dass Direct Media nicht zum Einsatz gekommen ist. Das Bild sieht also wie folgt aus:

Technisch kann ich nur den Trunk zwischen unserem TK-Anbieter (Hier EWE) und zu Teams genauer anschauen. Einfacher ist es aber erst einmal, eine Testserie mit anderen Gegenstellen zu starten.

Tln-A Tln-B Richtung Ergebnis Beschreibung

D1

Teams

TlnA -> Tln-B

FAIL

Verbindungsabbruch nach ca. 12 Sek

Teams

D1

TlnA -> Tln-B

OK

Kein schneller Verbindungsabbruch

D2

Teams

TlnA -> Tln-B

OK

Kein schneller Verbindungsabbruch

Teams

D2

TlnA -> Tln-B

OK

Kein schneller Verbindungsabbruch

O2

Teams

TlnA -> Tln-B

OK

Kein schneller Verbindungsabbruch

Teams

O2

TlnA -> Tln-B

OK

Kein schneller Verbindungsabbruch

DG

Teams

TlnA -> Tln-B

OK

Kein schneller Verbindungsabbruch

Teams

DG

TlnA -> Tln-B

OK

Kein schneller Verbindungsabbruch

Soweit war meine erste Testserie mit "gehaltenen" Anrufen und ob diese innerhalb einer Minute abgebaut wurden. Es hat den Anschein, dass T-Mobile hier sehr schnell Anruf beendet, die von der T-Mobile aufgebaut wurden. Interessanterweise scheint es in der Gegenrichtung viel länger zu dauern.

Die Tabelle ist so nicht ganz richtig, denn alle Provider haben Abbrüche. Dazu aber später mehr

Fehlersuche Audiocodes

Da auf dem Smartphone natürlich keine "Debug-Ausgabe" zu sehen sind und ich auf auf dem Teams-Client erst einmal kein UCCAPI-Log mehr habe, galt der Bild dem SBC, auf dem die SIP-Steuerung erfolgt. Hier ist dann gut zu sehen, dass der Call sauber aufgebaut wird und um 15:46:52 zustande kommt. 15:47:09 sendet mir dann der SIP-Trunk zum Carrier ein "BYE".

Das Paket kommt allerdings nicht direkt von T-Mobile, da die IP-Adresse 85.16.254.56 zu dem SIP-Provider EWS gehört. (https://ipinfo.io/AS9145/85.16.0.0/16-85.16.254.0/23). Interessant finde ich, dass hier als Caller" die Rufnummer mit der Domain "ims.telekom.de" steht. Bei weiteren Traces werden sie sehen, dass die bei anderen Carriern mittlerweile auch so ist.

Der Q.850-Fehler kommt normalerweise von Gegenseite (T-Mobile), wobei ich nicht weiß, ob EWE die Meldung noch überarbeitet hat oder tatsächlich genau so von der Telekom geliefert wird.

Dies ist nur ein Beispiele. Nicht immer kommt eine Fehlermeldung mit. Einige Tests lieferten auch einfach einen BYE.

Feedback EWE/Telekom

Da unser Vertragspartner für SIP die EWE ist, haben wir natürlich dort erst einmal eine Supportanfrage eingestellt. EWE hat in ihrer Umgebung keinen Fehler gefunden und hat daher die Telekom angefragt. Die weitergeleitete Antwort der Telekom beantwortet dann das Verhalten etwas.

Da hat die Telekom wohl eine aktive Überwachung, ob der RTP-Datenstrom noch vorhanden ist. Es kann ja durchaus sein, ein SIP-Teilnehmer ohne ein BYE verschwindet. Solche Fälle muss ein Timeout (Siehe RTCP und Session-Timeout)  absichern, die sowohl RTP als auch SIP betreffen. Aber 10 Sekunden ist schon sehr kurz.

Wireshark Trunk

Über einen TCP-Trace auf dem SBC (Audiocodes) konnten wie die Pakete auf dem LAN über einen SYSLOG-Server mitschneiden. Daher sind die IP-Adressen bei Source und Destination nicht aussagekräftig. Sie Sehen hier aber die RTP-Daten vom SBC zur Telekom, die dann um 16:45:30 durch die Stummschaltung aufhören und zum eingehende BYE um 16:45:42 geführt haben.

Eine Testserie mit anderen Providern bezüglich RTP-Timeout habe ich weiter unten angestellt. Ich bin aber etwas irritiert, denn bei SIP gibt es zwei Möglichkeit, wie man auf "Stille" reagieren kann.

  • SIP-Signalisierung
    Ein Client kann bei einer "Stummschaltung" über SIP einfach ein "SendOnly" oder "ReceiveOnly" übermitteln und damit der anderen Seite mitteilen, dass er keinen Ton sendet oder erwartet. Dieses Verfahren kenne ich von TK-Anlagen, da damit die Gegenseite auch "sehen" kann, dass der Anschluss "gehalten" wird. Das setzt in der Regel auch die RTP-Supervision außer Kraft.
  • Comfort Noise
    Eine zweite Option ist ein Codec-Wechsel von auf CN, um Bandbreite u.a. zu sparen. Die Endpunkte senden dann deutlich weniger Pakete um den RTP-Kanal offen zu halten und die Empfängerseite kann ein "Rauschen" generieren. Siehe Comfort Noise. Comfort-Noise macht natürlich keinen Sinn in einer "Audiokonferenz", bei der die meisten stummgeschaltet sind.

Keine der beiden Optionen ist hier im Wireshark-Trace zu sehen. Insofern ist es eigentlich sogar verständlich, dass jemand auf dem Weg irgendwann eine "Inactivity" feststellt und die Verbindung terminiert.

Wireshark Client

Also habe ich mich auf den Client konzentriert und hier per Wireshark mitgeschnitten, welche UDP-Pakete übertragen werden. Ich kann zwar so nicht die Signalisierung sehen aber auch due UDP-Pakete verraten viel, wenn ich neben dem Gespräch auch eine Stummschaltung aktiviere.

Client RTP-Streams

Teams native Windows Client

Sie erkennen, dass sowohl der Codec 104 (SILK/16000) als auch 118 (CN) genutzt. Der Windows Client erkennt Stille und sendet CN

Teams im Edge Browser

Im Gegensatz dazu habe ich auch noch mal einen Wireshark-Trace mit Teams im Edge-Browser gestartet. Hier kommt dann G.722 als Codes mit dem klassischen "CN" zum Einsatz.

Wireshark zeigt, obwohl er die Sprache selbst dank SRTP nicht decodieren kann, die Latenzzeit zwischen den Paketen auf und man erkennt gut, dass in die Senderichtung vom Client nur noch alle 100ms ein Paket kommt.

In den Details sehen wir dann auch den Codec-Wechsel mit dem Browser Client.

Damit ist klar, dass sowohl der Teams/WinX64 als auch der Edge-Browser ihre Aufgabe richtig machen.

Provider und Codecs

Wir haben uns dann die beiden SIP-Trunks genauer betrachtet. Von verschiedenen Gegenstellen haben wir einen Teams-Teilnehmer angerufen und die INVITES samt dem SDP verglichen. Die Provider bieten alle PCMA und DTMF an. Zusätzlich bieten einige Provider weitere Codecs an. Allerdings habe ich keinen Provider gefunden, der "Comfort Noise (CN) an anbietet. Das finde ich ungewöhnlich, denn genau dieser Codec könnte gerade bei Telefonaten in der "ruhigen" Richtung Bandbreite sparen.

Zusätzlich haben wie den erfolgreich aufgebauten Anruf auf der Team-Seite "stumm" gestellt und gewartet. So konnten wie pro getesteten Provider den "Timeout" ermitteln, nachdem Sie ihrerseits eine Verbindung mit einem "BYE" abbauen und nichtsagende Fehlermeldungen beifügen.

Interessanterweise betraf dies immer nur Verbindungen, die eingehend zu Teams aufgebaut wurden aber nie ausgehende Verbindungen. Betroffen waren die getesteten Clients: Teams/Win, Teams/Edge, Teams/IOS und Teams/Android.

Provider Codecs RTP Timeout INVITE und BYE-Schlussmeldung

T-Mobile

 G722/8000
PCMA/8000
PCMU/8000
DTMF/8000

10 Sek

Deutsche Glasfaser

 PCMA/8000
DTMF/8000

2 Minuten

O2/Telefonica

 G722/8000
PCMA/8000
PCMU/8000
DTMF/8000
DTMF/1600

1 Min

D2 Vodafone

 G722/8000
PCMA/8000
PCMU/8000
DTMF/8000

5 Min

DeutschlandLAN-SIP

 PCMA/8000
PCMU/8000
DTMF/8000

Stumm!

Hier hatte ich ein ganz anderes Fehlerbild. Tln-B hat nach 5 Minuten die Stummschaltung aufgehoben aber war dennoch von Tln-A nicht zu hören.

Bei Tln-B war aber zu sehen, dass die Telekom per INVITE immer wieder versucht hat, den RTP-Kanal wieder aufzubauen, was aber nicht gelungen ist. Ursächlich war hier dann die "RTP Erkennung" des SBC.

In den Einstellungen "Broken Connection Mode: Ignore" wurde der RTP-Stream beendet aber die SIP-Session ab leben gelassen. Daher ist es hier wichtig, die Einstellung auf "Disconnect" zu setzen.

T-Com Privatanschluss

 PCMA/8000
PCMU/8000
DTMF/8000

>10Min

Anscheinend hat die Telekom keine "RTP-Stream-Überwachung" aktiviert oder sie hat auch nach über 10 Minuten noch nicht angeschlagen. Die Verbindung hatte bestand und nach dem Öffnen des Mikrofons war eine Verständigung möglich.

Nur durch den Timeout von 12 Sekunden bei T-Mobile ist uns überhaupt aufgefallen, dass es hier ein Problem gibt. Ein Kunde ruft an und schildert sein Problem. In der Zeit schweigt ja der angerufene Teilnehmer für einige Zeit. O2/Telefonica erlaubt zumindest bis zu 1 Minute stille, ohne die Verbindung zu unterbrechen. Je länger der Timeout ist, desto seltener passiert der unerwartete Verbindungsabbruch.

Ich nehme gerne weitere Bye-Meldungen und Timeouts anderer Carrier auf, wenn sie das gleiche Problem haben.

Die Probleme sollten auch mit Konferenzen, Call Queues ohne Wartemusik auftreten. Das habe ich aber nicht weiter geprüft. Wir sehen aber, dass ein einfaches "Anrufen geht" durchaus Tücken haben kann.

Lösung: Comfort Noise auf dem Trunk

Damit wissen wir nun den Grund für die Verbindungsabbrüche. Keiner der Carrier hat "Comfort Noise" implementiert und trennt Verbindungen einfach, wenn die RTP-Pakete zu lange ausbleiben. Damit ist aber auch die Lösung relativ einfach. Der SBC muss sich die Mühe machen, zu Teams den Codec "CN" mit anzubieten, denn Teams kann natürlich Comfort Noise. Da aber der Trunk zum Carrier ohne CN arbeitet, muss der SBC in diese Richtung dann selbst "Noise" erzeugen. Dies wird auf den entsprechenden Trunk-Einstellungen konfiguriert

Achtung: Damit übernimmt der SBC eine "Transcoding"-Funktion, welche je nach Produkt gesondert zu lizenzieren ist. Das kann aber auch Vorteile haben, Weil Sie dann Richtung Teams nicht auf die Codes des TK-Anbieters beschränkt sind, sondern auch SILK und andere von Teams unterstützte Codecs einsetzen können.

Nach der Änderung von Comfort Noise sehen Sie bei dem INVITE vom SBC zu Teams, dass hier erst einmal der Codec "13 = CN/8000 dazu gekommen ist.

Teams nimmt dieses Angebot dankbar an und bei einem eingehenden Stream mit Stummschaltung ist der Codec-Wechsel einfach zu finden:

Auf der Seite zum TK-Dienstleister ist in der gleichen Zeit nur zu sehen dass ganz viele G.711-Pakete (PCMA) gesendet werden.

Damit gibt es für den Provider auch keinen Grund mehr den Anruf aufgrund fehlender RTP-Pakete zu beenden.

Ich hoffe nur, dass der Übergang zum Mobilfunknetz dann so schlau ist, um die "Stille" zu erkennen und damit nicht unnötig Pakete zu übertragen.

Festnetz zu Festnetz

T-Mobile über EWE liefert UserAgent

Bei der Analyse der unterschiedlichen INVITE-Pakete ist mir aufgefallen, dass T-Mobile auch einen UserAgent mitliefert, der einen Rückschluss auf den Anrufer aus dem Mobilfunknetz erlaubt.

Der angerufene Teilnehmer kann daraus nicht nur erkennen, welches Mobilgerät der Anrufer verwendet sondern bei Apple die Firmware und Android sogar das Security Update.

Ob das so gewollt und aus datenschutzrechtlichen Überlegungen "erlaubt" ist?

Wenn ich dann aber von meinem Mobiltelefon (D1) über einen Deutschland-LAN Trunk telefoniere, dann kommt der UserAgent nicht mit.

Das interpretiere ich so, dass T-Mobile den UserAgent beim Peering zu einem anderen Provider übergibt aber der Provider natürlich diese Information entfernen kann.

T-Mobile sendet den UserAgent aber über den DeutschlandLAN-Trunk kommt die Information nicht mehr an während EWE die Information nicht entfernt

Weitere Links