Möglicherweise kann dir der weiterhelfen, wo dir das Gerät verkauft hat.

Andernfalls, wenn du Online gekauft hast, bist du möglicherweise noch in der Rückgabefrist. Das würde ich in deinem Fall in Anspruch nehmen und ein anderes Gerät beim PC-Spezi um die Ecke kaufen, mit Installation bzw. Inbetriebnahme.

Hallo zusammen,

---

@gagg2408  schrieb:

In der Firma wissen sie von dem Problem, und haben es auch schon weitergeleitet( telekom).
Das Problem, das faxe nicht gesendet/ empfangen werden können, ist laut Chefin erst aufgetreten, als die Umstellung von analogem Anschluss auf einen IP Anschluss war.

Ich kann an dieser Stelle nur nochmal mein Angebot erneuern, mir einen von Dir erstellten Paketmitschnitt einer solchen gescheiterten Faxverbindung einmal näher anzuschauen (die Anleitung hierfür hatte ich bereits hier in der Diskussion gepostet, falls noch Fragen dazu sind, einfach melden).

Es läßt sich nicht garantieren, daß sich der Fehler hiermit finden läßt, aber man könnte ihn vielleicht immerhin etwas genauer eingrenzen.

cu talk

Hallo zusammen,

@gagg2408: Vielen Dank für das Erstellen und Bereitstellen des Mitschnitts! Ich habe ihn inzwischen analysiert und interessante Auffälligkeiten gefunden.

Schauen wir uns mal gemeinsam eine "Call Flow"-Analyse an, die ich mit Wireshark erstellt habe:

Diese Grafik zeigt im Wesentlichen folgende Details (die Zeitangaben links sind Sekunden seit dem Start des Paketmitschnitts):

- bei 116.831765 übermittelt der Speedport seinen Anrufwunsch ans Netz

- bei 117.041193 bekommt er vom Netz die Bestätigung, daß dieses versucht, die Verbindung aufzubauen ("trying")

- bei 117.302895 "klingelt" es beim Angerufenen ("ringing")

- bei 124.117035 startet der eingehende RTP-Datenstrom (also quasi der "ankommende Tonkanal") und bei 124.130279 wird das Zustandekommen des Anrufes vom Netz gemeldet. Dies wird vom Speedport wiederum bei 124.198113 bestätigt, der kurz daraufhin bei 124.222686 auch den ausgehenden RTP-Datenstrom (der "abgehende Tonkanal") aufbaut.

Zu diesem Zeitpunkt ist also die Verbindung zum Zielteilnehmer erfolgreich zustandegekommen. Im RTP-Stream ist auch zu hören, daß das Zielfax seinen charakteristischen Faxton aussendet.

Dies führt dann allerdings dazu, daß irgendwo auf der Verbindungsstrecke (evtl. vom Netz, von einem Carrier-Gateway oder vom Router auf der Gegenseite?) versucht wird, die Verbindung vom normalen Sprachübertragungsstandard G.711 auf den speziellen Faxübertragungsstandard T.38 umzuschalten. Dies geschieht bei 126.933758 mit einem erneuten INVITE (auch als Re-INVITE bezeichnet).

Der Speedport lehnt bei 126.975478 diese angefragte Umschaltung auf T.38 ab und wiederholt diese Ablehnung in den folgenden 32 Sekunden mehrfach, bis schließlich bei 158.923729 die Verbindung vom Netz oder der Gegenseite beendet wird, was schließlich vom Speedport bei 158.928930 bestätigt wird.

Zwischenfazit: Die Verbindung kommt zunächst korrekt mit dem Sprachstandard G.711 zustande (hierüber können in der Regel auch Faxe übertragen werden, das ist also kein Fehler). Es ist auch in Ordnung, daß eine an der Verbindung beteiligte Komponente versucht, die Verbindung auf T.38 umzuschalten. Und ist es auch völlig korrekt, daß der Speedport die T.38 -Umschaltung verweigert (der Speedport W724 V Typ B soll ja wohl gar kein T.38 können).

