[Gelöst] Anruf scheitert wegen fragmentierter SIP Messages

[essex_man]

Hallo Experten,

ich habe eine FB7590 (7.57) die ich hinter einem 4G Router in Bridge Mode betreibe. Mein Mobilfunkbetreiber (Three UK) teilt eine IPv4 Adresse aus. Abgehende Telefongespraeche gehen ueber Freevoipdeal. Manchmal, in letzter Zeit haeufiger, kommt keine Verbindung zustande, ich hoere kein Freizeichen, das angerufene Telefon klingelt nicht. Nach einer Weile "No User Responding" im Display from DECT Phone. Dann geht es mal wieder (bei Anrufen zu der selben Nummer)

Zunaechst habe ich eine erweitere Supportdatei erstellt und kann hier sehen was passiert:

2023-12-20 17:49:01.430 - OUT: my=192.168.1.1%19:5060 peer=77.72.174.128 port=5060 UDP, sipiface=voip tcclass=sip, netmark=0:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 92.xx.xxx.xxx:5060;rport;branch=z9hG4bK3C0D664BE05CA7BB
Route: <sip:sip.freevoipdeal.com;lr>
From: <sip:[email protected]>;tag=C1BFB9208831C3C6
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 49 INVITE
Contact: <sip:[email protected];uniq=BCF1197D043C194111A548D193BC8D9>
Max-Forwards: 70
Expires: 120
P-Early-Media: supported
User-Agent: AVM FRITZ!Box 7590 154.07.57 (Sep  2 2023)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Content-Type: application/sdp
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length:   455

v=0
o=user 3859233 3859233 IN IP4 92.xx.xxx.xxx
s=call
c=IN IP4 92.xx.xxx.xxx
t=0 0
m=audio 7078 RTP/AVP 9 8 0 2 102 100 99 101 97 18 120 121
a=sendrecv
a=rtpmap:2 G726-32/8000
a=rtpmap:102 G726-32/8000
a=rtpmap:100 G726-40/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=fmtp:18 annexb=no
a=rtpmap:120 PCMA/16000
a=rtpmap:121 PCMU/16000
a=rtcp:7079
a=ptime:20


2023-12-20 17:49:01.483 - IN: my=192.168.1.1%19:5060 peer=77.72.174.128 port=5060 UDP, sipiface=none:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 92.xx.xxx.xxx:5060;rport;branch=z9hG4bK3C0D664BE05CA7BB
From: <sip:[email protected]>;tag=C1BFB9208831C3C6
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 49 INVITE
Contact: <sip:[email protected]:5060>
WWW-Authenticate: Digest realm="sip.freevoipdeal.com", nonce="3646041531", algorithm=MD5
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK, BYE, CANCEL, INVITE, REGISTER, OPTIONS, INFO, MESSAGE
Content-Length: 0



2023-12-20 17:49:01.484 - OUT: my=192.168.1.1%19:5060 peer=77.72.174.128 port=5060 UDP, sipiface=voip tcclass=sip, netmark=0:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 92.xx.xxx.xxx:5060;rport;branch=z9hG4bK3C0D664BE05CA7BB
Route: <sip:sip.freevoipdeal.com;lr>
From: <sip:[email protected]>;tag=C1BFB9208831C3C6
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 49 ACK
User-Agent: AVM FRITZ!Box 7590 154.07.57 (Sep  2 2023)
Content-Length: 0



2023-12-20 17:49:01.490 - OUT: my=192.168.1.1%19:5060 peer=77.72.174.128 port=5060 UDP, sipiface=voip tcclass=sip, netmark=0:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 92.xx.xxx.xxx:5060;rport;branch=z9hG4bK7E7BC13C162BD795
Route: <sip:sip.freevoipdeal.com;lr>
From: <sip:[email protected]>;tag=C1BFB9208831C3C6
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 50 INVITE
Contact: <sip:[email protected];uniq=BCF1197D043C194111A548D193BC8D9>
Authorization: Digest username="aaaaaaaaaa", realm="sip.freevoipdeal.com", nonce="3646041531", uri="sip:[email protected]", response="c59d4116ae8722966ed44b691ed73480", algorithm=MD5
Max-Forwards: 70
Expires: 120
P-Early-Media: supported
User-Agent: AVM FRITZ!Box 7590 154.07.57 (Sep  2 2023)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Content-Type: application/sdp
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length:   455

[SDP part entfernt]

