[Gelöst] Einseitige Sprachverständigung nach Ende der Warteschleife

[chrsto]

Wer hast Lust, mir bei meinem Telekom VoIP Problem zu helfen?

Problem: Einseitige Sprachverständigung nach Ende der Warteschleife.

Was passiert: Anruf bei einer beliebigen Telekom Hotline, es folgt das Gespräch mit dem Sprachcomputer und danach ggf. Warteschleife. Sobald die Warteschleife aufgrund eines freigewordenen Mitarbeiters beendet ist, höre ich nichts mehr. Die Leitung ist einfach still, bis entweder ich, oder der Mitarbeiter, genervt durch mein "Hallo, hören Sie mich?", auflegt.

Das Problem ist auf Rufnummern der Telekom begrenzt, der Fehler ist bei keinem anderen Telefonat aufgetreten. Es ist egal ob oder wie lange eine Warteschleife stattfindet oder dauert. Bei der Hotline für Vertriebspartner kommt man mitunter sofort durch, dann ist direkt nach dem Sprachcomputer Stille.

TelekomHilft hat bereits ein Ticket dazu eingestellt, aber außer **#93# um den Speeddial Speicher des Speedports (den ich gar nicht habe) zu löschen, kam nichts dabei rum. Da ich keinen Speedport benutzte, wäre die Telekom jetzt auch raus, es läge an meinen Endgeräten, so die Aussage der Störungsstelle.

Ich habe einen Mitschnitt eines Testanrufs erstellt und kann zum Ende der Warteschleife in Wireshark sehen, dass der RTP Datenstrom "Telekom -> Ich" abbricht, allerdings sehe ich keinen Grund. Selbst wenn ich den Filter für SIP und RTP rausnehme, sehe ich davor nur RTP Pakete.



Man kann bei 208.8 Sekunden sehen, dass nur noch RTP Pakete zur Telekom geschickt werden, aber keine mehr zurück kommen. Das ist der Moment, wo die Warteschleife endet und das Gespräch eigentlich beginnen sollte. Ein Codewechsel findet auch nicht statt, sodass ich im Moment keine Idee mehr habe.

Jemand mit Glaskugel anwesend?

 

[sonyKatze]

1. IP in SDP ist global oder lokal? Zeile c=
2. RTP/SAVP (SDES-sRTP bzw. MediaSec) oder RTP/AVP?
3. Welche Firewall(s) nutzt Du: Kommen die RTP-Pakete wenigstens an der Firewall an oder auch dort nicht?

 

[chrsto]

1. lokal, 172.16.3.102
2. RTP/AVP
3. FritzBox, von dort ist auch der Mitschnitt, daher nein, die Pakete kommen auch nicht bei der Firewall an.

 

[NDiIPP]

FritzBox

Welche? Welche FW? Was für ein Telefon?

 

[chrsto]

FritzBox 7490, 7.21, Mitel 6869 an MiVoice SMBC, Release 6.3 HF1
Die FritzBox ist nur Router inkl. DSL Modem. Telefonie über Mitel.

 

[sonyKatze]

172.16.3.102

Hilft dieser Thread? Dort verlangte die Telekom Deutschland (bei bestimmten Szenarien) Deine öffentliche IP-Adresse im SDP.

 

[chrsto]

Öffentliche IP Im SDP macht keinen Unterschied. Test dazu dauerte etwas länger, die Warteschleife war dieses mal lang .

Die Telekom weist in ihrer technischen Unterlage auch darauf hin, dass "Weitere Angaben im SDP (insb. TK-seitige IPs und Ports)" ignoriert werden und rät davon ab Techniken wie STUN zu verwenden um die NAT Erkennung der Platform nicht zu gefährden.

Es wird wahrscheinlich einfacher sein abzuwarten, bis durch ein Update der Telekom Server das Problem (zufällig) behoben wird. Der Fehler war ja vorher nicht da.

 

[sonyKatze]

Upps, nicht SDP sondern SIP. Jedenfalls war das bei @sunnyman nötig.

 

[chrsto]

Lt. Trace von ist dann beides auf öffentlicher IP, wenn du den SIP Header des INVITE meinst.

 

[chrsto]

EDIT: Gelöst: Ich habe die Prio des Codecs runtergesetzt. Damit ist der Server der Telekom zufrieden und es funktioniert.

---

