[Problem] Bitte rufen Sie den Teilnehmer zu einem späteren Zeitpunkt an

[Telekom hilft Team]

@nobody.loopback: Ich hoffe wirklich, dass wir bei dir bald weiter kommen. Hast du meine Kollegen auch in Kenntnis gesetzt?

Viele Grüße

Natalie P. von Telekom hilft

 

[nobody.loopback]

Ich habs ja telefonisch versucht, aber das führte dazu, dass ich erstmal erschöpt aufgegeben habe.
Und:
Der Mitarbeiter, der den Versuch vorbeizukommen abgebrochen hat, der hat im Formular, das mir die Tkom in kopie geschickt hat "Servienachweis", leider angekreuzt: "kunde nicht angetroffen", Tätigkeit: kein Fehler (F. n. endg beseitigt), anstatt dort zu vermerken, dass sich jemand an anderer Stellt um das problem kümmern muss.

Was soll man dazu noch mehr sagen, als dass eine Aufrüstung des gemeinen Telekom-Kunden mit boden-boden Raketen, Ziel Bonn umgehend vom Bundestag beschlossen werden muss?

 

[rerhafnhabu]

Tätigkeit: kein Fehler (F. n. endg beseitigt)

Ich lese das so:
Er konnte keinen Fehler feststellen, Fehler nicht endgültig beseitigt.

 

[Telekom hilft Team]

Ich lese das so:
Er konnte keinen Fehler feststellen, Fehler nicht endgültig beseitigt.

Das ist auch meine Übersetzung.

Viele Grüße

Natalie P. von Telekom hilft

 

[nobody.loopback]

Wenn es so ist, dann ist ja noch nicht ganz hoffnungslos.

 

[Telekom hilft Team]

Wenn es so ist, dann ist ja noch nicht ganz hoffnungslos.

Das ist es auf jeden Fall nicht. Hoffentlich gibt es bald eine endgültige Lösung.

Viele Grüße

Natalie P. von Telekom hilft

 

[nobody.loopback]

Das Problem ist nun höchstwahrscheinlich klar, wenn auch nicht gelöst:
Bei den Anrufern, die mich nicht erreichen, da schickt die Telekom das Sip-Paket mit dem INVITE fragmentiert in drei Paketen. Die Anrufer bei denen es funktioniert, da ist es nicht fragmentiert.

Ich habe mir auch einen Speedport besorgt, und, dort kommt der Ruf an.
Dann habe ich mich mit Wireshark in die Wan Seite eingehängt, und beobachtet was passiert:
Das fragmentierte Paket hat eine Größe von zusammen 1650bytes
Das nicht fragmentierte eine größe von braven 1280 bytes.
Eigentlich (?) soll ein SIP paket maximal MTU (1500) - 200 bytes größe haben.

Es fragt es sich natürlich, wen hier die Verantwortung trifft. Das ist das nächste, was ich raussuchen muss.
hier:
https://tools.ietf.org/html/draft-gurbani-sip-large-udp-response-00

gibt es einen Text, der legt nahe, die Telekom müsste sich eigentlich anders verhalten.
Auch gibt es eine RFC die sagt, die Telekom müsste in diesem Fall das protokoll auf TCP wechseln wenn die gefahr besteht, dass das Paket >1500 bytes wird. Angeblich gibt es da die möglichkeit das der Gegenstelle anzukündigen. Ob aber meine 3CX tel.Anlage überhaupt SIP über TCP ohne TLS spricht, dass muss ich auch erstmal noch herausbekommen.
Andererseits wäre es natürlich auch gut, wenn der Router schlauer wäre - Die Firma Draytek die werde ich auch fragen gehen. Auf dem Draytek läuft ein OpenWrt. Eigentlich müsste es dort ja auch kenntnisse zu diesem Problem geben.
Der Speedport, der hat hier natürlich weniger probleme, denn der ist ja nicht hinter NAT sondern direkt am WAN. Da gibts wohl weniger Schwierigkeiten UDP pakete zu reassemblieren.
Nur, Speedport, das ist eigentlich keine lösung, selbst wenn die Telekom hier keine schuld trifft. Mit dus.net gibt es eine derartigen Probleme, und vermutlich (was aber noch zu testen wäre) auch nicht mit Sipgate oder QSC.
Dann habe ich noch den zweiten Standort, gleicher Router, gleiches modem, gleiche Firmware-Versionen. Und, auch telekom (mit 50 statt 100Mbit down), Und da gibt es diese Probleme nicht, zumindest war das vor 2 Monaten noch so. Und warum betrifft dieses Problem nur einen kleinen Kreis Personen, das sieht (gefühlt) eher nach einem Bug bei der Telekom aus.

