#1  (Permalink
Alt 04.07.2020, 12:14
talk talk ist offline
Senior Mitglied
 
Registriert seit: 28.12.1999
Beiträge: 541
Standard Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Hallo zusammen,

Probleme mit Faxübertragungen via VoIP sind ja in den Foren ein immer wieder diskutiertes Thema, welches aber oft relativ allgemein bzw. oberflächlich analysiert wird. In vielen Fällen kommen solche Diskussionen über allgemeine Ratschläge wie "Geschwindigkeit heruntersetzen", "Fehlerkorrektur ein-/ausschalten", etc. nicht hinaus - auch weil die Daten für eine genauere technische Analyse meist fehlen.

Im Telekom-Hilft-Forum gibt es zur Zeit eine interessante Diskussion, die mal einen tieferen Blick auf die Thematik wirft:

Ausgangspunkt ist ein Fall, bei dem mit einem Speedport W724V (Typ B) keine Faxübertragung zu einem bestimmten Festnetz-Anschluß möglich ist. Ein Paketdatenmitschnitt zeigt, daß nach dem Erkennen einer Faxverbindung die angerufene Seite (oder irgendein Netzelement auf dem Weg zum Angerufenen) versucht, die aufgebaute G.711-Verbindung auf den speziellen T.38-Faxstandard umzuschalten.

Das entsprechende Re-Invite wird vom Speedport mit Status-Code 488 (not acceptable here) abgelehnt (die Speedport-Router unterstützen nach offiziellen Angaben bekanntlich kein T.38), die Verbindung läuft aber nicht mit dem anfangs vereinbarten G.711-Codec weiter. Stattdessen reißt fast zeitgleich zum Re-Invite der eingehende RTP-Datenstrom (vom Angerufenen zum Nutzer) ab, sodaß das Faxgerät des Anrufers das Faxgerät am anderen Ende der Leitung nicht mehr hören kann. Der Speedport W724V (Typ B) wiederholt im Folgenden mehrfach seine 488-Meldung, doch es wird kein eingehender RTP-Stream mehr durchgeschaltet. Währenddessen sendet der Speedport den von ihm ausgehenden RTP-Datenstrom weiter. Es handelt sich also quasi um eine "einseitige" Übertragung, die logischerweise scheitern muß.

Die Reaktion der Telekom auf die dortige Forumsdiskussion bestand darin, den Speedport W724V (Typ B) gegen einen Speedport Smart auszutauschen.

Das Erstaunliche: Mit dem Speedport Smart funktioniert die Faxübertragung zum betroffenen Ziel einwandfrei, wie mehrere Tests gezeigt haben. Auch mit diesem Router reißt der eingehende RTP-Stream etwa zeitgleich zum eingehenden Re-Invite ab. In diesem Fall kehrt er aber kurz nach der Ablehnung des Re-Invites (ebenfalls mit Statuscode 488) plötzlich wieder zurück (nach einer Lücke von etwa 15 fehlenden RTP-Paketen) und läuft danach ungestört weiter. Es findet also auch mit diesem Router kein Umschalten auf T.38 statt, allerdings funktioniert nun der "Fallback" zurück zu G.711.

Wie kann das sein? Da ich freundlicherweise von der betroffenen Nutzerin die Möglichkeit bekam, Paketdatenmitschnitte von Verbindungen beider Router zu untersuchen, konnte ich mit dem Netzwerktool Wireshark mal genauer erforschen, inwieweit sich die beiden Speedport-Router beim Verbindungsaufbau unterschiedlich verhalten:

Beide Router (Speedport W724V Typ B und Speedport Smart) lehnen das Re-Invite mit dem SIP-Status-Code 488 (not acceptable here) ab. Beim Speedport Smart enthält das betreffende SIP-Paket aber auch noch SDP-Daten, mit denen er nochmals die von ihm unterstützten Codecs mitteilt; beim Speedport W724V (Typ B) ist das 488er-Paket hingegen eher kurz und ohne SDP-Daten.

Bildlich gesprochen verhalten sich die beiden Router also wie folgt auf die Einladung (Re-Invite) zur T.38-Umschaltung:

- Speedport W724V (Typ B): "T.38? Kenne ich nicht!"

