crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
15.08.2019 19:23 Zuletzt bearbeitet: 15.08.2019 19:33 durch den Autor
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.
Gelöst! Gehe zu 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.
15.08.2019 19:31
15.08.2019 19:34
So jetzt ist er drin.
15.08.2019 19:57
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.
15.08.2019 20:01
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.
15.08.2019 20:12
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.
15.08.2019 20:27
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 ?
15.08.2019 22:12
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)
16.08.2019 07:18
Ich habe deine Frage mal hier:
plaziert.
16.08.2019 09:17
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.
16.08.2019 11:28 Zuletzt bearbeitet: 16.08.2019 11:29 durch den Autor
Hallo zusammen,
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
16.08.2019 11:31
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.
16.08.2019 13:40 Zuletzt bearbeitet: 19.08.2019 08:41 von Anja S.
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
16.08.2019 15:19
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
19.08.2019 08:55
Hallo zusammen,
gibt es eine Lösung dazu. Es muss in den Richtungen "immer DSP benutzen" ausgewählt sein. Dann funktioniert alles soweit.
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.