[fli4l] SIP - dynamisc?==?utf-8?Q?he Umschaltung von udp auf ?==?utf-8?Q?tcp

[Erwin Lottermann]

Inzwischen sind ein paar Erkenntnisse hinzugekommen, deswegen hier ein
Update.

Der in rfc3261 beschriebene messagegrößenabhängige Wechsel des
Transportprotokolls von UDP auf TCP bei SIP macht aus den o.g. Gründen
(fehlende manuell eingerichtete Portforwardings) in der Praxis wohl mehr
Probleme als er löst. Zumindest die Telekom und DUS.net scheinen
deshalb derzeit keinen Gebrauch davon zu machen. Für die serverseitige
Kontaktaufnahme mit dem SIP-Client bei einem Anruf verwenden sie das
gleiche Transportprotokoll mit dem sich der SIP-Client beim Server
registriert hat, so dass man den offenen Router-Port und die Verbindung
benutzt, die der SIP-Client bei der Registrierung aufgebaut hat und die
durch SIP-Pings am Leben gehalten werden.

Aus Sicht der SIP-Provider ist UDP wegen der geringeren Serverlast die
erste Wahl für SIP.

Das meiste SIP-User-Equipment scheint derzeit standardmäßig SIP per
UDP zu machen.

Zum Fragmentierungsproblem bei UDP:

SIP-Messages, die größer als 1492Byte sind (MTU für PPPOE) und per
UDP transportiert werden, werden vom IP-Layer in mehrere IP-Pakete
aufgeteilt und erhalten dabei eine UDP-Fragmentierungskennung, die beim
Empfänger (z.B. dem SIP-Client) dazu dient, die IP-Pakete wieder zur
ursprünglichen SIP-Message zusammenzusetzen. 

Problematisch sind hier einige Router, die fragmentierten UDP-Traffic
als potentiellen Angriffsversuch prinzipiell verwerfen. z.B.
Draytek-Router in neueren Firmwareversionen

In der Praxis scheint es einiges SIP-Equipment zu geben, das sehr große
SIP-Messages erzeugt (z.B. ein Speedport W724V) und sie als
fragmentierten UDP-Traffic verschickt.

In der üblichen serverbasierten SIP-Telefonie laufen die Messages immer
über die SIP-Proxies der Provider.
Hier wurden Unterschiede zwischen den Providern in der Behandlung langer
SIP-Messages gefunden.

Die Telekom leitet fragmentierten UDP-Traffic an den Angerufenen als
fragmentierten UDP-Traffic weiter, wenn der Angerufene per UDP
registriert ist.
DUS.net entfernt überflüssigen Ballast aus den SIP-Messages und
verkürzt sie dadurch soweit, dass die Message, die von DUS.net an den
Angerufenen SIP-Client geschickt wird, nicht fragmentiert ist.

Der fli4l sollte im Normalfall keine Probleme mit fragmentiertem
UDP-Traffic machen, so dass fragmentierter UDP-Traffic bei SIP kein
Problem für einen SIP-Client im LAN des fli4l sein sollte.

Wer einen Router hat, der fragmentierten UDP-Traffic nicht passieren
lässt und einen Provider hat, der nichts gegen fragmentierten
UDP-Traffic unternimmt, kann nur SIP-Equipment verwenden, das sich auf
SIP per TCP konfigurieren lässt.

Ob der Vigor130 im Routermodus fragmentierten UDP-Traffic verwirft, ist
noch nicht genau heraus.
Wenn ja, dann müsste es Leute geben, von denen man nie angerufen werden
kann und wo die Anrufer immer dieses: "Bitte rufen sie den Teilnehmer zu
einem späteren Zeitpunkt wieder an" hören.

In Modekonfiguration hat der Vigor130 das Problem nicht.