- Speedport Smart: "T.38? Kenne ich nicht! Aber ich unterstütze G.711 (und noch ein paar weitere Codecs)..."

Hier auch als Screenshots:

a) Speedport W724V (Typ B): SIP-Status 488 ohne SDP-Daten



b) Speedport Smart: SIP-Status 488 mit SDP-Daten



Meine Interpretation: Irgendein "Netzelement" (z.B. ein Telefonie-Server bzw. -Gateway in der Routingkette) unterbricht den (eingehenden) RTP-Datenstrom, wenn ein Re-Invite verschickt wird und schaltet ihn nach einer Ablehnung des Re-Invites erst dann wieder durch, wenn die Codecs erneut vereinbart wurden.

Damit stellt sich die Frage, ob das Verhalten des "Netzes" überhaupt korrekt ist bzw. welche Anforderungen eine 488-Meldung eigentlich erfüllen muß.

Die Internet-Norm RFC3261, in der das SIP-Protokoll definiert ist, sagt hierzu in Punkt 4:

Zitat:
If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics.
Das Ablehnen des Re-Invites darf also nicht zu einem Scheitern der gesamten Verbindung führen, sie müßte stattdessen mit den ursprünglich vereinbarten Eigenschaften weiterlaufen (was hier nicht der Fall ist). Das Netzelement, welches den RTP-Stream zum Anrufer unterdrückt, würde sich demnach regelwidrig verhalten.

Außerdem heißt es in Punkt 21.4.26:

Zitat:
21.4.26 488 Not Acceptable Here

The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.
Die einen Re-INVITE ablehnende Seite kann also in der 488er-Meldung nochmal die von ihr unterstützten Codecs mitteilen, sie muß es aber nicht! Da laut Pkt. 4 die Verbindung bei einer Ablehnung des Re-Invites einfach unverändert weiterlaufen soll, ist eine erneute Mitteilung der Codecs auch im Grunde überflüssig.

Fazit:

Die Untersuchung hat gezeigt, daß im vorliegenden Fall das Gelingen eines Fallbacks von einer gescheiterten T.38-Umschaltung zurück zu G.711 offenbar vom Aufbau der ablehnenden 488-Meldung des Routers abhängig ist.

Ich vermute außerdem, daß die Ursache für das Phänomen irgendwo "im Netz" zu finden ist - entweder bei einem der beteiligten Server der Telekom VoIP-Plattform oder (falls die Nummer des Angerufenen nicht bei der Telekom geschaltet ist) bei der VoIP-Technik des Ziel-Carriers.

Desweiteren vermute ich, daß dieses Problem schon seit längerem bei unterschiedlichen Fällen auftritt und möglicherweise auch der Grund für die gescheiterten Fax-Verbindungen in einem anderen hier bei onlinekosten.de diskutierten Thread ist (dort ging es um Probleme von 1&1-Nutzern bei Fax-Verbindungen zu 0800-Rufnummern bei VSE-Net; diese Anrufe wurden wohl im Transit über das Telekom-Netz vermittelt). Dort gab es ebenfalls das Phänomen, daß ein RTP-Stream bei einem T.38-Re-Invite abreißt und auch nach dessen Ablehnung nicht mehr wieder kommt.

Wer die gesamte Diskussion im Telekom-Hilft-Forum nachlesen will, kann dies wie gesagt hier tun.

Ich hoffe mal, daß es dort noch möglich ist, die gesammelten Erkenntnisse an die passende Stelle bei der Telekom weiterzuleiten, um das vorliegende Problem in den Griff zu kriegen (seit meinem letzten Posting im Telekom-Hilft-Forum zu diesem Thema gab es leider noch keine Rückmeldung). Das Austauschen des Routers mag zwar im Einzelfall weiterhelfen, ist ja aber keine Lösung des Problems insgesamt.

Evtl. helfen diese Erkennisse auch, vergleichbare Fax-Probleme mit anderen Routern bzw. in anderen VoIP-Netzen zu lösen. Meinungen und Ideen zum Thema sind willkommen.

cu talk
Mit Zitat antworten
  #2  (Permalink
Alt 04.07.2020, 13:46
Benutzerbild von Telekom hilft Team
Telekom hilft Team Telekom hilft Team ist offline
Verifizierter Benutzer
 
Registriert seit: 23.07.2010
Beiträge: 5.234
Standard AW: Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Hallo talk,

ich danke dir herzlich für die ganze Arbeit, Zeit und Energie, die du in dieses Thema gesteckt hast!

Eines ist sicher: Kein Feedback bleibt ungehört oder ungelesen. Und es wird natürlich auch an die jeweiligen Fachansprechpartner weitergeleitet.

Ich hake aber für alle Fälle bei den Kollegen noch einmal nach. Doppelt hält bekanntlich besser.

Viele Grüße
Jutta T.
__________________
Telekom hilft Team Kundenservice Telekom Deutschland GmbH
Haben Sie Fragen an den Telekom Kundenservice? Wir helfen Ihnen gerne!
Mit Zitat antworten
  #3  (Permalink
Alt 04.07.2020, 15:52
Mot Mot ist offline
Senior Mitglied
 
Registriert seit: 23.08.2011
Beiträge: 4.605
Standard AW: Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Sehr aufschlussreich, danke talk!
Mit Zitat antworten
  #4  (Permalink
Alt 04.07.2020, 18:12
talk talk ist offline
Senior Mitglied
 
Registriert seit: 28.12.1999
Beiträge: 541
Standard AW: Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Hallo zusammen,

Zitat:
Zitat von Telekom hilft Team Beitrag anzeigen
Eines ist sicher: Kein Feedback bleibt ungehört oder ungelesen. Und es wird natürlich auch an die jeweiligen Fachansprechpartner weitergeleitet.

Ich hake aber für alle Fälle bei den Kollegen noch einmal nach. Doppelt hält bekanntlich besser.
Auf jeden Fall!

Es wäre ja auch schade, wenn dieses Thema einfach im Sande verlaufen würde.

Man muß sich nur mal überlegen, daß bei den meisten Carriern im Normalfall das vorliegende Thema beim telefonischen (Privatkunden-)Support o.ä. vermutlich entweder mit den allgemeinen Fax-Tipps wie "Geschwindigkeit heruntersetzen" o.ä. abgespeist würde oder spätestens nach dem Routertausch als erledigt angesehen worden wäre. Und dann wäre das Problem irgendwann einmal woanders erneut aufgetreten und das ganze Spiel wäre dort wieder von vorne losgegangen.

Die meisten Nutzer (damit meine ich die Telekom-Kundin, die das Thema im Telekom-hilft-Forum eröffnet hat) hätten vermutlich auch nicht die Geduld gehabt, sich näher mit dem Thema zu beschäftigen und schließlich für einen Dritten (also mich) auch noch Mitschnitte der Verbindungen anzufertigen, was für den Normalnutzer auch wieder etwas ungewohntes ist.

Zur Vollständigkeit zeige ich nun noch die Screenshots aus Wireshark, mit denen man den Datenverkehr der beiden Router jeweils beim Aufbau einer Faxverbindung sehen kann. Gefiltert wurde übrigens in beiden Fällen auf SIP- und RTP-Pakete, was die Sprünge in der Paketnummerierung erklärt.

(217.85.x.x ist der DSL-Anschluß, an dem der Speedport angeschlossen ist; 217.0.27.X ist der SIP-Server der Telekom für die Signalisierung; 217.0.6.X ist der RTP-Server der Telekom, über den die Nutzdaten [also das Audiosignal] laufen).

1.) Verbindungsaufbau Speedport W724V (Typ B):



Man sieht, wie sich der Speedport und der RTP-Server der Telekom zunächst abwechselnd RTP-Daten zusenden. Paket 1142 ist also ein RTP-Paket vom Speedport ins Netz, Paket 1143 ist ein RTP-Paket vom Netz zum Speedport und so weiter...

Ab Paket 1150 sind auf einmal nur noch die RTP-Daten vom Speedport zum Netz zu sehen, in der Gegenrichtung (vom Netz zum Speedport) fließen keine RTP-Daten mehr. Es findet also keine Tonübertragung von der angerufenen Seite zum Speedport mehr statt.