Jetzt kommt der entscheidende Punkt: Es ist nicht in Ordnung, daß der eingehende RTP-Stream praktisch zeitgleich zu diesem Re-INVITE abbricht! Der "Call Flow" zeigt bereits, daß der eingehende RTP-Stream (siehe bei 124.117035) nur 135 Pakete lang ist, also 2,68  Sekunden lang dauert. Danach ist die Verbindung "stumm" / die Leitung "tot" und bleibt noch etwa 32 Sekunden ohne Tonübertragung offen. Im Paketmitschnitt selbst sind in diesem Zeitraum keine ankommenden Pakete (egal ob RTP, T.38 o.ä.) zu sehen, bis dann schließlich mit einem "BYE" die Verbindung beendet wird.

Was den abgehenden RTP-Stream angeht, interpretiert die mir vorliegende Wireshark-Version die vom Speedport ausgehenden Daten nach dem T.38 -Reinvite offenbar als T.38 -Pakete. Deshalb im obigen "Call Flow" auch die Angabe von angeblich nur 136 ausgehenden RTP-Paketen. Meiner Ansicht nach ist dies aber eine Fehlinterpretation. Alle vermeintlichen T.38 -Pakete werden als "malformed" bezeichnet. Außerdem ist bei den RTCP-Paketen erkennbar, daß die Anzahl der verschickten RTP-Pakete auch nach dem abgelehnten Re-Invite immer weiter hochgezählt wird. Demnach wird der ausgehende RTP-Stream wohl aufrecht erhalten. Zumal wäre es auch ungewöhnlich, wenn der Speedport T.38 ablehnen und dann dennoch auf T.38 umschalten würde. Man darf also auch Wireshark nicht alles blind glauben...!

Fazit: Das Hauptproblem sehe ich hier im Abbrechen des eingehenden RTP-Datenstroms (also dem Signal, das von der Gegenseite kommt). Das halte ich für einen Fehler, denn beide RTP-Streams dürften erst nach einer erfolgreichen Umschaltung zu T.38 beendet werden, vgl. auch Punkt 4.2.4.3 (Fax and Modem) der Telekom-eigenen Richtlinie 1TR114.

Es stellen sich daher verschiedene Fragen, die man mal näher untersuchen sollte. Eventuell kann da die Netztechnik der Telekom helfen?

1.) "Wer" versucht, die Verbindung auf T.38 umzuschalten? Die Telekom VoIP-Plattform soll sich angeblich bei T.38 transparent verhalten, also diesen Standard nur durchleiten, wenn eine Endseite dies wünscht. Geht die Umschaltung also evtl. vom Router o.ä. auf der Zielseite aus? Ist die Zielrufnummer wirklich bei der Telekom geschaltet, oder evtl. bei einem anderen Anbieter? Kann ggf. von einem Gateway zwischen der Telekom und einem anderen Anbieter die Umschaltung ausgehen? Ist das Phänomen evtl. davon abhängig, über welche SIP-/RTP-Server die Verbindung verläuft?

2.) Wieso bricht der eingehende RTP-Stream ab? Dieser Stream dürfte ja erst bei einer erfolgreichen Umschaltung auf T.38 beendet werden. Verhält sich die Telekom-Plattform da tatsächlich transparent oder kann es sein, daß das Telekom-Netz durch ein transparent durchgeleitetes T.38 -Re-INVITE auf SIP-Ebene daraufhin den RTP-Stream selbst beendet? Hier sollte auf den Telekom-Servern überprüft werden, ob der eingehende RTP-Stream bereits dort fehlt.

3.) Es gab schon mal eine Diskussion über gescheiterte Faxverbindungen, bei denen ein Umschaltversuch auf T.38 scheitert und zeitgleich der eingehende RTP-Stream abbricht, siehe dazu dieses Thema bei onlinekosten.de. Damals ging es um eine Verbindung von 1&1/Versatel zu einer 0800-Rufnummer bei VSE-Net, die über die Telekom als Transit-Carrier lief. Aufgrund der damals vielen beteiligten Seiten konnte das Problem damals nicht gelöst werden. Falls bei einem Telekom-VoIP-Server ein Fehler vorliegen sollte, könnte es sich evtl. in beiden Fällen um ein vergleichbares Problem ( T.38 -Re-INVITE verursacht fälschlicherweise einen RTP-Abbruch) handeln?

