SMS im Festnetz - falscher Zustellbereicht und Problem mit T.38
vor 4 Jahren
Mit T.38 und dem Zustellbereicht haut etwas bei SMS im Festnetz nicht hin.
Ich habe das mal im folgenden dargestellt:
Wie kann der Bug nachgestellt werden?
Beispielsweise SMS von T-Mobile zu einem Fax ins (IP) Festnetz der Telekom mit aktiviertem T.38 senden. Hierzu braucht man nur eine MSN, eine Fritzbox und ein T-Mobile-Handy.
Welches Ergebnis hast du erwartet?
SMS kommt als Fax raus.
Zustellbericht wird erst dann als zugestellt Versand.
Welches Ergebnis hast du erhalten?
Verbindung kommt mit G.711 Codec zu Stande.
Es wird versucht auf T.38 umzuschalten.
Verbindungsabbruch mit SIP Statuscode 488 ab.
Zustellbericht wird als zugestellt gesendet.
Meine Bitte an die Community:
Kann das jemand mit einem nicht-AVM Router nachstellen?
Meine Bitte ans Team:
Ist das Problem bekannt und wird es behoben?
893
21
5 Sterne Mitgestalter*in
vor 4 Jahren
@olliMD
Hab hier mal das Fass geöffnet.
0
1 Stern Mitgestalter*in
vor 4 Jahren
Hallo zusammen,
Bei diesem Thema kommen mehrere Dinge zusammen:
1.) Ein sehr exotischer Dienst (SMS im Festnetz und das auch noch kombiniert mit Fax)
2.) Ein Protokoll mit einigen Tücken ( T.38 )
3.) Support-Strukturen bei Carriern und Herstellern, die oftmals mit den Untiefen von SIP und verwandten Protokollen nicht so wirklich hundertprozentig vertraut sind: Der 1st-Level-Support kann mit solchen speziellen Anfragen oft nichts anfangen, 2nd- und 3rd-Level teilweise auch nicht wirklich (falls sie die Anfrage überhaupt erreicht und das Ganze nicht irgendwo auf dem Weg dorthin versackt)
4.) Fax über VoIP ist ein Dilemma: Es funktioniert nicht gut genug, um es wirklich risikolos benutzen zu können, aber auch nicht schlecht genug, daß die Branche sich nochmal grundsätzlich mit dem Thema auseinander setzen müßte.
Ich befürchte daher, daß Du hier keinen Nutzer finden wirst, der das hier passend nachstellen kann und wenn vergleichbare Fälle nur selten bis nie auftreten, wird das Problem evtl. auch nicht gelöst werden können.
Daher würde ich einen anderen Ansatz empfehlen: Mit der Fritzbox kannst Du doch relativ einfach einen Paketmitschnitt einer solchen Verbindung erstellen, den man dann mit Diagnosetools wie Wireshark analysieren kann. Wie sowas aussehen kann, wurde hier im Forum schon mal in einem anderen Fall durchprobiert, siehe:
https://telekomhilft.telekom.de/t5/Geraete-Zubehoer/Fax-kann-empfangen-aber-nicht-gesendet-werden/m-p/4508531
Meine Diagose hatte sich am Ende allerdings nicht ganz bewahrheitet, das Problem lag offenbar nicht an den fehlenden SDP-Daten, sondern an der Syntax der Warning-Meldung des genutzten Speedport-Routers, (siehe dazu diese onlinekosten.de-Diskussion). Immerhin konnte so aber Licht in die Thematik an sich gebracht werden. Ob seitens der Telekom dann noch irgendwelche Maßnahmen erfolgt sind, ist mir allerdings nicht bekannt. Meiner Ansicht nach hätte trotz der nicht standardkonformen Warning-Meldung der RTP-Stream unverändert weiterlaufen müssen.
Ich kann Dir - ähnlich wie in oben zitiertem Parallelthread - meine Hilfe bei der Analyse anbieten. Eine Erfolgsgarantie kann ich Dir aber beim besten Willen nicht geben.
cu talk
19
Antwort
von
vor 4 Jahren
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