Wenige Millisekunden später kommt dann in Paket 1158 ein Re-INVITE (vermutlich vom Router auf der Seite des Angerufenen), das versucht, die G.711-Telefonverbindung auf den speziellen Faxübertragungsstandard T.38 umzuschalten. In Paket 1163 gibt der Speedport an, daß er diese Anfrage prüft ("100 trying"); in Paket 1165 lehnt er den Umschaltversuch ab ("488 not acceptable here").

Danach bleibt die Übertragung "einseitig": Der Speedport W724V (Typ B) schickt weiterhin seine RTP-Audiodaten, es kommen aber keine RTP-Daten mehr aus dem Netz an. Im weiteren Verlauf sieht man dann noch, wie der Speedport alle paar Sekunden die 488er-Meldung wiederholt, bis schließlich die Verbindung vom Netz oder der Gegenstelle beendet wird (im Screenshot nicht mehr zu sehen).

2.) Verbindungsaufbau Speedport Smart:



Auch hier senden sich Speedport und Netz zunächst gegenseitig RTP-Audiopakete zu. Und auch hier verschwindet der eingehende RTP-Stream (vom Netz zum Speedport) plötzlich und es taucht das Re-INVITE auf, bei dem aus Richtung des Angerufenen (vermutlich von dessen Router) versucht wird, die G.711-Audioverbindung auf eine T.38-Faxverbindung umzuschalten.

Außerdem ist zu erkennen, wie das Re-INVITE vom Speedport zunächst überprüft ("100 trying") und dann ebenfalls abgelehnt wird ("488 not acceptable"). Allerdings eben mit zusätzlichen SDP-Daten im Message Body. In diesem Fall wird das 488-Paket dann auch aus Netzrichtung bestätigt (Paket 237), was bei der gescheiterten Verbindung (vgl. 1.)) nicht geschah.

Für einen kurzen Zeitraum (etwa eine Drittel Sekunde) ist die Verbindung auch hier einseitig (der Speedport sendet RTP-Daten, von der Gegenstelle kommen aber keine). Ab Paket 249 kommen aber plötzlich wieder eingehende RTP-Daten von der Gegenseite an. Im Folgenden wechseln sich eingehende und abgehende RTP-Datenpakete wieder ab. Das Fax am Speedport kann also das Fax am anderen Ende der Leitung (wieder) hören und die Übertragung eines Faxes ist erfolgreich möglich.

Eine weitere interessante Entdeckung: Die mir vorliegende Version von Wireshark interpretierte in beiden Fällen die RTP-Daten, die von den Speedports nach dem Zeitpunkt des T.38-Re-Invite-Versuches gesendet wurden als (fehlerhafte) T.38-Pakete! Das war zunächst eine ziemliche Überraschung ("Der Speedport lehnt T.38 ab und sendet danach trotzdem T.38-Pakete, die aber alle fehlerhaft sind?") - wenn man aber Wireshark manuell dazu zwingt, diese vermeintlichen T.38-Pakete als RTP-Pakete zu interpretieren, dann sieht man, daß ein normaler RTP-Stream entsteht (bei dem Paketnummer und Timestamp ganz normal hochgezählt werden).

Man darf also auch Wireshark nicht blind vertrauen, sondern muß sich immer überlegen, ob die vorliegenden Ergebnisse auch plausibel sind. Man muß aber auch sagen, daß es Wireshark da nicht ganz einfach hat, da RTP- und T.38-Pakete hauptsächlich aus dem Zusammenhang zu anderen Paketen erkannt werden können (wie z.B. eben der Signalisierung auf SIP-Ebene).

cu talk
Mit Zitat antworten
  #5  (Permalink
Alt 06.07.2020, 20:54
Benutzerbild von Meester Proper
Meester Proper Meester Proper ist offline
Senior Mitglied
 
Registriert seit: 21.05.2007
Beiträge: 6.322
Standard AW: Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Hallo zusammen,

ich kann das Thema auflösen:

Zitat:
Zitat von talk Beitrag anzeigen
Danach bleibt die Übertragung "einseitig": Der Speedport W724V (Typ B) schickt weiterhin seine RTP-Audiodaten, es kommen aber keine RTP-Daten mehr aus dem Netz an. Im weiteren Verlauf sieht man dann noch, wie der Speedport alle paar Sekunden die 488er-Meldung wiederholt, bis schließlich die Verbindung vom Netz oder der Gegenstelle beendet wird (im Screenshot nicht mehr zu sehen).
Der Speedport wiederholt das 488, weil er kein ACK auf das INVITE erhält. Das kommt dadurch, dass im SIP488 ein Syntax-Fehler enthalten ist, weshalb die erste Komponente im Telekom-Netz das SIP488 verwirft.

Der Syntax-Fehler ist der folgende:


Es heißt dort:
Zitat:
Warning: 305 SIP Phone "session description isn't understood"
Schauen wir uns nun einmal die ABNF des Warning-Headers an:

Warning = "Warning" HCOLON warning-value *(COMMA warning-value)
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = hostport / pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
pseudonym = token

Wie man erkennen kann, ist das Format immer "Warning: warncode SP warn-agent SP warn-text" (SP = Space, Leerzeichen).
Das Warning oben hat aber vier durch Leerzeichen getrennte Zeichenketten:
305 SIP Phone "session description isn't understood".

Es verletzt somit die ABNF. Richtig müsste es heißen:
Zitat:
Warning: 305 SIP-Phone "session description isn't understood"
Das merkwürdige ist: Dieses Problem war schon einmal für Arcadyan-Geräte behoben, bspw. für den W724v Typ B, ab Firmware 01011603.05.033. Scheint mir, als gäbe es hier eine Regression.

Es ist völlig irrelevant, ob im SIP488 ein SDP Body enthalten ist oder nicht, denn die Media-Session fällt auf den Status vor dem Re-INVITE zurück. Wie oben richtig zitiert.
__________________
Zitat:
Consumers have only limited interest in NGA at present – incremental willingness to pay (WTP) for ultra-fast broadband is at most only about € 5 per month, which is nowhere near enough to fund the initial investment needed in most parts of the national territory.
Mit Zitat antworten
  #6  (Permalink
Alt 06.07.2020, 21:46
eifelman eifelman ist offline
Senior Mitglied
 
Registriert seit: 26.12.2005
Ort: bei Bitburg / Trier
Alter: 36
Beiträge: 7.049
Provider: Telekom
Bandbreite: SVDSL 175
Standard AW: Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Smart 3 nicht betroffen?
__________________
MagentaZuhause XL - MagentaTV Smart
Mit Zitat antworten
  #7  (Permalink
Alt 06.07.2020, 23:19
Benutzerbild von Meester Proper
Meester Proper Meester Proper ist offline
Senior Mitglied
 
Registriert seit: 21.05.2007
Beiträge: 6.322
Standard AW: Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Das Problem wurde initial Ende 2017 behoben. Daher gehe ich nicht davon aus.
__________________
Zitat:
Consumers have only limited interest in NGA at present – incremental willingness to pay (WTP) for ultra-fast broadband is at most only about € 5 per month, which is nowhere near enough to fund the initial investment needed in most parts of the national territory.
Mit Zitat antworten
  #8  (Permalink
Alt 07.07.2020, 12:05
Benutzerbild von Meester Proper
Meester Proper Meester Proper ist offline
Senior Mitglied
 
Registriert seit: 21.05.2007
Beiträge: 6.322
Standard AW: Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Ich habe noch einmal nachgeforscht. Ich habe Beispiele gefunden vom W 724V Typ B mit den Firmwares 01011603.07.001 und 01011603.07.003, bei beiden Geräten trat der Fehler nicht auf.

Vielleicht war in diesem Beispiel gar nicht die Firmware schuld, sondern der Fakt, dass das Gerät ursprünglich mit einer Firmware in Betrieb ging, wo der Fehler bestand und somit noch in alten Konfigurationsdateien oder Caches hing?! Hätte hier vielleicht schon ein Werksreset das Problem behoben?!

Da nun das Gerät ausgetauscht wurde, lässt sich das vermutlich nicht mehr nachvollziehen.
__________________
Zitat:
Consumers have only limited interest in NGA at present – incremental willingness to pay (WTP) for ultra-fast broadband is at most only about € 5 per month, which is nowhere near enough to fund the initial investment needed in most parts of the national territory.
Mit Zitat antworten
  #9  (Permalink