Zusammenfassung:

Angesichts der vorliegenden Daten bitte ich das @Telekom-hilft-Team  um das Eröffnen eines Störungstickets. Bei den gestörten Faxverbindungen wird irgendwo im Netz oder auf der angerufenen Seite im Rahmen eines T.38 -Re-Invites der RTP-Datenstrom zum anrufenenden Nutzer hin abgebrochen, obwohl der Re-Invite vom anrufenden Speedport abgelehnt wird. Die Frage ist, wo dies erfolgt.

@gagg2408  kann den Paketmitschnitt einer gestörten Faxverbindung bereitstellen. Es kann jedoch sein, daß ein Analysetool wie Wireshark diesen Mitschnitt als "damaged or corrupt" bezeichnet und nur einen Teil der mitgeschnittenen Daten darstellt (wo dann ausgerechnet die SIP-/RTP-Daten fehlen). In diesem Fall muß der Mitschnitt mit einem Tool wie pcapfix repariert werden. Auf Wunsch kann ich eine reparierte und auf die wesentlichen Daten gekürzte Version des genannten Mitschnitt selbst bereitstellen. Ebenfalls wäre zu beachten, daß Wireshark evtl. die vom Speedport nach dem abgelehnten Re-Invite ausgehenden Daten fälschlicherweise als T.38 -

Daten interpretiert (meines Erachtens wird hier aber einfach der ausgehende RTP-Stream fortgesetzt, vgl. die Zähler in den RTCP Sender Reports).

Es kann gerne auf diesen Thread und meine Analyse verwiesen werden. Informationen über den weiteren Verlauf dieses Falls bitte auch hier ins Forum oder per PN an mich.

cu talk

@talk 

Vielen Dank.

Wenn es dich interessiert kann ich gerne nochmal versuchen, einen Mitschnitt zu machen.

Vielleicht schaffe ich es ja  Montag oder Dienstag.

Und ja, mich hat es auch gewundert, dass es nur durch den Tausch des Routers funktioniert hat.

Wir haben es jetzt schon mehrmals versucht, an die Firmennummer zu faxen und es hat immer funktionert. Schon komisch.

@talkDanke nochmal, und ich melde mich dann bei dir, sobald ich den Mitschnitt habe.

Grüße

gagg2408

Hallo zusammen,

gagg2408

 

Wenn es dich interessiert kann ich gerne nochmal versuchen, einen Mitschnitt zu machen.

Vielleicht schaffe ich es ja Montag oder Dienstag.

Gerne! Einfach melden, wenn sich was ergibt.

Und ja, mich hat es auch gewundert, dass es nur durch den Tausch des Routers funktioniert hat.

Wir haben es jetzt schon mehrmals versucht, an die Firmennummer zu faxen und es hat immer funktionert. Schon komisch.

Ich hätte ein paar Vermutungen (die unter anderem mit dem speziellen Fax-Standard T.38 zu tun haben), aber genaueres läßt sich nur mit einem Mitschnitt sagen.

cu talk

Hallo zusammen,

@gagg2408: Vielen Dank für die Mitschnitte von funktionierenden Faxverbindungen mit dem Speedport Smart!

Damit konnte ich mir in den letzten Tagen mal etwas näher anschauen, inwiefern sich der Speedport W724V (Typ B) und der Speedport Smart beim Faxen unterschiedlich verhalten - und ich konnte vermutlich auch die Ursache näher eingrenzen, warum das Faxen im einen Fall funktioniert, im anderen Fall aber nicht.

Zur genaueren Erläuterung nutze ich im Folgenden Screenshots von Analysen mit dem Tool Wireshark. Persönliche Daten sind unkenntlich gemacht. Zum Verständnis noch ein paar kurze Erläuterungen zu den ersten beiden Screenshots, die jeweils einen Ausschnitt von Paketmitschnitten zeigen:

- Bei "No." ganz links steht die Nummer des Pakets, also um das wievielte Paket des Mitschnitts es sich handelt. "Lücken" in der Nummerierung entstehen dadurch, daß ich hier auf SIP- und RTP-Pakete gefiltert habe und somit Pakete anderer Protokolle aus der Analyse herausfallen.