2023-12-20 17:49:01.990 - OUT: my=192.168.1.1%19:5060 peer=77.72.174.128 port=5060 UDP, sipiface=voip tcclass=sip, netmark=0:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 92.xx.xxx.xxx:5060;rport;branch=z9hG4bK7E7BC13C162BD795
Route: <sip:sip.freevoipdeal.com;lr>
From: <sip:[email protected]>;tag=C1BFB9208831C3C6
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 50 INVITE
Contact: <sip:[email protected];uniq=BCF1197D043C194111A548D193BC8D9>
Authorization: Digest username="aaaaaaaaaa", realm="sip.freevoipdeal.com", nonce="3646041531", uri="sip:[email protected]", response="c59d4116ae8722966ed44b691ed73480", algorithm=MD5
Max-Forwards: 70
Expires: 120
P-Early-Media: supported
User-Agent: AVM FRITZ!Box 7590 154.07.57 (Sep  2 2023)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Content-Type: application/sdp
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length:   455

[SDP part entfernt]

Der SDP Part ist bei allen INVITEs derselbe, habe den aus Platzgruenden geloescht. Die WW-Authenticate Antwort habe ich nachgerechnet, sie ist korrekt. Die INVITE message mit Authentication wird sechs mal wiederholt, dann gibt die FB auf.

Zunaechst habe ich angenommen dass der Fehler Bei FVD liegt. Dann habe ich mal die Wireshark traces auf der FB angeworfen um zu sehen was wirklich verschickt wird. Da sieht man dann deutlich dass die INVITE message mit Authentication alle fragmentiert werden. Und das scheint wohl bei FVD nicht so gut anzukommen.

Obwohl ich noch keinen Packettrace von einem erfolgreichen Gespraech habe, gehe ich mal davon aus dass die SIP messages in dem Fall nicht fragmentiert werden und deswegen alles paletti ist.

Die INVITE messages mit Authentication sind mit 1481 Byte IP Payload natuerlich zu gross und muessen fragmentiert werden, es ist nur seltsam dass die FB diese dann in 736 / 744 /1 Byte zerlegt wenn vorher 1279 Byte IP Payload unzerlegt versendet werden.

Anscheindend laesst sich die max MTU Size an der Fritzbox nicht verstellen, habe zumindest nichts gefunden. Vielleicht weiss ja hier jemand wie ich das Problem loesen kann.

 

[stsoft]

Du könntest mal HD in den Einstellungen beim DECT-Telefon deaktivieren, dann wird das INVITE kleiner.

 

[frank_m24]

Eine Lösung hab ich nicht, aber siehst du im Trace was von Path MTU Discovery? Das könnte zumindest das komische MTU Verhalten erklären. Was man dann dagegen machen könnte, weiß ich aber auch noch nicht.

 

[FlyingToaster]

Hatte ich vor Jahren mal mit der Telekom, einzige Lösung war damals die SIP-Umstellung von UDP auf TCP.

 

[PeterPawn]

Oder mal testen, was passiert, wenn man als Transportprotokoll TCP auswählt (derzeit ist es ja UDP bzw. "automatisch" lt. Supportdaten) - das hat schon als Protokoll eine bessere Behandlung für fragmentierte Pakete.

EDIT: zu langsam, aber egal

 

[essex_man]

Oder mal testen, was passiert, wenn man als Transportprotokoll TCP auswählt

Dann geht gar nichts mehr, schon der SIP REGISTER bei FVD funktioniert nicht. Anscheinend wird TCP von FVD nicht unterstuetzt

Du könntest mal HD in den Einstellungen beim DECT-Telefon deaktivieren, dann wird das INVITE kleiner.

Das werde ich mal probieren, sollte 109 Bytes einsparen. Rein rechnerisch muesste weiterhin fragmentiert werden da der INVITE weiterhin zu gross ist, aber vielleicht wird dann ja ploetzlich anders fragmentiert.

Eine Lösung hab ich nicht, aber siehst du im Trace was von Path MTU Discovery?

Im Trace kann ich nichts finden, aber in der Support Datei steht

0: name internet (attached, active internet)
0: sync_group: sync_ata
0: iface wan RBE/14/dsl dc:39:6f:dd:db:77 stay online 1 (prop: default internet)
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2023-12-19 13:22:05 (setup time 0 secs) (connect cnt 1)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 92.41.xxx.xxx mask 255.255.255.192 gw 92.41.xxx.xxx dhcp mtu 1380
0: IPv4: masqaddr 92.41.xxx.xxx
0: IPv4: dns 188.31.250.128 188.31.250.129

also ganz klar MTU 1380 Bytes. Und bei Ping Tests werden auch 1380 Byte Fragmente verschickt.