Alt 07.07.2020, 14:54
talk talk ist offline
Senior Mitglied
 
Registriert seit: 28.12.1999
Beiträge: 541
Standard AW: Fax am Telekom IP-Anschluß und G.711-Fallback nach abgelehntem T.38-Re-Invite

Hallo zusammen,

Zitat:
Zitat von Meester Proper Beitrag anzeigen
ich kann das Thema auflösen:

Der Speedport wiederholt das 488, weil er kein ACK auf das INVITE erhält. Das kommt dadurch, dass im SIP488 ein Syntax-Fehler enthalten ist, weshalb die erste Komponente im Telekom-Netz das SIP488 verwirft.
vielen Dank für Deine Antwort und Deine Erläuterungen!

Damit verzieht sich der Nebel und man muß nicht mehr mit der Stange in selbigem herumstochern...

Einen Zusammenhang mit den SDP-Daten hätte ich noch in gewisser Weise nachvollziehen können (z.B. daß das Netz da nochmal auf Nummer sicher gehen will und deshalb die Codecs erneut explizit genannt bekommen möchte). Daß das Problem nun in der Syntax des Warning-Headers liegt, überrascht mich.

Zwecks besserer Übersicht trenne ich die Thematik mal in zwei Teile: Zum einen das Unterbrechen des RTP-Streams und zum anderen die erfolgte bzw. nicht erfolgte Bestätigung ("ACK") der 488-Meldung.

1.) Unterbrechen des RTP-Streams

Wie bereits angesprochen soll eine VoIP-Verbindung bis zu einem erfolgreich ausgehandelten Re-Invite mit den ursprünglichen Parametern weiterlaufen (RFC 3261, Pkt. 4).

Ich interpretiere das so, daß im vorliegenden Fall die RTP-Streams einfach ohne jegliche Unterbrechnung durchlaufen müßten - bis zu dem Moment, in dem der jeweils sendende Endpunkt nach einem erfolgreichen Re-Invite auf die neuen Parameter umschalten würde (und ein solches Umschalten erfolgt ja in beiden Fällen nicht, da T.38 jeweils abgelehnt wird). Bei den Speedports ist das auch der Fall: Beide Modelle senden ihre ausgehenden RTP-Streams durchgehend weiter. Auch in der Zeit zwischen Re-Invite und Ablehnung desselbigen weisen die ausgehenden RTP-Streams keine Lücke auf.

Das Netz unterbricht aber quasi zeitgleich zum Re-Invite den (aus Sicht des Anrufers) eingehenden RTP-Stream und stellt ihn erst wieder nach der gewünschten Reaktion des Routers durch. Eben dieses Verhalten kann ich anhand der bislang vorliegenden Infos nicht nachvollziehen.

Hierfür werden offenbar sogar aktiv RTP-Pakete verworfen, denn der eingehende RTP-Stream hat beim erfolgreichen Fallback einen Verlust von 15 Paketen. Das läßt vermuten, daß die angerufene Seite (von welcher der T.38-Re-Invite wohl ausgeht) die Regeln ähnlich wie ich interpretiert und trotz Re-Invite-Versuch seinen G.711-RTP-Stream lückenlos aufrecht erhält, der dann aber teilweise vom Netz unterdrückt wird. Der RTP-Stream würde demnach nicht transparent durchgereicht werden.

Gäbe es diese Unterbrechnung des eingehenden RTP-Streams nicht, könnte das Faxgerät des Anrufers das andere Faxgerät weiterhin hören und erfolgreich eine Faxübertragung vornehmen. Hierfür wäre es dann im Grunde sogar zweitrangig, ob parallel dazu auf SIP-Ebene die 488-Meldung wiederholt wird oder nicht und ob sie bestätigt ("ACK") wird oder nicht. Die Verbindung würde einfach (erfolgreich!) durchlaufen.

2.) (Nicht-)Bestätigung der 488-Meldung

Parallel dazu stellt sich die Frage, ob es zulässig bzw. sinnvoll ist, eine 488-Meldung aufgrund eines Fehlers im Aufbau zu ignorieren.