- "Time" gibt jeweils an, wieviel Zeit in Sekunden seit dem Start des Mitschnitts vergangen ist.

- "Source" gibt die IP-Adresse an, die der Absender des Paketes ist und "Destination" gibt die IP-Adresse an, die das Ziel des Paketes ist

(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.) Schauen wir uns erstmal einen Screenshot aus dem Mitschnitt einer gescheiterten Faxverbindung mit dem Speedport W724V (Typ B) an:

Wir sehen zunächst, wie sich der Speedport und der RTP-Server der Telekom abwechselnd RTP-Daten zusenden, die das zu übertragende Fax-Signal in "Portionen" von jeweils 20 ms Dauer enthalten. Paket 1142 ist also ein RTP-Paket vom Speedport ins Netz, Paket 1143 ist ein RTP-Paket vom Netz zum Speedport, und so weiter... Zunächst verlaufen diese Datenströme schön abwechselnd - beide Seiten schicken also ihre RTP-Daten korrekt zur jeweiligen Gegenstelle. In der letzten Spalte können wir sehen, daß es sich hier um Audiopakete mit dem Übertragungsstandard G.711 handelt (der auch im klassischen ISDN-Netz zum Einsatz kommt).

Ab Paket 1150 sind 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. Das bedeutet, daß das am Speedport angeschlossene Faxgerät das am anderen Ende der Verbindung befindliche Faxgerät nicht mehr "hören" kann.

Wenige Millisekunden später kommt dann ein Re-INVITE (vermutlich vom Router auf der Seite des Angerufenen), das versucht, die G.711-Telefonverbindung auf den speziellen Faxübertragungsstandard T.38 " href="https://telekomhilft.telekom.de/t5/Glossar/T-38/ta-p/4563098#glossar" target="_blank"> 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 weiterhin "einseitig": Der Speedport W724V (Typ B) schickt wie gewohnt seine RTP-Audiodaten, es kommen aber weiterhin keine RTP-Daten mehr aus dem Netz an. Im Gesamtmitschnitt sieht man dann noch, wie der Speedport daraufhin alle paar Sekunden die 488er-Meldung wiederholt, bis schließlich die Verbindung vom Netz oder der Gegenstelle beendet wird.

Zusatzhinweis: Meine Wireshark-Version interpretiert "serienmäßig" die Pakete, die der Speedport ab dem eingehenden Re-INVITE verschickt, als fehlerhafte T.38 -Datenpakete. Dies ist aber meines Erachtens falsch. Zwingt man Wireshark, diese vermeintlichen T.38 -Pakete als normale RTP-Daten zu interpretieren, dann entsteht eine korrekte Fortsetzung des (abgehenden) RTP-Streams, bei dem auch die streaminterne Paketnummer und der Zeitstempel korrekt hochgezählt werden (erkennbar an den Angaben für "Seq" und "Time" in der letzten Spalte). Dieses Phänomen tritt auch bei den Mitschnitten anderer Router auf (auch bei erfolgreichen Faxverbindungen via G.711-Fallback!) und ist wohl der Tatsache geschuldet, daß Wireshark zur Erkennung von RTP- und T.38 -Paketen auf den Kontext / Zusammenhang angewiesen ist, in dem die Übertragung erfolgt, da diese Protokolle von Haus aus keine eindeutige Identifikation mitbringen. Auch beim nachfolgend unter 2.) analysierten Mitschnitt mußte ich zu diesem Mittel greifen.

2.) Schauen wir uns nun einen Screenshot aus dem Mitschnitt einer funktionierenden Faxverbindung mit dem Speedport Smart an:

Auch hier sehen wir zunächst, daß Speedport und Netz sich gegenseitig RTP-Audiopakete senden. 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.

Ebenfalls ist zu erkennen, wie das Re-INVITE vom Speedport zunächst überprüft ("100 trying") und dann abgelehnt wird ("488 not acceptable"), soweit also alles wie im ersten Fall.