Wenn hier jemand erfahrung hat würde mich das interessieren.

Zum Schluss noch etwas zur Telekom:
Ich halte es weiterhin für einen falsche Entscheidung der Telekom den Kunden das komplette Risiko aufzubürden mit VoIP zurande zu kommen. Wenn die Telekom sparen will, dann sollte die die Kosten und die Verantwortung tragen (zumindest dort wo nicht gerade nur Call+Surf verkauft wird). Heisst: Die Telekom hätte anstatt mit Kündigung zu drohen, den Kunden einen von der Telekom gemanagte Blackbox mit ISDN und eine Netzwerksteckdose mit DHCP und einer öffentlichen IP zur Verfügung stellen müssen, Kosten und Anschluss zu lasten der Telekom. Das wäre gerecht gewesen und, weiterhin wäre klar gewesen, wo die Verantwortung der Telekom endet und die des Kunden beginnt. Ich kenne genug Kunden mit einem Speedport die alle 1-2 Monate das gerät neustarten müssen, die generell nicht angerufen werden können usw. Im vergleich zu ISDN ist das ein ganz klarer Rückschritt bezüglich Zuverlässigkeit. Mehr Features bietet VoIP nicht (zumindest nicht das von der Telekom!).

Edit: habe 3xc auf SIP über TCP umgestellt - geht.

 

[KunterBunter]

Heisst: Die Telekom hätte anstatt mit Kündigung zu drohen, den Kunden einen von der Telekom gemanagte Blackbox mit ISDN und eine Netzwerksteckdose mit DHCP und einer öffentlichen IP zur Verfügung stellen müssen, Kosten und Anschluss zu lasten der Telekom. Das wäre gerecht gewesen und, weiterhin wäre klar gewesen, wo die Verantwortung der Telekom endet und die des Kunden beginnt.

Die meisten Leute nennen so etwas Routerzwang. Deshalb wird der jetzt verboten.

 

[nobody.loopback]

Wie meinst Du das?
mein Vorschlag ist ja gerade kein routerzwang! Ich bekomme (wie bei jedem besseren Tarif/anbieter) eine öffentliche IP Adresse und z.B. einen ISDN anschluss. Was ich dann mache, ist mir überlassen.
Da kann ich jeden router meiner wahl anschliessen, oder sogar keinen. Und telefonieren kann ich auch. Und VPN kann ich auch haben.

Hingegen jetzt haben wir einen de-facto-routerzwang bei der Telekom, denn nur mit Forschung funktioniert es mit anderer Technik.

 

[andreas00]

Hingegen jetzt haben wir einen de-facto-routerzwang bei der Telekom, denn nur mit Forschung funktioniert es mit anderer Technik.

So sehe ich es auch. Denn entweder man nimmt für seinen Anschluß bei der Telekom einen Speeport oder ein Produkt von AVM (z.B. AVM 7490) und die Telefonie funktioniert zuverlässig oder man nimmt andere Hardware und die Telefonie funktioniert leider nur unzuverlässig.

 

[thtomate12]

Tja, man sollte halt schon einen professionellen Router haben, der es nicht schuld sein kann.

BTW: Seit wann muss die Telekom sich an RFCs halten und erst recht abgelaufene Entwürfe?

 

[nobody.loopback]

Das sieht mir nicht abgelaufen aus.
Hier ist ein schöner Artikel zu dem Thema, und der ist aktuell und liest sich glaubwürdig.
http://blog.csrpswitch.com/sip-udp-fragmentation-and-kamailio-the-sip-header-diet/

Und auch hier:
https://support.software.dell.com/kb/sw10958

Ist man der Meinung, das ist ein Fehler der telekom. Das sonic wall OS release ist von ende 2015. Die router von SonicWall sind eigentlich auch nicht gerade Spielzeuge.

 

[qwertz.asdfgh]

... Die Telekom hätte anstatt mit Kündigung zu drohen, den Kunden einen von der Telekom gemanagte Blackbox mit ISDN und eine Netzwerksteckdose mit DHCP und einer öffentlichen IP zur Verfügung stellen müssen, Kosten und Anschluss zu lasten der Telekom.

