Faxen funktioniert seit Umstellung auf Telekom VoIP nicht mehr. Sipgate besser?

[Meester Proper]

Demnach wurde das Problem inzwischen gelöst? Würde in einem vergleichbaren Fall heute der RTP-Stream auch nach der "fehlerhaften" SIP-488-Antwort wieder durchgeschaltet werden oder würde der RTP-Stream durch den Re-Invite gar nicht mehr unterbrochen werden?

Meines Wissens wurden Endgeräte mit dem Fehler zwischenzeitlich mit einem Update ausgestattet. Das Verhalten der alten P-CSCF bei fehlerhaftem Syntax wurde meines Wissens aber nicht angepasst.

Meines Erachtens wäre die zweite Variante (RTP-Streams werden auch nach Versand des Re-Invites unverändert durchgeleitet solange dieser nicht bestätigt wurde) die bessere und auch standardkonformere - auch mit Blick auf evtl. andere Probleme mit gescheiterten bzw. abgelehnten Re-Invite-Versuchen.

Hier kollidiert auch wieder Theorie und Praxis: Sobald auf der Signalisierungsebene eine neue SDP Offer eintrifft, wird das entsprechende RTP-Gateway (bei Ericsson auch als "BGF" bezeichnet) informiert. Durch die fehlende SDP Answer bzw. Ablehnung des INVITE kam es dann zu den besagten Problemen.

Es gab im onlinekosten.de-Forum ja auch den Fall mit den Faxverbindungen von 1&1-Kunden zu 0800-Rufnummern bei VSE-Net, die ebenfalls Probleme machten, wenn ein T.38-Re-Invite versucht und abgelehnt wurde. Es konnte nach meiner Erinnerung aber leider nicht geklärt werden, woran es lag und ob diese Verbindungen im Transit über die Telekom liefen (von Nicht-Telekom-TNB zu einer 0800 eines anderen Nicht-Telekom-TNB ist die Wahrscheinlichkeit aber m.E. relativ groß). Möglicherweise war da auch irgendeine Kleinigkeit in der SIP-Signalisierung die Ursache. Sowas bei einer Verbindung zu untersuchen, an der mehrere Carrier beteiligt sind, ist oftmals eh schon fast ein Ding der Unmöglichkeit - und wenn einfach irgendwo in der Routingkette der RTP-Stream blockiert wird und man nicht weiß, wo, wird es nicht einfacher... ;-)

Für solche Fälle gibt es eigentlich definierte Prozesse zwischen den Carriern. Hier muss der Kundenservice eines Carriers natürlich erst einmal den Fehler erkennen und an den anderen Carrier weitergeben. Ohne einen sehr hartnäckigen Mitarbeiter wird, sofern es tatsächlich einen Fehler gibt, so etwas dann aber auch eher selten gelöst.

 

[gehtdoch]

T.30 via VoIP/G.711 / Fax passthrough funktioniert bei ordentlichen "Leitungen" problemlos und nach wie vor sehr gut. Da kann man auch über 100 Seiten damit übertragen. Als Verantwortlicher für die Infrastruktur für eine hohe 5-stellige Anzahl von Faxen jeden Tag weiß ich das!

@Meester Proper hat beschrieben, warum T.38 keinen Sinn macht. Daher T.38 grundsätzlich abschalten (btw: T.38 ist kein Codec)! Leider wollen das viele nicht kapieren und daher kommt es am Ende des Tages immer wieder sinnlos zu Problemen.

Wodurch zeichnet sich eine "ordentliche Leitung" aus:
- keinerlei Paketverluste
- geringer Jitter

Im "billger geht immer" - Wahn (least cost routing z.B. oder überlasteten Leitungen (nur eine überlastete und gleichzeitig schlecht gemanagte Leitung kann eine billige Leitung sein)) werden natürlich bevorzugt die letzten Schrott-Leitungen gekauft / genutzt, wo es reiner Zufall ist, ob und wann ein Paket durchkommt. Das funktioniert bei Fax natürlich nicht, weil T.30 dafür nicht designed wurde.

Also nicht auf T.30 schimpfen, sondern dafür sorgen, dass die Devices über ordentliche Leitungen angebunden sind. Wenn diese Anforderung zwischen TN A und B durchgängig erfüllt ist, funktioniert das mit dem Faxen auch heute noch problemlos.

Das witzigste ist ja oft auch die Reaktion der Kunden, wenn man z.B. deren Leitungen repariert wg. Faxproblemen und sie dann ganz verwundert feststellen, dass ja Telefonie jetzt auch (wieder) besser geht und selbst die eine oder andere Anwendung plötzlich weniger hängt bzw. weniger träge ist.

Ach ja, noch was: das Leitungsproblem muss gar nicht im WAN liegen - bei manchem Betroffenen ist das LAN schlechter als das WAN ... .

 

[Wechseler]

T.30 via VoIP/G.711 / Fax passthrough funktioniert bei ordentlichen "Leitungen" problemlos

Isch abe gar keine "Leitung" mehr.

T.38 ist kein Codec

Ist einfach nur das Einpacken von Fax-Daten in IP. Bei E-Mail-Versand funktioniert das ja auch, da macht ja auch niemand einen UUCP-Call per VBD.

Also nicht auf T.30 schimpfen, sondern dafür sorgen, dass die Devices über ordentliche Leitungen angebunden sind

Circuit Switched Data ist tot. Ich kann also nur noch FoIP verwenden.

 

[gehtdoch]

Isch abe gar keine "Leitung" mehr.

Echt? Verwendest Du Rauchzeichen? Oder sonst irgendwas?

Auch paketorientierte Datenübertragung basiert am Ende des Tages auf physischen Leitungen. Wenn man die paketorientierte Datenübertragung auf der physischen Leitung von a nach b versteht (und alle weiteren Komponenten dazwischen), dann weiß man auch, wie man diese "Leitung(en)" hinsichtlich Echtzeitanwendungen (dazu gehört Voice bzw. Fax) zu betreiben hat bzw. auf welche Parameter es ankommt.
Sobald irgendwo einer auf der Strecke nicht mitspielt (weil die physische Leitung defekt oder überlastet ist z.B.), kann man Echtzeitanwendungen vergessen (das war übrigens "früher" auch schon so - mal ganz abgesehen davon).

 

[Wechseler]

Echt? Verwendest Du Rauchzeichen? Oder sonst irgendwas?

Nein, ich faxe per T.38 über LTE. Ich werd doch nicht für FoIP eine Strippe vorhalten, die mindestens 35 € im Monat kostet.

Voice-Band-Data ginge notfalls zwar auch, aber dafür bräuchte ich ja wieder diese "Echtzeitanwendung", die mir T.38 praktischerweise erspart.