Wir sehen ebenfalls, daß danach die Verbindung erstmal einseitig bleibt (nur der Speedport sendet 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. Insgesamt entsteht ein (fast) durchgehender eingehender RTP-Datenstrom, der lediglich rund um den Zeitpunkt des Re-INVITEs für etwa eine Drittel Sekunde unterbrochen wird. Nach dieser Unterbrechung wird er aber fortgesetzt. Das Fax am Speedport kann sich mit dem Fax am anderen Ende der Leitung erfolgreich verständigen und die Übertragung eines Faxes ist möglich.

Die Frage ist nun: Was ist der Grund für dieses unterschiedliche Verhalten? Dafür schauen wir uns nun in einem weiteren Schritt die SIP-Pakete an, mit denen das Re-INVITE jeweils abgelehnt wird.

3.) Bei der gescheiterten Faxverbindung mit dem Speedport W724V (Typ B) sieht die Ablehnung des Re-INVITEs wie folgt aus:

Der Speedport W724V (Typ B) lehnt das vorgeschlagene Re-INVITE mit dem Statuscode 488 (not acceptable here) ab und ergänzt diese Ablehnung noch bei "Warning" mit dem Hinweis "Session description isn´t understood": Der Speedport kennt das gewünschte T.38 -Verfahren also nicht (kein Wunder, da T.38 " href="https://telekomhilft.telekom.de/t5/Glossar/T-38/ta-p/4563098#glossar" target="_blank"> T.38 von den Speedports laut offiziellen Angaben nicht unterstützt wird).

4.) Bei der erfolgreichen Faxverbindung mit dem Speedport Smart sieht dagegen die Ablehnung wie folgt aus:

Auch hier wird das Re-INVITE mit dem Statuscode 488 (not acceptable here) abgelehnt. Der Aufbau des "Message Headers" ist hier etwas anders ("Reason" statt "Warning"), das scheint mir aber nicht entscheidend zu sein.

Der deutliche Unterschied zum W724V (Typ B): Der Speedport Smart schickt bei seiner Ablehnung (488) auch noch sogenannte SDP-Daten mit (siehe hierfür den "Message Body"). Hiermit teilt er - vereinfacht gesagt - dem Netz / der Gegenstelle nochmal explizit mit, welche Übertragungsverfahren er unterstützt. Darunter an erster Stelle (mit RTP-Map-Wert "8") der PCMA-Codec, der auch als G.711 bezeichnet wird. Er sagt also Netz / Gegenstelle nochmal ausdrücklich, daß er den G.711-Codec beherrscht und diesen mit höchster Priorität (er wird als erstes genannt) anbietet. Dieses "Angebot" wird in Paket 237 von Netz oder Gegenstelle mit "OK" akzeptiert und bestätigt. Eine solche Bestätigung des 488-Paketes gibt es im ersten Fall (gescheiterte Faxverbindung) nicht!

Zwischenfazit: Nach Erkennen eines Faxtones wird in beiden Fällen seitens des Routers des Angerufenen oder durch irgendein anderes Netzelement versucht, mit einem Re-INVITE von G.711 auf T.38 " href="https://telekomhilft.telekom.de/t5/Glossar/T-38/ta-p/4563098#glossar" target="_blank"> T.38 umzuschalten, desweiteren wird praktisch zeitgleich irgendwo in der Routingkette bereits "versorglich" der RTP-Stream vom Netz zum Nutzer unterbrochen.

Bei der Ablehnung des Re-INVITES wird der eingehende RTP-Stream nur dann wieder durchgelassen, wenn der Speedport über SDP-Daten nochmal explizit die bei ihm verfügbaren Codecs (z.B. G.711) mitteilt. Wenn der Speedport das Re-INVITE nur ablehnt, ohne nochmals die von ihm unterstützten Codecs vorzustellen, bleibt der RTP-Stream offenbar dauerhaft unterbrochen, bis die ganze Verbindung irgendwann beendet wird.

5.) Welches Verhalten ist das korrekte? Wo liegt der Fehler?