Ich krame den Beitrag nochmal hoch. Zwischenzeitlich hat sich doch das VoIP Management nochmal damit auseinander gesetzt: Es ist ein Codec Problem.

Kurz nach dem Ende der Warteschleife sendet die Telekom ein Invite:



Das wird dann von meiner Anlage auch beantwortet:



Im Anschluss gibts dann noch ein ACK.

In der Antwort steht G722 vor PCMA. Wird damit auch eine höhere Prio von G722 ggü. PCMA durchgesetzt? Im initialen INVITE steht G711 an erster Stelle.

 

[sonyKatze]

SDP ist eines der fragilsten Protokolle, die ich kenne. Leider ist völlig unklar, ob man höchstens mit einer Untermenge oder all seinen Audio-Codes antworten darf. In letzterem und Deinem Fall kann eine asymmetrische Verbindung entstehen – also in jede Richtung ein anderer Audio-Codec. Die Telekom Deutschland empfiehlt sogar in manchen (allen?) Schnittstellenbeschreibungen, dass man höchstens mit einem Audio-Codec antwortet. Allerdings glaube ich nicht, dass das hier die Ursache ist. Ich vermute eher, dass das MiVoice SMBC die Zeile „msi…“ nicht interpretieren kann, danach aufhört weiter zu parsen und einfach mal alle Audio-Codecs anbietet. Kann das sein?

 

[chrsto]

Mein letzter Stand ist, das SDP nur eine Art Angebot darstellt, demnach sollte die Reihenfolge und Codecmenge eigentlich egal sein. Korrigiere mich hier gern, falls ich da falsch liege.

Ich verweise auch selbst gern auf die TR oder TU der Telekom, der Punkt mit der Anzahl der Codecs war mir aber bisher nicht bekannt, ergibt aber dann doch Sinn: Nachdem ich vor einer Woche, die Prio des G722 in der Anlage runtergesetzt habe, hatte ich Ruhe bis heute. Heute morgen war das Problem plötzlich wieder da. Scheinbar gibt es auch noch Unterschiede, welcher Telekom Server grade für mich zuständig ist.

Ich mache mal ein Ticket bei Mitel auf.

 

[sonyKatze]

Reihenfolge und Codecmenge eigentlich egal sein

Nee. Der erste Codec hat eine Sonderstellung. Und weil SDP von wirklich jedem anders interpretiert und auch implementiert wird, muss man höllisch aufpassen. Wahnsinnig komplex. Kannst Du das mit „msi“ nicht simulieren? Dann wüsstest Du, ob meine Hypothese stimmt. Aber dafür müsstest Du mit einem Test-Server verbinden, denn Du richtig programmieren/coden kannst.

 

[chrsto]

Können ja, wollen nein. Ich denke, dass das dann doch etwas die Arbeitsleistung übersteigt, die ich da reinstecken sollte.

Ich muss das nochmal für mich zusammenfassen:

Steht G722 im SDP an Position eins, funktioniert es nicht (mehr). Aussage des VoIP Management der Telekom dazu: Ich sende nur G722. Anscheinend werden die anderen Codecs verworfen, ignoriert bzw. es wird tatsächlich nur ein Codec als Antwort erwartet. Unabhängig davon akzeptiert die Anlage die Vorgabe der Telekom und sendet weiterhin G711.

Steht G711 im SDP an Position eins, funktionierte es für ca. eine Woche, bis gestern erneut Probleme auftraten. Grund aktuell unbekannt, Mitschnitte fehlen.

Das ganze betrifft nur REINVITES innerhalb der Telekom Hotline.

Bevor ich ein Ticket bei Mitel aufmache, werde ich noch ein paar Testanrufe mitschneiden. In der Hoffnung, dass ich ein paar Positiv-/Negativbeispiele mit G711 an erster Stelle bekomme.

 

[sonyKatze]

das dann doch etwas die Arbeitsleistung übersteigt

Ach so … bei mir ist das hier einmal Copy-and-Paste und dann vier Kommando-Zeilen-Aufrufe zum Neu-Übersetzen. Anruf starten. Ob ich Dir mal einen Test-Konto gebe … mhm. Die Frage ist, ob das wirklich nur bei re-INVITEs passiert. Stehen diese „msi“ auch in anderen Telefon-Abläufen, die aber klappen?

Steht G711 im SDP an Position eins […]

Hast Du schon probiert, ausschließlich G.711 A-law anzubieten?