Daß ein Parser ein bestimmtes Datenformat möchte, ist ja in gewisser Weise nachvollziehbar - und den Effekt "kleine Ursache, große Wirkung" kennt jeder, der z.B. bei einem PHP-Skript mal eine Klammer o.ä. vergessen hat. Allerdings kann sich fragen, wie streng man da sein will.

Der Warning-Header ist nicht mal verpflichtend, so heißt es z.B. in Pkt. 13.3.1.3:

Zitat:
A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected.
"Soll" ist ja etwas anderes als "muß" - und der Speedport Smart, dessen 488-Meldung akzeptiert wird, sendet auch gar keinen Warning-Header (statt dessen einen Reason-Header). Da ist es schon kurios, wenn ein fehlender Warning-Header akzeptiert wird, ein fehlerhafter jedoch gleich zum Scheitern der ganzen Verbindung führt.

Ich hätte ehrlich gesagt gar nicht erwartet, daß dem Warning-Header überhaupt eine große Bedeutung zugemessen wird. Spontan würde mir da noch am ehesten einfallen, daß man diesen Header evtl. a) zur Fehlerdiagnose auswertet oder b) aus Sicherheitsgründen auf einer korrekten Syntax besteht. Aber da stellt sich dann auch noch die Frage nach a) der Aussagekraft bzw. b) dem konkreten Risiko.

RFC 3261 schreibt z.B. in Pkt. 8.2.2.

Zitat:
If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. A UAS SHOULD ignore any malformed header fields that are not necessary for processing requests.
Die Server-Seite eines SIP-Requests (jeweils auf den Kontext bezogen) soll also unbekannte oder fehlerhafte Header-Felder ignorieren (in letzterem Fall zumindest solange diese fehlerhaften Felder nicht für die Bearbeitung erforderlich sind). Und auch wenn hier nur vom UAS die Rede ist, würde ich doch mal annehmen, daß man dies vom Grundgedanken auch auf den UAC anwenden kann.

Dann hätte aber auch die 488-Meldung des Speedport W724V (Typ B) mit einem ACK akzeptiert werden müssen. Die Grundaussage ("Der Re-Invite für T.38 wird nicht akzeptiert, denn dieser Standard wird hier nicht unterstützt") ist ja eindeutig.

Mein persönliches Fazit: Anhand der vorliegenden Daten hätte ich erwartet, daß das Netz die RTP-Daten, die von der angerufenen Seite kommen, einfach weiter durchleitet - ungeachtet dessen, ob ein Re-Invite kommt - und idealerweise auch die 488-Meldung des W724V (Typ B) akzeptiert.

Auch vor dem Hintergrund der vielfältigen Endgerätelandschaft und den im Markt sowieso nicht immer hundertprozentig einheitlichen Implementierung des SIP-Standards würde ich da auf eine gewisse "Toleranz" setzen, solange eindeutig klar ist, was gemeint ist. Für einen Carrier, der auch im nationalen und internationalen Wholesale-Geschäft eine wichige Rolle spielt, sowieso.

Fälle wie die oben angesprochene Thread mit den Faxverbindungen 1&1 <> Telekom <> VSE-Net dürften dann wohl auch mit irgendeiner kleinen Inkonsistenz in der SIP-Kommunikation zusammenhängen, sind aber in solchen Konstellationen (wo mehrere Beteiligte und auch Carrier zusammenkommen) praktisch gar nicht mehr wirklich entstörbar (wie der dortige Fall auch gezeigt hat).

cu talk
Mit Zitat antworten
 
Anzeige
Antwort


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Rechtliche Frage - VDSL25 Fallback bei Telekom rechtlich in Ordnung? sikabayup Telekom 10 21.09.2017 19:46
1&1 -> Telekom: Knacken, Kratzen, Knistern. G.711-HD hle VoIP-Anbieter und VoIP-Technik 1 14.06.2017 12:17
Fallback nach umstellung auf VDSL2? ForTN0X Telekom 6 25.11.2016 21:36
REGISTER - INVITE - 403 - Forbidden Bronkoo Telekom 2 03.09.2015 17:06
Modem-Fehlermeldung RAS Fehler 711 / "nicht installiert" Hamburgmonster Hardware 2 28.11.2003 15:48


Alle Zeitangaben in WEZ +2. Es ist jetzt 09:57 Uhr.


Basiert auf vBulletin®
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.