Ist das nicht das wo sich viele dafür eingesetzt haben, dass genau so etwas eben nicht passiert?

mein Vorschlag ist ja gerade kein routerzwang!

Hm, so gesehen auf den ersten Blick richtig, aber nur auf den ersten Blick. Das neue Gesetz heißt allerdings nicht "Gesetz gegen Routerzwang", so wird es nur umgangssprachlich genannt, sondern "Gesetz zur Auswahl und zum Anschluss von Telekommunikationsendgeräten" oder umgangssprachlich einfacher aber dennoch exakter "Gesetz zur freien Modem- und Routerwahl", beugt also nicht nur dem Routerzwang vor sondern u.a. auch einem Modemzwang (das von dir bevorzugte Modell würde aber genau das voraussetzen). Der Netzabschlusspunkt in den Räumen des Kunden darf nur mit passiver Technik umgesetzt werden und genau das widerspricht wiederum deinen Ideen.

Genau genommen hat auch die Telekom das neue Gesetz noch nicht vollständig umgesetzt wenn man es genau nimmt, z.B. bei GPON-Anschlüssen (nur mal so nebenbei bemerkt, ist ja sowieso schon OT genug). Von den TV-Kabelnetzbetreibern natürlich ganz zu schweigen (und u.a. aus der Praxiserfahrung die man mit diesen Anbietern schon sammeln konnte sträuben sich bei deinen Vorschlägen sicherlich auch schon bei einigen wieder die Nackenhaare).

Wer eine Lösung bevorzugt die deiner Vorstellungen nahe kommt kann das übrigens auf Wunsch von der Telekom bekommen, freiwillig versteht sich, kein Zwang, muss aber von der Telekom gekauft oder gemietet werden. Und nein, ich spreche hier nicht von Speedports (die übrigens für die einfachen Ansprüche im privaten aber auch geschäftlichen Umfeld (bei (sehr) kleinen Büros z.B.) übrigens ausreichend sind und auch dort zuverlässig ihren Dienst verrichten können und z.B. nicht ständig manuell neu gestartet werden müssen), sondern z.B. von Geräten die die Telekom ganz offiziell Geschäftskunden (auf Wunsch mit Service, natürlich nicht kostenlos) anbietet, z.B. Zyxel Speedlink 5501, Digitalisierungsbox Standard/Premium oder auch Lancom 1783VA, R800V und sicher bald auch 883/884VoIP. Wer es also nicht schafft mit der eigenen Technik und sich evtl. überfordert füllt kann es auch mal damit probieren...

 

[thtomate12]

Das sieht mir nicht abgelaufen aus.

Was steht dann in der vierten Zeile? "Expires: [...] 2007"

 

[nobody.loopback]

thtomate12: es gibt ja noch mehr Dokumente dazu - das war nur das erste, was ich dazu gefunden habe. Ich denke weiterhin nicht, dass die Vorgabe falsch ist, keine UDP Pakete >MTU zu verschicken.

Aber, etwas ganz anderes ist heute passiert:
Ich hatte gestern das noch positiv getestet, nach der Registrierung mit ;Transport=TCP konnte ich auch ein Gespräch von der betreffenden Gegenstelle empfangen.
Heute aber nicht mehr. Zwar sagt der Telekom Server auf die Registrierung hin "200 OK", aber dennoch ist jedes INVITE über udp und nicht TCP.
Was könnte es da für einen Grund geben? Technik, die sich zufällig verhält ist noch wesentlich lästiger, als hartnäckige Fehler.

Vielleicht honorieren nicht alle Server der Telekom den Wunsch nach kommunikation SIP over TCP, bzw manche nur, wenn man selber beim REGISTER schon TCP spricht?
Mit X-Lite kann man das, und, dann kommt der ruf auch heute an. Die 3CX Tel. Anlage die schickt die Registrierung per UDP und hofft, die rückmeldungen kommen dann per TCP.

 

[broeselmeier]

Nachdem ich auf das Problem von Nobody im Draytek-Forum gestoßen bin und mir exemplarisch 2 Invite-Messages ansehen konnte, die Nobody mit Wireshark eingefangen hat, hier vielleicht mal eine Zusammenfassung des Problems, wie es sich für mich derzeit darstellt.

Vorab. Es ist wie fast immer bei SIP/RTP, dass man wegen der Vielschichtigkeit der Thematik, nicht einfach eine Lösung oder einen Verantwortlichen für das Problem findet.

