[Berlin-wireless] SIP Rant
Sven-Ola Tuecke
sven-ola
Di Jun 4 08:40:48 CEST 2013
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
Mehr Informationen über die Mailingliste Berlin