[Problem] SIP Geräte über Codec G.722 (HD-Telefonie) bekommen Timeout (Ursache 408)

[inetdesaster]

Hallo,
ich stehe vor einem Problem. Seit fast 2 Jahren funktioniert meine FritzBox 6590 erfolgreich am Vodafone Kabel(Red 100). Ich nutze ein Fritz DECT Telefon, ein OpenStage 60 über SIP und das Programm Phoner über SIP (jeweils an am Fritzbox Registrar angemeldet). Es gab nie Probleme.

Seit 2-3 Wochen kann ich an den SIP-Geräten auf einmal nicht mehr raus telefonieren. Nach ca. 30 Sekunden kommt "besetzt" und in der FritzBox erscheint das Ereignis: "Internettelefonie mit *** über sip.kabelfon.vodafone.de war nicht erfolgreich: Ursache: (408)"

Alle 3 Geräte telefonieren sonst immer in HD (wenn bei Gegenstelle verfügbar). Das FritzFon kann auch weiterhin HD-Gespräche (G.722) aufbauen. Die beiden SIP-Geräte allerdings nicht mehr, jdeoch wenn ich es auf G.711 umstelle, funktioniert es tadellos. Allerdings kommen eingehende Anrufe per G.722 auf den SIP Geräten erfolgreich an.

Erst dachte ich ja, dass die wegen Corona oder so vielleicht die HD-Codecs unterbinden.. Wer weiß.. Aber warum kann das FritzFon dann weiterhin solche Gespräche aufbauen... Und vor allem, was macht es in der Gegenstelle für ein Unterschied mit welchem Gerät ich anrufe? Bekommen die irgendwelche Merkmale der Endgeräte übermittelt, sodass es das Timeout gibt?

Meine Versuche bisher: Alle VPN-Verbindungen unterbrochen, Neustarts. Update von Fritz Firmware 7.12 auf 7.19 beta, SIP-Geräte in Fritzbox neu eingerichtet, Sicherheit für Telefonate von IP-Telefonen ins Ausland etc. alles rausgenommen...

Ich weiß nicht weiter. Da ich aber seit längerem nichts an der Fritzbox eingestellt habe oder Updates gemacht habe, bin ich fest davon überzeugt, dass das mit Vodafone zu tun hat und nicht mit der FritzBox..
Was meint ihr? Habt ihr Tipps oder ähnliche Erfahrungen?

Vielen Dank schonmal!
Gruß
inetdesaster

 

[weißnix_]

G.711 gänzlich zu deaktivieren scheint mir keine gute Idee. Wenn die Aushandlung von G.722 aus irgendeinem Grund fehlschlägt, hast Du den Salat.
Eventuel kannst Du das in Logfiles nachvollziehen.

 

[inetdesaster]

Vollzitrat von darüber gemäß Boardregeln entfernt by stoney

Leider kann ich im Debug Log bei Phoner nichts nachvollziehen. Zu mindest kommt nach Trying der Session Progress und dann wars das. Beim Besetztzeichen kommt keine weitere Ausgabe, außer die in der Fritzbox.
Das interessante: G.711 ist nie deaktiviert gewesen, es ist einfach nur an zweiter Stelle. Aber er nutzt es nicht, sondern macht dieses seltsame Vorgehen..

 

[gehtdoch]

Du hast kein Codec-Problem. G.722 hat auch die gleiche Bandbreitenanforderungen wie G.711 - gibt also keinen Grund, das nicht mehr zu fahren.

Wenn Du ein Codec-Problem hättest, würdest du sofort ein not acceptable here bekommen und nicht austimen. Das Austimen spricht für ein Problem auf IP-Ebene. Firewall? NAT? Bereich der genutzten RTP-Ports verändert? Hier kommst Du nur mit Tracen an allen Stellen weiter, um zu sehen, was da abgeht.

Sind alle Calls betroffen? Nur bestimmte? Eindeutig reproduzierbar? Wenn reproduzierbar -> dann durchgängig tracen (pcap / Wireshark kann VoIP): am WAN-Eingang, am Ausgang, auf Deiner Büchse, wo der Client läuft und dann die Traces übereinanderlegen.

 

