[fli4l] SIP - dynamische U?==?utf-8?Q?mschaltung von udp auf tcp

[Erwin Lottermann]

Hallo,

bei meinen Recherchen zu SIP bin ich auf eine mögliche Erklärung
gestoßen, warum die Signalisierung von Anrufen unzuverlässig
funktioniert, wenn man kein Portforwarding für den Port 5060 für tcp
für den SIP-Client konfiguriert hat.

SIP-Clients registrieren sich standardmäßig per udp mit Quellport 5060
beim SIP-Proxy. Auf diesem Port warten sie dann auf Anrufe.

So lange man nur einen SIP-Client im LAN hat, verwendet der fli4l beim
NAT auch Quellport 5060 für die Verbindung.
D.h. durch den Registrierungsvorgang des SIP-Clients entsteht im fli4l
ein NAT-Eintrag, der dafür sorgt, dass vom SIP-Proxy kommende
UDP-Pakete den SIP-Client erreichen.
Damit der NAT-Eintrag nicht nach 180s (Timeout des fli4l für
UDP-Verbindungen) Sendepause vom fli4l gelöscht wird, werden
regelmäßig entweder client- oder serverseitige SIP-Ping gesendet, die
dafür sorgen, dass der NAT-Eintrag im fli4l erhalten bleibt.

Nun kommt es zu der Erscheinung, dass man trotz aktivem NAT-Eintrag für
einige Anrufer erreichbar ist und für andere nicht. Bei einigen
Anrufern klappt es, wenn sie ihre Rufnummer unterdrücken bei anderen
hilft auch das nichts.

Im Router ist dabei die ganze Zeit der NAT-Eintrag aktiv.
Falls vorhanden zeigt auch das Web-Interface des SIP-Providers an, dass
der SIP-Client erfolgreich registriert und aktiv ist.

Was passiert?

Die SIP-Spezifikation sieht vor, dass SIP-Request-Messages, die auf
ihrem Zustellweg über diverse Proxies zwangsläufig immer größer
werden, weil jeder Proxy der Message seinen eigenen VIA-Header
hinzufügt, ab einer Größe von 1300 Byte per TCP zugestellt werden
müssen. D.h. der Proxy, der feststellt, dass die Request-Message diese
Größe überschreitet versucht die weitere Übertragung per TCP. 
Das hat damit zu tun, dass es ab einer gewissen Messagegröße zur
Aufteilung auf mehrere UDP-Pakete kommt und dann SIP per UDP nicht mehr
funktioniert. 
Dies passiert zwar noch nicht bei 1300 Byte, aber die Responsemessage
des SIP-Clients verlängert die Invite-Message um 200 Byte und läuft
damit Gefahr auf mehrere UDP-Pakete aufgeteilt zu werden. Damit erhält
der SIP-Proxy keine Antwort auf die Invite-Message und nach mehreren
erfolglosen Wiederholungen signalisiert er dann "nicht erreichbar" an
den Anrufer.

Versucht der SIP-Proxy eine TCP-Verbindung zu Port 5060 des fli4l
herzustellen, dann stellt er fest, dass der Port geschlossen ist, da es
für TCP keinen NAT-Eintrag gibt. Die meisten SIP-Proxies scheinen als
Fallback die Message dann trotzdem per UDP zuzustellen und pokern quasi
darauf, dass es erst möglichst spät zu einer Fragmentierung der
Message kommt. Dies erklärt, warum minimal kürzere Messages in Folge
unterdrückter Rufnummern noch funktionieren können.

Die führt zu der Schlussfolgerung, dass SIP-Clients auf Port 5060 per
UDP und TCP erreichbar sein müssen.

Da der SIP-Client hinter dem NAT-Router durch seinen
Registrierungsvorgang nur einen NAT-Eintrag für UDP erzeugt, muss
mindestens für TCP ein statisches Forwarding auf dem Router
konfiguriert werden.
Ein statisches Forwarding für UDP schadet dann aber auch nicht und kann
ggf. ein SIP-Ping ersetzen.