Hallo zusammen,

@Stefan D.

Ja, wir hatten zu einem ähnlichen Problem schon mal in folgendem Thread die Ehre:
https://telekomhilft.telekom.de/t5/Geraete-Zubehoer/Fax-kann-empfangen-aber-nicht-gesendet-werden/td-p/4508531

Die Thematik ist relativ komplex - und ich habe in meinen beiden vorangegangenen Postings ja einiges dazu geschrieben. Von daher wäre es wohl sinnvoll, wenn sich die Experten aus der Fachabteilung den ganzen Thread hier durchlesen würden.

Zur besseren Übersicht hier nochmal die wichtigsten Punkte zusammengefaßt:

1.) Wenn man aus dem Telekom-Mobilfunknetz eine SMS als Fax zu einer Telekom-Festnetznummer schicken will, kommt es offenbar zu Problemen, wenn der am angerufenen Anschluß eingesetzte Router diese Faxverbindung auf den T.38 -Standard umschalten will. Zumindest zeigen dies die vorliegenden Tests mit einer Fritzbox 6890.

Das von der Fritzbox verschickte Re-Invite für T.38 wird vom SMS-Faxserver oder dem Telekom VoIP-Netz abgelehnt (was auch völlig in Ordnung ist). Die Faxverbindung läuft dann aber nicht mit dem herkömmlichen G.711-Standard weiter, sondern wird nach wenigen Sekunden von der anrufenden Seite beendet. Es kommt offenbar nicht einmal zu einem "Handshake" zwischen den beiden Fax-Endpunkten.

2.) Wenn dieses schnelle Auflegen vom SMS-Faxserver selbst ausgeht, könnte dies bedeuten, daß der SMS-Faxserver das Faxgerät am angerufenen Anschluß nicht mehr "hören" kann - z.B. wenn er keine RTP-Pakete von der angerufenen Seite mehr empfängt.

3.) Es gab bereits andere Fälle, in denen nach einer abgelehnten T.38 -Umschaltung keine Fax-Kommunikation über G.711 mehr möglich war. Siehe z.B. die Diskussion unter

https://telekomhilft.telekom.de/t5/Geraete-Zubehoer/Fax-kann-empfangen-aber-nicht-gesendet-werden/td-p/4508531

In dem dort diskutierten Fall war zu bemerken, daß es nach einer Ablehnung des T.38 -Re-Invites zu Auffälligkeiten in den RTP-Streams kam (komplettes oder zumindest vorübergehendes Abreißen / Unterdrücken des RTP-Streams in zumindest eine Richtung), sodaß mindestens ein Fax-Endpunkt den anderen nicht mehr hören konnte.

Ich vermute anhand meiner Analyse von Verbindungsmitschnitten, daß die VoIP-Plattform der Telekom beim Erkennen eines T.38 -Re-Invites die bereits aktiven RTP-Streams zumindest in einer Richtung(?) nicht mehr weiterleitet, solange das Re-Invite nicht geklärt ist und die Wiederaufnahme der Weiterleitung des RTP-Streams davon abhängig ist, wie die Signalisierung zwischen den beiden SIP-Endpunkten konkret aussieht und nur dann erfolgt, wenn die Plattform die SIP-Statusmeldung 488 der ablehenden Seite akzeptiert. Wird die 488-Meldung als fehlerhaft eingestuft, wird der RTP-Stream offenbar nicht wieder aufgenommen und die Verbindung scheitert, obwohl der entsprechende Endpunkt weiterhin RTP-Pakete sendet. Ein solches Verhalten widerspricht meines Erachtens der grundlegenden Idee, daß eine Verbindung beim Scheitern eines T.38 -Re-Invites einfach unverändert als G.711-Verbindung weiterlaufen soll. Ein VoIP-Netz sollte daher m.E. die RTP-Pakete eines korrekt aufgebauten G.711-Streams auch ungeachtet eines Re-Invites-Versuch weiterhin durchleiten. Ein RTP-Stream dürfte erst nach einem erfolgreichen Re-Invite enden oder beim Auslösen der Verbindung durch einen der beiden Endpunkte oder das Netz.

4.) Im aktuellen Fall sind im Wireshark-Mitschnitt zwar korrekte RTP-Streams in beide Richtungen zu sehen (siehe die diversen Screenshots), wir wissen so aber nicht, ob der RTP-Stream von der angerufenen Seite zum SMS-Faxserver dort auch korrekt ankommt oder ob er irgendwo im Netz blockiert wird o.ä. Meines Erachtens sollte dies einmal genauer überprüft werden. Falls dies direkt am SMS-Faxserver nicht möglich ist, könnte hilfsweise überprüft werden, wie die RTP-Streams am Interconnect zwischen Telekom-Festnetz und Telekom-Mobilfunknetz oder alternativ direkt "hinter" dem vom Nutzer verwendeten RTP-Server aussehen und ob der vom Nutzer ausgehende RTP-Stream dort korrekt und vollständig weitergeleitet wird.

5.) Mehr zum Ablauf der hier besprochenen Verbindung und der Kommunikation auf SIP- und RTP-Ebene in meiner ausführlicheren Analyse hier im Thread (siehe dazu meine beiden vorangegangenen Postings).

Bei Bedarf kann @Mächschen  den Mitschnitt sicher auch für die Telekom-Experten bereitstellen. Ich nehme aber mal an, daß man für eine netzseitige Prüfung auch eine aktuelle Verbindung bräuchte, die man im Netz passend nachverfolgen könnte.

cu talk

@talk 

Sorry, für die späte Antwort.

Für eine Analyse benötige ich ein aktuelles Beispiel, also nicht älter als sieben Tage.

Benötigte Daten wären A- und B-Rufnummer sowie der genaue Zeitpunkt, am besten per PM senden.

Hallo zusammen,

@Meester Proper: Danke für Deine Rückmeldung!

Und damit hole ich auch @Mächschen wieder an Bord: Um "frische" Verbindungsdaten zu generieren, wäre damit ja ein erneuter Testanruf nötig (mit den bekannten Rahmenbedingungen). Vielleicht wäre es gut, für den neuen Testanruf auch wieder einen Paketmitschnitt zu erstellen, damit man diesen ggf. auch noch analysieren kann. Ich weiß ja nicht, welche Daten die Telekom-Fachabteilung alleine aus den Verbindungsdaten der VoIP-Plattform genau einsehen kann (vermutlich die Signalisierung auf SIP-Ebene, aber keine RTP-Datenströme?)...

cu talk