UDP Fragmentation scheint ein bekanntes Problem bei SIP zu sein, da gibt es im Internet reihenweise Artikel zum Problem aber natuerlich keine richtige Loesung.

Da muss ich mal an AVM schreiben, vielleicht koennen die mir ja mal erklaeren warum die SIP messages so seltsam fragmentiert werden.

 

[frank_m24]

also ganz klar MTU 1380 Bytes.

Ja, auf dem letzten Teilstück. Das heißt nicht, dass es auf dem ganzen Weg zum SIP Server so ist.

Schau noch mal in den Trace, ob du ICMP Nachrichten über dropped Packets, die zur SIP Verbindung gehören, findest. Das könnte ein Hinweis sein.

 

[essex_man]

Nein. keine ICMP Nachrichten im Zusammenhang mit den SIP messages zu FVD. Die MTU von 1380 Bytes wird vom Mobilfunknetz diktiert (bei GTP-U passte infach nicht mehr rein). Ich glaube nicht dass im weiteren Internet noch niedrigere MTUs auftreten (sonst wuerde es ja ggf. auch ICMP messages von unterwegs geben).

Habe gerade mal FVD mit Pings (1500 Byte Payload) behaemmert:

--- 77.72.174.128 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 599752ms
rtt min/avg/max/mdev = 45.147/55.815/115.439/5.148 ms

Zero packet loss! ich vermute eher dass die Fragmetierung in 736 / 744 /1 Byte dazu fuehrt dass die Pakete nicht in der richtigen Reihenfolge bei FVD ankommen und die Reassembly deshalb nicht klappt bzw. wenn das Gespraech zustande kommt sind die Pakete in der richtigen Reihenfolge angekommen.

 

[essex_man]

Habe gerade nochmal ausgiebig getestet:

16.51 fail
reassembled IPv4 Length 1482
fragmentation 736/744/2

16.52 ok
reassembled IPv4 Length 1480
fragmentation 736/744

16.53 ok
reassembled IPv4 Length 1480
fragmentation 736/744

16.54 fail
reassembled IPv4 Length 1482
fragmentation 736/744/2

Ich habe noch nicht nachgesehen warum die SIP INVITEs unterschiedliche Laengen haben (war immer dieselbe Nummer mit Wahlwiederholung), aber davon ab scheint FVD nicht mit der (unnoetigen) Fragmentation in drei Pakete klarzukommen.

Ich habe jetzt HD Voice abgeschaltet und bisher waren alle Anrufsversuche erfolgreich, die SIP INVITE Message wird in zwei Pakete fragmentiert und alles ist gut.

Das ist zwar keine Loesung aber immerhin geht das Telefonieren jetzt wieder (gerade rechtzeitig vor Weihnachten!).

 

[essex_man]

Da muss ich mal an AVM schreiben, vielleicht koennen die mir ja mal erklaeren warum die SIP messages so seltsam fragmentiert werden.

AVM hat jetzt geantwortet, aber leider nur Hinweise auf Artikel in der Wissensdatenbank, die leider das Problem nicht beheben.
Was die seltsame IP Fragmentierung angeht gab es keine Reaktion. Ich habe nochmals um Weiterleitung an die Entwicklungsabteilung gebeten. Mal abwarten ob sich das jemand ansieht.

 

[AachenChris]

Und? Was war das Ergebnis? Haben Sie es weitergeleitet?
FVD kann die Fragmentierung nicht ab und ich vermute vorher war das auc nicht der Fall ...

 

[essex_man]

Ja, ich habe dem AVM Service nochmal eine aufuehrliche Fehlerbeschreibung und Wirshark Traces gechickt. Der letzte Stand (4 Januar 2024) der Diskussion mit dem AVM Service ist wie folgt:

Guten Tag Herr xxx,

vielen Dank für Ihre Geduld.

Mein Kollege Herr yyy hatte mit mir den Fall besprochen. Nach Durchsicht Ihrer Anfrage möchte ich mich Ihrem Ticket persönlich annehmen. Aktuell lässt sich der Sachverhalt noch nicht abschließend bewerten. Ich befinde mich aber bereits mit anderen Abteilungen im Informationsaustausch.
Aufgrund dessen, dass wir es hier auf den ersten Blick nicht mit einer Standardanfrage zu tun haben, möchte ich Sie noch um ein wenig Geduld bitten. Ihr Fall befindet sich nun in der tieferen Analyse. Ich melde mich, sobald ich weitere Informationen für Sie habe.

Freundliche Grüße aus Berlin
zzz zzz (AVM Support)

