T.38 Rückfall auf G.711 kein RTP Stream

Gelöst

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.

 

1 AKZEPTIERTE LÖSUNG

Hallo zusammen,

gibt es eine Lösung dazu. Es muss in den Richtungen "immer DSP benutzen" ausgewählt sein. Dann funktioniert alles soweit. 

Lösung in ursprünglichem Beitrag anzeigen  

Gelöschter Nutzer

@luther-dominik 

 

Der angekündigte Screenshot fehlt.

So jetzt ist er drin.

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.

 

Das Fax wird zunächst versucht mit T.38 anzufragen. Dann wird mit 488 geantwortet. Daraufhin wird versucht über G.711 zu senden, allerdings kommen hier keine Pakete von der Telekom Plattform mehr an. Dieses Problem tritt nicht auf, wenn vom gleichen Anschluss auf diesen gefaxt wird. Dabei wird dann auch durchgehend T.38 verwendet.

@luther-dominik 

Wie kommst du zu der mutigen Aussage?

Ich sehe das nicht so wie du.

Der INVITE wird doch mit G.711 gesendet, dann gibts das Trying und Ringing, das Fax nimmt an (200 OK) und das Gezwitschere beginnt.

Jetzt fällt dem Fax ein, ich will T.38, daraufhin wird ein Re-Invite mit T.38 gesendet, den der Telekom-Server mit 488 ablehnt.

 

Die Frage ist, hat jemand hier die aktuelle Software v2 R7.0.0_871 am IP MSN Anschluss am laufen hat mit UC Suite Fax ?

Die Fragen die sich mir stellen sind:

 

1. Warum klappt das Faxen vom eigenen Anschluss auf dem eigenen Anschluss fehlerfrei. Hierbei wird T.38 verwendet.

 

2. Warum klappt die Umschaltung auf G.711 nicht?  Der RTP Strom, der von der Plattform kommt ist leer und enthält keine Daten, nach der 488 Not acceptable here Meldung.

 

als Anlage mal ein Fax vom IP auf IP (Bild 1 und 2)sowie vom Isdn auf ISDN (Bild 3 und 4)

 

 

Hallo @luther-dominik,

 

dein Problem werden wir wahrscheinlich nicht ohne konkrete Informationen zur einzelnen Verbindung angehen können. Daher würde ich dich bitten, mir eine private Nachricht zukommen zu lassen.

 

@wari1957: Der Ablauf der Signalisierung ist korrekt, sofern die A-Seite kein T.38 kann. Die Sendeseite sollte nach dem Abweisen des Re-INVITE mit T.38 mit einem SIP 488 antworten, der Call Flow verläuft unverändert mit RTP und G.711.

 

Gruß

Erik.

Hallo zusammen,

 

@luther-dominik:



einmal schreibst Du: "Daraufhin wird versucht über G.711 zu senden, allerdings kommen hier keine Pakete von der Telekom Plattform mehr an" und einmal "Der RTP Strom, der von der Plattform kommt ist leer und enthält keine Daten, nach der 488 Not acceptable here Meldung".

 

Ein fehlender RTP-Stream ist meines Erachtens aber etwas anderes, als ein bestehender RTP-Stream, der jedoch plötzlich "stumm" ist. Daher sollte man das genau auseinanderhalten.

 

Im ersten Wireshark-Screenshot startet der (aus Deiner Sicht) eingehende RTP-Stream von der Telekom-Plattform bei Sekunde 76,711169. Er enthält 2.433 Pakete und dauert 48,642 Sekunden. Damit läuft er offenbar bis zum Ende der Verbindung durch. Hast Du mal mit der "Player"-Funktion von Wireshark in diesen Stream hineingehört, ob er plötzlich verstummt (und nur noch "Stille" übertragen wird)?

 

cu talk

 Es wird nach der Umschaltung auf G.711, nur noch Stille übertragen. Dies kann man beim Stream auch gut hören. Der RTP Stream ist sofort und dann durchgehend stumm.

Hallo @luther-dominik, @talk,

In der technischen Telekom Schnittstellenbeschreibung für SIP 1TR114 (Stand 07.01.2019) ist der Fax-Protokoll-Ablauf G.711/T.38/G.711 unter dem Punkt "4.2.4.3 Fax und Modem", Seite 19, im Detail beschrieben.
Ich hoffe eine nützliche Info zur Klärung (falls noch nicht bekannt).

PS: G.711 muss immer für die Aushandelung aktiviert sein, um ein Fax mit T.38 übertragen zu können!

Gruß

Thomas-P

--------------------------------------

Update 19.08.19: Der Punkt 4.2.4.3 Fax und Modem ist nun im Anhang als pdf-Auszug angefügt. Dort ist der Ablauf zwischen T.38 und G.711 sichtbar

 

 

Hallo zusammen,

 

@thomas-p: Die technischen Richtlinien sind (wenn man sich im jeweiligen Thema etwas auskennt), immer wieder interessant. Fröhlich Es ist auch sehr erfreulich, daß die Telekom da so transparent ist und die entsprechenden Dokumente der Öffentlichkeit zur Verfügung stellt. Fröhlich

 

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"). Zwinkernd

 

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

Telekom Experte
Guten Morgen @talk,
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

Hallo zusammen,

gibt es eine Lösung dazu. Es muss in den Richtungen "immer DSP benutzen" ausgewählt sein. Dann funktioniert alles soweit.