Gelöst
T.38 Rückfall auf G.711 kein RTP Stream
vor 6 Jahren
Hallo zusammen,
seit dem 26.08.2019 ist kein Faxempfang mehr möglich. Das Phänomen sieht so aus, dass eine Aushandlung von T.38 abgelehnt wird. Daraufhin wird G.711 ausgehandelt, doch das sendende Gerät hört die gegenstelle nicht mehr und beendet die Verbindung nach 50s.
Als Hardware wird eine Octopus FX V2 R7.0.0_871 mit UC Suite eingesetzt. Der Faxempfang funktionierte bisher immer fehlerfrei.
Als Anschluss wird ein Magenta Zuhause M All-Net verwendet.
Als Anlage das Call Flow aus Wireshark einer solchen Verbindung.
Hier wurde von einem Anlagenanschluss von Vodafone (echtes ISDN) auf den IP Provider der Telekom gefaxt.
Ich danke schon einmal für Ideen oder Antworten.
1164
16
Das könnte Ihnen auch weiterhelfen
vor 6 Jahren
756
0
2
414
0
4
vor 6 Jahren
@luther-dominik
Der angekündigte Screenshot fehlt.
1
Antwort
von
vor 6 Jahren
So jetzt ist er drin.
Uneingeloggter Nutzer
Antwort
von
vor 6 Jahren
Hallo @luther-dominik ,
vielleicht bin ich ja blind.
Für mich will der INVITE das Fax mit G.711 versenden, dann fällt dem Empfänger ein "Nein ich will T.38 ", und das mag der Sender nicht (488), das Elend wird beendet.
Du darfst mich gern eines besseren belehren.
12
Antwort
von
vor 6 Jahren
Hallo zusammen,
@thomas-p: Die technischen Richtlinien sind (wenn man sich im jeweiligen Thema etwas auskennt), immer wieder interessant.
Es ist auch sehr erfreulich, daß die Telekom da so transparent ist und die entsprechenden Dokumente der Öffentlichkeit zur Verfügung stellt. 
In der genannten Fassung scheint bei der Nummerierung aber etwas durcheinander geraten zu sein (Punkt 4.2.4 taucht doppelt auf - für "Multimedia Telephony" und " DTMF ").
Der im Wireshark-Screenshot gezeigte Call-Flow sieht doch eigentlich ganz gut aus. Da kann ich spontan keine Ursache für den geschilderten Fehler erkennen. Die Frage wäre nun, wie sehen die Call-Flows (in jeweils beide Richtungen) aus Sicht des Telekom-RTP-Servers bzw. am Netzübergang Telekom <> Vodafone aus.
Ich könnte mir vorstellen, daß irgendwo in der Routingkette der RTP-Stream durch den Umschaltversuch abreißt. Da ein SBC o.ä. aber einen RTP-Stream nicht unbedingt transparent 1:1 durchleiten muß, sondern zur "anderen Seite hin" auch selbst neu generieren kann, fällt das dann unter Umständen gar nicht auf, daß der RTP-Datenstrom zwar noch vorhanden ist, aber mangels Audiodaten nur noch "stumm" ist.
cu talk
Antwort
von
vor 6 Jahren
Danke für den Hinweis zum Punkt 4.2.4. Prüfung angestoßen.
Ich habe den Abschnitt "Modem und Fax" als pdf als Update eingefügt. Somit hoffentlich klarer.
Gruß
thomas-P
Antwort
von
vor 6 Jahren
Hallo zusammen,
gibt es eine Lösung dazu. Es muss in den Richtungen "immer DSP benutzen" ausgewählt sein. Dann funktioniert alles soweit.
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 6 Jahren
Hallo zusammen,
gibt es eine Lösung dazu. Es muss in den Richtungen "immer DSP benutzen" ausgewählt sein. Dann funktioniert alles soweit.
0
Uneingeloggter Nutzer
Frage
von