[inetdesaster]

Unnötiges Vollzitat von darüber gemäß Boardregeln entfernt by stoney

Danke schonmal für deine Antwort! Wie gesagt, es sind nur die Calls von SIP Geräten an der Fritzbox über G.722 betroffen. Ein DECT-Telefon an der gleichen Fritzbox kann allerdings G.722 aufbauen. Also auch wenn es ein Problem auf IP-Ebene ist, es muss ja einen Zusammenhang zum Codec geben.

Im Anhang sind Wireshark SIP Aufzeichnungen einmal von G.722 und G.711. Einzige Umstellung war, dass ich bei dem G.711 Gespräch den Codec G.722 deaktiviert habe.
Bei dem G.722 Protokoll ist hinzuzufügen, dass ca. 30 Sekunden vor dem Code 480 das Ereignis mit Code 408 in der Fritzbox erzeugt wird.

 

[gehtdoch]

Moin!

• Es handelt sich um einen ausgehenden Call
• vermutlich auf dem SIP-Client selbst getraced
• Im Fehlerfall kommt kein 200 OK zurück (d.h., der Angerufene scheint nicht abzunhemen / zu antworten), wobei der Mediastream nach dem 183 ja schon läuft (selbst Provider scheint Pakete zu schicken / falls die nicht von der FB generiert wurden - daher wäre eben noch die Sicht auf die WAN-Schnittstelle interessant)
• Mangels fehlendem 200 OK kommt der 408er Timeout, was die FB offensichtlich mit 480 hintenraus "übersetzt"

Aus Deinem Trace ist zu erkennen, dass Du ziemlich viele Codecs im SDP hast. Da habe ich schon Devices gesehen, die damit nicht klar kommen und dann "schlapp" machen. Reduziere die Liste doch mal auf max. 3 Codecs: G.722 / alaw / ulaw - damit solltest Du eigentlich weltweit klarkommen. Das könnte nämlich auch der Grund sein, warum Du kein Problem mehr hast, wenn Du G.722 entfernt hast: weil dann die Liste kleiner wurde.

 

[sonyKatze]

Sieht so aus, als würde irgendwer hinter Vodafone quasi abstürzen. Die FRITZ!Box bricht nach 30 Sekunden ab. Vodafone bricht nach 60 Sekunden ab. Weil beide merken, dass was krumm ist. Kannst Du mal zum Test jemanden in einem anderen Zielnetz anrufen; zum Beispiel Vodafone Kabel intern, aber besten im selben Vorwahl-Bereich oder wenigstens Bundesland intern; passiert das auch dann?

Wir müssten uns mal genauer die SDP-Nachrichten anschauen, also in Wireshark auf sdp filtern, Abschnitt auswählen und das dann als Text-Datei exportieren. Das Exportieren ist wichtig, weil Wireshark beim Interpretieren auch schon einiges repariert und damit unsichtbar macht. Aber die eigentliche Ursache könnte alles Unmögliche sein (IP-Adresse, Absende-Name, Audio-Codec, …). Das kannst Du nur ermitteln, indem Du die Unterschiede mit einem Test-Programm wie sipp Stück für Stück ausschließt.

 

[FunkReich]

Beim Codec Problem gibts für gewöhnlich ein
488 Not Acceptable Here
zurück.

Schau mal im "BYE" Paket nach dem Reason Code. z.b. normales BYE durch Auflegen sieht so aus:

Reason: Q.850 ;cause=16 ;text="2"

Vielleicht gibt das den genaueren Grund des Abbruchs.

 

[inetdesaster]

Ich hatte aus privaten Gründen leider keine Möglichkeit mehr, es zu testen.
Heute war ein Anbieterwechsel und nun kann ich keine neuen Logs mitschreiben.
Es hätte mich zu sehr gefreut, die Ursache zu finden..
Vielen Dank euch.
Ich denke, der Thread kann geschlossen/gelöscht werden.