[fli4l] SIP - dynamische Umschaltung von udp auf tcp

[Torsten Kästel]

Hallo Erwin,

das klingt für mich als Laien sehr plausibel. Bei mir gibt es auch den 
Effekt, dass ich nur für manche Anrufer nicht erreichbar bin und die 
Telekom konnte keinen Fehler feststellen.

Wie sieht denn dann die konkrete Konfiguration des fli4l (Version 
3.10.x) für Deine Lösung aus?

Beste Grüße
Torsten

Am 24.05.2016 um 17:06 schrieb 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.
>


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus