[Berlin-wireless] SIP Rant

[Sven-Ola Tuecke]

Moins,

die Fummelei an IP-Adressen und Portnummern ist ein integraler 
Bestandteil von NAT. Wenn 3 Rechner auf eine einzige öffentlichen 
IP-Adresse umgesetzt werden sollen, erkennt der NAT-Router anhand der 
Ports welcher interne Rechner welche Antwort-Datenpakete erhalten 
sollen. Beispiel: 3 interne Rechner machen gleichzeitig einen DNS-Lookup 
bei Google. Sie senden je ein Fragepaket von Port 53 nach Port 53:

192.168.1.1:53 -> 8.8.8.8:53 (IP von Freifunk?)
192.168.1.2:53 -> 8.8.8.8:53 (IP von Heise?)
192.168.1.3:53 -> 8.8.8.8:53 (IP von Wikipedia?)

kommt der NAT-Router. Und packt die öffentliche IP 1.2.3.4 'rein:

1.2.3.4:1025 -> 8.8.8.8:53 (IP von Freifunk?)
1.2.3.4:1026 -> 8.8.8.8:53 (IP von Heise?)
1.2.3.4:1027 -> 8.8.8.8:53 (IP von Wikipedia?)

der Google-DNS antwortet:

8.8.8.8:53->1.2.3.4:1025 (IP von Freifunk ist...)
8.8.8.8:53->1.2.3.4:1026 (IP von Heise ist...)
8.8.8.8:53->1.2.3.4:1027 (IP von Wikipedia ist...)

Jetzt hat der NAT-Router eine Chance, jedem internen Rechner die 
richtige Antwort zu senden.

8.8.8.8:53->192.168.1.1:53 (IP von Freifunk ist...)
8.8.8.8:53->192.168.1.2:53 (IP von Heise ist...)
8.8.8.8:53->192.168.1.3:53 (IP von Wikipedia ist...)

Wenn das DNS-Protokoll darauf bestünde "Quell-Port 53 ist 
vorgeschrieben" gäb' es ein Problem. Gibt es aber nicht. Nur der 
Zielport steht fest - da muss es schon 53 sein, wenn man eine 
DNS-Antwort haben will. Es mag Firewalls geben, die das anders sehen.

Wenn jetzt jeder der Client-Rechner bei obigen Beispiel seinen Quellport 
zufällig auswählt, dann könnte man in der Mehrzahl der Fälle diesen 
zufälligen Quellport auch extern verwenden. Aber eben nur in der 
Mehrzahl der Fälle. Und nicht immer. Eine Quell-Port-Kollisionsmechanik 
ist die allermeisten Protokolle (die sind oft älter als NAT) nicht 
eingebaut. Und darum "würfelt" ein Linux-NAT-Router den Quellport 
selber. Damit es eben nicht funktioniert, wenn es meistens funktionieren 
könnte. Eine Filosofiefrage. Man könnte es anders sehen / machen, aber 
die Kernel-Entwickler haben da so ihre Meinung ;-)

Gruppen-Auftritt der Telefonindustrie. Ein Protokoll sie alle zu 
binden...! Schöne Idee haben sie da: wenn sich die SIP-Teilnehmer direkt 
untereinander Daten austauschen, dann sind die Paketlaufzeiten kürzer. 
Jetzt hätte man das "Direktverbinden" richtig in das SIP-Einbauen 
können. So wie jedes x-beliebige Filesharing-Protokoll das auch macht. 
Haben sie aber nicht. Blödheit oder Absicht? Keine Ahnung. Jedenfalls 
ist es dummes Zeug, IP-Adressen und Portnummern in einem Protokoll zu 
verhandeln um die ausgehandelte Kombi später mal (jaja: Millisekunden 
nur) zu verwenden. Jedenfalls nicht ohne irgend ein Fallback das 
automatisch in Kraft tritt wenn der gewählte technische Ansatz mal nicht 
funktioniert. Oder wenigstens mit einer SIP-v2 wo das korrigiert ist. 
Ende vom Lied kennen wir: alle nutzen Skype. Äh - ja. Es gibt auch AIX. 
Fragt mal $Telefonindustriellen was er von so OpenDingenkirchen hält. 
Die machen lieber noch ein Protokoll... Es gäbe auch noch UPnP. Fragt 
mal einen Firmen-Firewall-Admin was er davon hält...

Warum geht jetzt SIP-ohne-STUN bei SIPGate? Weil sie "mogeln". Ohne STUN 
weiss dein Telefon nicht, dass es mit einer privaten IP-Adresse hinter 
einem NAT-Gateway ist. Das SIP-Protokoll funktioniert prima, ganz 
stinknormales Protokoll für mehrere Clients und einem zentralen Server. 
Was ja immer nicht funktioniert sind die per STUN vom Telefon 
ausgehandelten Quell-Portnummern. Was macht also SIPGate? Sie sagen dem 
Telefon: baue eine RTP-Verbindung zu *unserem* Server auf. Die 
angegebene Quellportnummer werfen sie beim Aufbau der RTP-Verbindung 
einfach weg. Und antworten auf dem verwendeten Quell-Port. Und schon 
funktionierts. Es gib eine (geringe) Gefahr, dass ausversehen zwei 
falsche Leute miteinander sprechen. Aber das ist Schwund und evt. haben 
sie bei SIPGate diese "Mogelei" auch richtig implementiert. Oder es 
funktioniert nur, bei SIP-to-POTS (Händi, Festnetz) und bei 
SIPGate-zu-SIPGate. SIPGate-zu-AndererSIPProvider? Muss man 
Ausprobieren. Oder es funktioniert nur Bedingt. Makeln, Konferenz, 
Weiterleiten, Sammelrufe, Rufumleitungen, Ansagen, MoH, usw. usw. Ob das 
alles mit der Mogelei funktioniert? Müsste man ausprobieren, aber die 
meisten sagen zunächst: "ich will doch nur telefonieren".

// Sven-Ola

Am 04.06.2013 00:02, schrieb Fischkeks:
> Abend!
>
> Ich bin kein Netzwerkspezialist, aber was spricht dagegen via WAN zu den
> SIP-Providern zu routen?
>
> Außerdem habe ich testweise die Stun-Funktion auf meinem VoIP-Adapter
> deaktiviert und den ganzen Abend telefoniert. Auch den Sipgate-Echo-Test
> mal angerufen (Tel. 10005). Läuft prima! Ob das alles langfristig
> funktioniert wird sich zeigen. Was ich noch nicht verstehe, warum es
> jetzt funktioniert. Ich Ich dachte der Stun-Server ist gerade dafür da,
> auch hinter einem NAT erreichbar zu sein. Meine VoIP-Daten müssen
> momentan durch insgesamt drei NATs. Aber gut es läuft (augenblicklich).
>
> Gruß Max