Fuer die Beseitiguing des Problems ist natuerlich eine neue FritzOS Version noetig (oder vielleicht vorab in einer Laborversion). In der Zwischenzeit verzichte ich eben auf HD Telefonie.

 

[AachenChris]

Ich habe das in der Zwischenzeit ein wenig analysiert.
Das SIP INVITE der Fritzbox an sip.freevoipdeal hat eine payload von 1518 bytes und wird konsequenterweise fragmentiert.
sip.freevoipdeal.com reassembliert die (korrekten) Pakete nicht -> Ende des Verbindungsaufbau. Warum sie die Paket nicht zusammenbauen ist mir ein Rätzel, sooo viel Aufwand ist es nicht; es geht schließlich nur um den Rufaufbau.
Es gibt eine alternative Adresse von FVD: 77.72.169.131
Dorthin sendet dei FB 1247 byte payload, dementsprechend in einem unfragmentierten Paket.
Der größte Unterschied ist, dass zu sip.freevoipdeal.com die Authentication beim INVITE direkt mitgeschickt wird ... aber nicht nur das.
Das Fragmentieren der SIP UDP Packete ist ein klarer Verstoß gegen den Standard:

https://www.ietf.org/rfc/rfc3261.txt:

18.1.1
...
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
...
Aber FVD akzeptiert kein TCP.
Also sendet AVM nicht stardard konforme SIP INVITES.
Also nehme 77.72.169.131.

 

[essex_man]

Es gibt eine alternative Adresse von FVD: 77.72.169.131
Dorthin sendet dei FB 1247 byte payload, dementsprechend in einem unfragmentierten Paket.

Wieso ist bei der alternativen IP Adresse die Payload kleiner? Oder wird die dann im SIP Header explizit eingetragen, also an Stelle von "freevoipdeal.com" die IP Adresse (was natuerlich kuerzer ist).

Alternative, dass sip.freevoipdeal.com mit fragmentierten Paketen umgehen kann.

Das waere natuerlich gut, generell nehme ich an dass das auch funktioniert aber das Fragmentieren in 736/744/2 ist natuerlich Bloedsinn, alle Pakete (bis auf das letzte) sollten die maximal auf dem Link zulaessige Laenge haben, also wenn es denn 744 Bytes waeren, dann sollte in 744/738 fragmentiert werden und nicht 736/744/2. Kein Wunder dass das reassmbly dann nicht klappt.

 

[AachenChris]

Das Paket ist kürzer, weil der Server andere features hat. Ich bin nicht im Einzelnen durchgegangen, welche Felder es waren.
Fragmentierte UDP Pakete gehen sehr oft verloren (und dürfen auch verloren gehen), aus den verschiedensten Gründen. Deshalb sieht der Standard auch vor, was dann zu tun ist, etwa TCP zu benutzen, wenn die SIP Pakete größer werden als die MTU (siehe https://www.ietf.org/rfc/rfc3261.txt,18.1.1).
FVD müsste TCP können, was aber nicht der Fall ist. FVD verliert sicherlich eine Menge Geld durch nie zustande kommende Telefonate (und wenn die INVITE Pakete nicht einmal bis zu ihnen kommen, merken sie es noch nicht einmal).
Die AVM "Lösung" ist mehr als unglücklich, da die Fehlermeldung nicht ist: der FVD server sollte TCP unterstützen bei unserem langen INVITE, sondern stattdessen fragmentierte UDP versenden, die dann in einen für den Anwender absolut nichtssagenden timeout rennen. Alternativ sollten sie Felder aus dem INVITE rausnehmen bis nicht mehr fragmentiert werden muss, was wohl die praktikabelste Lösung für solche server wäre, die nur UDP unterstützen.

 

[essex_man]

FVD müsste TCP können, was aber nicht der Fall ist.

Ja, die koennen leider kein TCP, aber damit sind sie bestimmt nicht die einzigen.

FVD verliert sicherlich eine Menge Geld durch nie zustande kommende Telefonate

Na ja, wenn ich Freedays habe, dann freut sich FVD sicher wenn das Telefonat nicht zustande kommt

Aber im Ernst, das Problem tritt wahrscheinlich nicht so haeufig auf dass es bei FVD & Co. zu Umsatzverlusten fuehrt: Bei DSL liegt die MaxMTU Size bei 1452 bis 1500 bytes, bei mir wegen LTE nur bei 1380 bytes. Ob die seltsame Fragmentierung bei DSL auch auftritt kann ich nicht mehr verifizieren (mein DSL Anschluss ist stillgelegt) aber wegen der groesseren MaxMTU Size ist die Wahrscheinlichkeit von Fragmentierung natuerlich niedriger.