Wie ich in früheren Postings bereits erläutert habe, ist es normal, daß die Faxverbindung als normale G.711-Telefonverbindung beginnt. Es ist auch in Ordnung, daß irgendwo in der Routingkette versucht wird, nach dem Erkennen eines Fax-Signales die Verbindung von G.711 auf T.38 " href="https://telekomhilft.telekom.de/t5/Glossar/T-38/ta-p/4563098#glossar" target="_blank"> T.38 umzuschalten - und es ist auch in Ordnung, daß dieser Umschaltwunsch abgelehnt wird. Das ist alles korrekt - dann müßte die Verbindung aber einfach als G.711-Anruf weiterlaufen.

Wir sehen, daß die beiden Speedport-Router bei der Ablehnung des Re-INVITEs einen unterschiedlichen Aufbau ihrer 488-Statusmeldung verwenden: Einmal ohne und einmal mit SDP-Daten. Da stellt sich natürlich die Frage, welches Verhalten denn nun eigentlich korrekt ist. Hierfür schauen wir nun in die Internet-Norm RFC 3261, in der der Aufbau des SIP-Protokolls offiziell definiert wird.

Dort heißt es in Punkt 4 unter anderem:

During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re-INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. 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.

Den entscheidenden Teil am Ende dieses Zitats habe ich hervorgehoben. Dort steht also, daß die 488-Meldung bestätigt werden soll und die Ablehnung des Re-INVITES nicht zu einem Verbindungsabbruch führen soll. Statt dessen soll die Verbindung mit den zuvor vereinbarten Eigenschaften weiterlaufen.

In Punkt 21.4.26 des Standards heißt es außerdem:

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.

Auch hier habe ich den entscheidenden Teil hervorgehoben: Eine 488-Meldung kann einen "Message Body" mit einer Beschreibung der unterstützten Übertragungsverfahren enthalten - das Wort "MAY" (engl. für "kann" / "darf") sagt aber: Man kann bzw. darf dies so machen, man muß es aber nicht!

Weiteres Zwischenfazit: Beide Speedport-Router verhalten sich meiner Meinung nach standardkonform.

Meiner Ansicht entspricht es aber nicht dem RFC 3261-Standard, wenn das Netz (oder wer auch immer) nach Ablehnung des Re-INVITES den RTP-Stream nur dann wieder durchschaltet, wenn die 488-Meldung auch SDP-Daten enthält.

Einerseits weil diese SDP-Daten laut Pkt. 21.4.26 bei einer 488-Meldung nur optional sind, anderseits auch weil die Verbindung ja (vgl. Pkt. 4 des Standards) nach dem Scheitern des Re-INVITEs ausdrücklich mit den bestehenden Eigenschaften fortgesetzt werden soll (dazu gehört auch der zu Verbindungsbeginn ursprünglich vereinbarte Codec) - eine erneute Mitteilung der verfügbaren Codecs ist da im Grunde auch einfach überflüssig.

Meines Erachtens nach sollte bereits das Unterbrechen des eingehenden RTP-Streams nicht passieren, solange kein Re-INVITE erfolgreich bestätigt wird.

6.) Liegt das Problem an der Gegenstelle oder im Netz?

Ich würde vermuten, daß der Umschaltversuch zu T.38 " href="https://telekomhilft.telekom.de/t5/Glossar/T-38/ta-p/4563098#glossar" target="_blank"> T.38 vom Router des Angerufenen ausgeht. Das Telekom-Netz selbst soll ja angeblich nicht als T.38 -Gateway auftreten. Sollte das Ziel bei einem anderen Carrier geschaltet sein, wäre es theoretisch auch möglich, daß das Re-INVITE in der dortigen VoIP-Netztechnik seinen Ursprung hat.

Das zeitweilige bzw. dauerhafte Unterdrücken des RTP-Streams und das Warten auf SDP-Daten in der 488-Meldung könnte theoretisch auch vom Router des Angerufenen ausgehen. Das glaube ich aber nicht, denn der zweite Screenshot zeigt bei der Nummerierung der RTP-Pakete, daß nach der kurzen "Pause" der eingehende RTP-Stream nicht mit Paket 398 (das letzte eingehende RTP-Paket vor der Unterbrechung hatte die Seq-Nummer 397, s. ganz hinten in der letzten Spalte), sondern mit Paket 413 weitergeht. Die Pakete 398 bis 412 werden also wohl bei der Gegenstelle losgeschickt, aber vermutlich irgendwo unterwegs "im Netz" einfach verworfen.