Ausgangslage:
Am Telekom-VDSL-Anschluss sind Draytek Modem und Draytek Router angeschlossen. Im LAN hinter dem Router arbeitet eine Software-TA von 3CX als SIP user agent mit SIP-Account der Telekom.

Problem:
Einige Anrufer können diesen SIP-Account nicht anrufen (niemals und reproduzierbar). Bei einem Anrufversuch tut sich lange nichts, dann erhält der Anrufer die Ansage: Bitte rufen Sie den Teilnehmer zu einem späteren .... Eine Umleitung des Anrufers auf die Sprachbox der Telekom, wie sie bei nicht registriertem SIP-Client normalerweise gemacht wird, erfolgt nicht.

Analyse:
Versucht einer der bekannten Problemanrufer einen Anruf, dann kommt am WAN-Interface des Draytek-Routers eine UDP-SIP-Invite-Message an, die größer ist als die MTU der PPPOE Verbindung (1492 Byte?). D.h. es kommen zwei IP-Pakete mit UDP-Fragmentierungskennung.
Die beiden IP-Pakete mit UDP-Fragmentierungskennung werden vom Draytek Router verworfen.
Eine der langen Invite-Messages, die mit Wireshark eingefangen wurden, die ich gesehen habe, stammte von einem Speedport W 724V mit t-online SIP-Account. Das was die Message (unnötig?) lang machte, stammte offensichtlich alles vom Speedport. z.B. ca. 350 Byte SDP-Content-Length mit ewig vielen Optionen, umfassende und längliche USER-AGENT Angabe mit Firmwareversion des Speedports, ein doppeltes P-Asserted-Identity Header Feld, Header-Bezeichner in Langform.

Hier ist das Problem ganz gut beschrieben http://thomas.gelf.net/blog/archives/Smaller-SIP-packets-to-avoid-fragmentation,27.html


Bewertungsversuche:

* Warum verwirft der Draytek-Router fragmentierten UDP-Traffic?

Der Router scheint Regeln ab Level4 aufwärts anwenden zu wollen. Dazu müsste er fragmentierten UDP-Traffic zusammensetzen.
Da es aus Sicht der Routerprogrammierer keinen sinnvollen Anwendungsfall für fragmentierten UDP-Traffic gibt und das Zusammensetzen von IP-Paketen zu einem vollständigen UDP-Datagramm keine naheliegende Aufgabe für einen Router ist, werden IP-Pakete, die Fragmente eines UDP-Datagramms sind, verworfen.
Diese Erklärungen hier erschienen mir plausibel für das Verhalten
http://www.cisco.com/c/en/us/suppor...ncapsulation-gre/25885-pmtud-ipfrag.html#anc2

Prinzipiell machen so etwas wohl überhaupt erst Router ab einer bestimmten Leistungsklasse. Draytek scheint da auch nicht ganz allein zu sein wenn man sich das hier anschaut https://support.software.dell.com/kb/sw10958

* Warum schickt der SIP-Server der Telekom große Invite-Messages als fragmentierten UDP-Traffic?

UDP ist wegen der deutlich geringeren Serverlast die bevorzugte Übertragungsvariante für SIP-Provider.

RFC3261 sagt zwar "MUST" zu TCP wenn sich die SIP-Messagegröße bis auf 200Byte an die MTU angenähert hat, es sagt aber auch "MUST" zur Unterstützung von UDP-Datagrammen bis zur theoretischen Größe von ca. 64 KByte für SIP-Clients.

Da das Problem mit fragmentiertem UDP-Traffic aber an Routern auftritt, liefert der SIP-RFC wahrscheinlich nicht die richtige Begründung, in wie weit Router mit fragmentiertem UDP-Traffic rechnen müssen. In so fern liefert RFC3261 mit dem Hinweis auf TCP nur einen Anhaltspunkt, dass fragmentierter UDP-Traffic bei SIP nicht sein soll.


Bisherige Lösungsversuche seitens nobody:

* einen "accept fragmented UDP-Traffic" Schalter gibt es im Draytek Router nicht

* RFC3261 liefert den Hinweis auf TCP.

Manche SIP-Clients kann man dazu zwingen, bei der Registrierung TCP zu verwenden. Vermutung: Wenn sich der SIP-Client per TCP registriert, dann verwendet der SIP-Server auch TCP für die Rufsignalisierung. Das funktioniert bei den Telekom SIP-Servern auch tatsächlich so. Problem: Nur die wenigsten SIP-Clients lassen sich explizit zu TCP für die Registrierung zwingen.