Würde das Problem im Router des Angerufenen bestehen, wäre der RTP-Stream meines Erachtens einfach bei Paket 398 weitergegangen oder es wäre ein komplett neuer RTP-Stream (mit abweichendem SSRC-Wert) begonnen worden.

Daher tippe ich darauf, daß die Ursache eher "im Netz" liegt. Ein Server dort scheint das Re-INVITE als Aufforderung zu verstehen, den RTP-Stream zu unterbrechen, um dann (mit leichter Verzögerung) das Re-INVITE weiter an den Anrufer durchzureichen und auf eine Bestätigung oder aber eine Ablehnung inkl. SDP-Daten zu warten.

7.) Fazit: Bitte das Thema weiter untersuchen!

Die Untersuchung hat gezeigt, daß 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 im hier diskutierten Thema bei onlinekosten.de ist (dort ging es um Probleme von 1&1-Nutzern bei Fax-Verbindungen zu 0800-Rufnummern bei VSE-Net, die offenbar im Transit über das Telekom-Netz vermittelt werden).

Das Tauschen des Routers bei @gagg2408 ist letztlich keine Lösung des Problemes an sich, sondern mehr eine Auseinandersetzung mit den Symptomen des Problems. Man wird wohl kaum bei jedem betroffenen Nutzer den Router austauschen wollen - zumal dies auch im vorliegenden Fall erst nach einer wochenlangen Odyssee erfolgte, die die allermeisten Nutzer wohl nicht mitmachen würden bzw. könnten. Zumal ist das Verhalten des Speedport W724V (Typ B) m.E. standardkonform und kein Fehler - und selbst wenn es einer wäre, müßte man notfalls zumindest auf der hauseigenen VoIP-Plattform dieses Verhalten tolerieren, solange man es nicht anders lösen könnte.

Außerdem ist die Telekom ja auch als Transit-Carrier für in- und ausländische Netzbetreiber tätig. Das sollte ein Grund mehr sein, solchen Problemen detailliert auf den Grund zu gehen, weil sonst evtl. auch Kunden anderer Netzbetreiber in Mitleidenschaft gezogen werden.

Da Probleme bei Faxverbindungen über VoIP ohnehin ein Thema für sich sind und oftmals nur mit Standardlösungen wie "Geschwindigkeit heruntersetzen", "Fehlerkorrektor ein-/ausschalten" oder "Mail2Fax-Dienst nutzen" abgefertigt werden, sollte die Chance jetzt genutzt werden, das bestehende Problem in alle Details auszuleuchten, da ja nun auch eine umfangreiche Analyse dieses Falls vorliegt.

@Stefan D.: Ich hoffe, das war jetzt nicht zu viel Text auf einmal. Kannst Du mit den vorliegenden Erkenntnissen bitte nochmal bei der Technik nachhaken? Wie gesagt, @gagg2408 kann mit dem neuen Router jetzt wohl problemlos faxen, das ist aber keine Lösung des eigentlichen Problems. Ich fände es daher sehr schade, wenn die ganze Thematik nun einfach als erledigt betracht werden würde - zumal es hier ja auch um die korrekte Interpretation von offiziellen Branchenstandards wie RFC 3261 (SIP) geht.

Im Grunde handelt es sich hier um kein Problem speziell von @gagg2408, sondern um ein Szenario, daß man auch bei der Telekom nachstellen können müßte. Die Telekom hat sich doch für ihr tolles Labor zur IP-Umstellung gerühmt, wo Hersteller ihre Produkte in allen denkbaren Situationen testen können. In diesem Fall müßte die Telekom halt nun selbst einen solchen Fall nachbauen, die wichtigen Infos dazu habe ich ja in diesem und meinen frühreren Postings zu diesem Thema geliefert...

An alle Nutzer, die sich durch dieses ganze Posting gekämpft haben: Danke für die Aufmerksamkeit! Ich hoffe, dieser Ausflug in die Untiefen der Protokolle von SIP, RTP und Co. war für den einen oder anderen Nutzer auch ein bißchen von Interesse.

cu talk