* Umleitung des Telekom-SIP-Accounts im Kundencenter auf einen DUS.net-SIP-Account.

Die Problemanrufer kommen jetzt durch. Aber auch der DUS SIP-Server macht die Signalisierung nicht per TCP.

Vermutung1:
Falls die Telekom die Anrufe in Folge der Umleitung über PSTN an DUS vermittelt, entfernt wahrscheinlich das SIP-PSTN Gateway der Telekom die lange Invite-Message des Speedports. Die kurze Invite-Message, die bei Nobody per UDP ankommt, hat wahrscheinlich das PSTN-SIP-Gateway von DUS erzeugt.

Vermutung2:
DUS entfernt überflüssigen Ballast aus den SIP-Messages und hält die Messages dadurch unter der Grenze von 1292 Byte bis zu der SIP per UDP ohne Fragmentierung funktioniert. (Verkürzungsvorschläge siehe z.B. hier, Abschnitt "let's brake the rules" http://thomas.gelf.net/blog/archives/Smaller-SIP-packets-to-avoid-fragmentation,27.html )

Einen Wireshark Mitschnitt der Invite Message von DUS, wenn der selbe Speedport W 724V anruft, will nobody noch machen.

 

[thtomate12]

Nicht, dass es wieder peinlich für euch wird, aber seid ihr sicher, dass die TCP-Verbindung nicht einfach von eurer NAT abgelehnt wird?

Zusammensetzen von IP-Paketen zu einem vollständigen UDP-Datagramm keine naheliegende Aufgabe für einen Router ist, werden IP-Pakete, die Fragmente eines UDP-Datagramms sind, verworfen.

Es würde auch nicht passen oder hast du zwischen Telefonanlage und Router Jumboframes?

Der Router scheint Regeln ab Level4 aufwärts anwenden zu wollen.

Wie war das mit den Aufgaben eines Routers?

 

[broeselmeier]

Also ich bin mir sicher, dass der Wireshark-Mitschnitt, den mir Nobody geschickt hat, 2 Fragmented IP protocol proto=UDP Pakete enthält, die zusammengesetzt eine Invite-Message eines Speedport W724V mit einer Größe von 1524 Byte ergeben.

Es soll tatsächlich Router/Appliances geben, die Traffic ab Protokollebene4 aufwärts analysieren. Wozu sollen bei solchen Geräten irgendwelche sinnfreien Betrachtungen über die "eigentliche" Aufgabe von Routern gut sein.

Liegen dir Informationen vor bzw. kannst du aus Erfahrung bestätigen, dass die Telekom-SIP-Server normalerweise keine Messages per UDP schicken, die größer sind als die Path MTU?

 

[thtomate12]

Die Telekom-Doku sagt, dass die Grenze der Paketgröße 1300 ist, also eher unabhängig von der Path MTU.

Ihr redet immer vom Speedport W724V, gebt aber nicht welcher Typ, anhand der Informationen auf dem Telekomhilft-Forum nehme ich B an. Habt ihr auch andere getestet?

Es folgt meine Meinung zu dem "Verantwortlichen für das Problem": Alle, außer die vielen Informationen in den Paketen, denn das ist meiner Sicht nach ein Errungenschaft von (Telekom-)SIP/VoIP, sodass das Netz transparenter als das ISDN ist.

• Arcadyan für die Software auf dem Speedport W724V B wegen der angeblichen doppelten Information im Header und wahrscheinlich der Nichtbeachtung von clause 18.1 (Umschaltung auf besseres Protokoll als UDP bei großen Headern) des SIP-RFC (vorgegeben durch TR114)
• die standardmäßige Verwendung von UDP bei SIP
• Router, die Pakete, die sie nicht öffnen können, droppen (machen die das auch bei verschlüsselten Verbindungen wie TLS? )
• Telekom-IMS für die Nichtbeachtung von clause 18.1 (Umschaltung auf besseres Protokoll als UDP bei großen Headern) des SIP-RFC (vorgegeben durch TR114)

PS:

sinnfreien Betrachtungen über die "eigentliche" Aufgabe von Routern gut sein.

Damit hast du angefangen

 

[broeselmeier]

Die Telekom-Doku sagt, dass die Grenze der Paketgröße 1300 ist, also eher unabhängig von der Path MTU.

So steht es etwa auch in rfc3261. D.h. wenn nichts über die Path MTU bekannt ist (dann wird eine Path MTU von 1500 unterstellt) und SIP-Messages müssen ab 1300 Byte per TCP übertragen werden.
Die Telekom könnte allerdings wissen, dass die MTU von PPPOE kleiner als 1500 ist. Max. 1300 Byte für UDP wäre aber schon mal ein Anfang, wenn sie es denn auch so machen würden.

Kannst du bitte mal einen Link zu der Telekom-Doku geben?

Ihr redet immer vom Speedport W724V, gebt aber nicht welcher Typ, anhand der Informationen auf dem Telekomhilft-Forum nehme ich B an. Habt ihr auch andere getestet?

Vielleicht noch einmal zum Verständnis des Problems:

Der hier exemplarisch erwähnte Speedport steht bei einem der Anrufer, die bei Nobody nicht anrufen können. Es ist sicher schon nicht einfach, überhaupt die Leute zu ermitteln, die nicht anrufen können, noch viel schwieriger wird es sein, sie nach ihren Telefonieanbietern und ihrem Telefonie-Equipment auszufragen und sie dann noch mehrfach zu Testanrufen zu überreden.

Es kann im konkreten Fall auch nicht zielführend sein, die Welt nach SIP-Clients abzuklappern, die lange Invite-Messages produzieren. Es gibt sie einfach und die langen Messages sind grundsätzlich auch zulässig.

Falls es hilft, hier die user agent Zeile aus dem Header der langen Invite-Message:

User-Agent: Speedport W 724V/Version 01011603.00.008

Das doppelte Header Feld:

P-Asserted-Identity: <sip:[email protected]>
P-Asserted-Identity: <tel:+49712345678>

Der längliche SDP content

v=0
o=- 307979852 677332281 IN IP4 217.0.23.36
s=-
c=IN IP4 217.0.4.69
t=0 0
m=audio 19320 RTP/AVP 8 0 121 120 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:121 PCMA/8000
a=gpmd:121 vbd=yes
a=rtpmap:120 PCMU/8000
a=gpmd:120 vbd=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32
a=ptime:20
a=maxmptime:20 20 20 20 20

Es folgt meine Meinung zu dem "Verantwortlichen für das Problem":
Alle, außer die vielen Informationen in den Paketen, denn das ist meiner Sicht nach ein Errungenschaft von (Telekom-)SIP/VoIP, sodass das Netz transparenter als das ISDN ist.

• Arcadyan für die Software auf dem Speedport W724V B wegen der angeblichen doppelten Information im Header und wahrscheinlich der Nichtbeachtung von clause 18.1 (Umschaltung auf besseres Protokoll als UDP bei großen Headern) des SIP-RFC (vorgegeben durch TR114)
• die standardmäßige Verwendung von UDP bei SIP
• Router, die Pakete, die sie nicht öffnen können, droppen (machen die das auch bei verschlüsselten Verbindungen wie TLS? )
• Telekom-IMS für die Nichtbeachtung von clause 18.1 (Umschaltung auf besseres Protokoll als UDP bei großen Headern) des SIP-RFC (vorgegeben durch TR114)

Ja, der Speedport hätte genau genommen, seine Message gleich per TCP verschicken müssen, denn wenn man den VIA-Header abzieht, den erst der Telekom-Proxy hinzugefügt hat, dann ist die Message immer noch größer als 1300 Byte.

Via: SIP/2.0/UDP 217.0.23.36:5060;branch=z9hG4bKg3Zqkv7ieh6tqb8vqhgnxvsll6eu8mr3d

Da aber die Telekom das SIP-Equipment, das sie selbst vertreibt, entsprechend zertifiziert, könnte man davon ausgehen, dass es bei der Telekom keine Größenbeschränkung für SIP über UDP gibt.
Die Message, die bei Nobody ankommt, hat der SIP-Proxy der Telekom erzeugt.
Spätestens er hätte TCP verwenden müssen, da durch seinen VIA-Header die Message größer als die MTU wurde. Es spricht einiges dafür, dass mindestens die Telekom keine Anstrengungen unternimmt, um für SIP die Fragmentierung von UDP-Datagrammen zu verhindern.

Die Draytek-Router verwerfen fragmentierten UDP-Traffic nicht, weil sie ihn nicht analysieren können, sondern weil sie ihn für einen potentiellen Angriff halten.