[Berlin-wireless] SIP Rant

[Sven-Ola Tuecke]

Hey,

muss mal eine Runde stänkern. SIP und STUN sind *DER ALLERGRÖBSTE 
HANDWERKLICHE MIST*. Welche Trottel waren das...?

Hintergund: auf dem VPN03-Server sind ja mittlerweile $Leute drauf. Die 
wollen natürlich auch mal telefonieren. Wenn man kein Skype mag: dann 
möchte man SIP. Aber SIP hat von Haus aus ein Problem mit NAT 
(phänotypisch: eingehendes Audio funktioniert nicht). Gab es damals wohl 
noch nicht. Immer dasselbe. Was? Nun, weil die meisten Gateways auf 
Linux basieren und Linux nun mal Symmetric-NAT macht. Da werden die 
Quell-Port-Nummern bei jeder neuen Verbindung am NAT-Gateway neu 
ausgewürfelt. War schon immer so, wird auch so bleiben, geht nicht weg 
(jedenfalls in den letzten 20 Jahren nicht).

Nun war der Trottel, das das mit dem SIP verbrochen hat , der Meinung es 
müssten unbedingt IP-Adressen und vor allen Dingen Port-Nummern im 
SIP-Protokoll möglichst tief versteckt mit übertragen werden. Das geht 
natürlich schief wenn da irgendwas an IP-Adressen und Portnummern 
herumschraubt. NAT tut das. Dann hat irgend ein anderer $Schlauberger 
sich das STUN-Protokoll ausgedacht. Damit ermittelt ein Telefon, welche 
externe IP-Adresse es hat. Allerdings auch (schlimmer) welche 
Quell-Port-Nummer es für den Audio-Stream verwenden soll. Das Telefon 
fragt also irgendeinen STUN-Server, bekommt eine valide externe 
IP-Adresse und *IRGENDEINE* Portnummer. Mit der Info soll jetzt 
telefoniert werden. RTP wird aufgebaut $Ermittelte-Portnummer zu 
$SIP-Provider-Portnummer. Und was passiert? Der SIP-Provider sendet an 
$Ermittelte-Portnummer. Und das funktioniert dann nicht, weil die 
RTP-Session ein ganz anderer Server als der STUN-Server ist und weil 
sowieso die Quell-Portnummer am Linux-NAT für *jede neue* UDP-Verbindung 
neu ausgewürfelt wird. Kurz: die hereinkommenden RTP-Pakete purzeln nach 
/dev/null weil das Gateway einfach nicht weiss, wo die hin sollen.

Kommt ein weiterer Schlauberger. Und implementiert ein 
NAT-Helper-Kernel-Modul für Linux. Nennt sich SIP-ALG. Noch etwas, was 
an Ports und IP-Adressen herumschraubselt. Toll: auf dem VPN03-Gateway 
gibt es nun mal 64 IP-Adressen und nicht eine. Das blöde Modul bekommt 
das aber nicht mit, haut also die falsche IP-Adresse in die SIP-Pakete. 
Folge: nix geht. Irgendwelche Kernelmodule-Ladeparameter? Ja - aber nix 
mit IPs. Das kann ja heiter werden.

Jetzt kommt der nächste Schlauberger. Der denkt sich: na gut, wenn das 
Telefon sich mit einer privaten IP (192.168.x.x oder 10.x.x.x) meldet 
schalte ich den ganzen Krams aus und mach' es richtig. Geht so bei 
SipGate, aber sicher nicht bei allen SIP-Providern. Immerhin: das 
funktioniert. Wenn das Telefon keine 104er hat. Die 104er haben wir und 
geklaut und die sind von SipGate aus nicht als Private-IP zu erkennen. 
Grmbl. Gilt auch auch für andere "geklaute" IP-Bereiche, z.B. für die 
IPs von US-Miltär / US-Grokos / USblabla.

Auftritt des allerletzten (hoffentlich) Schlaubergers. ICE soll es jetzt 
richten. Eines Tages guck ich mir das bestimmt mal an. Hoffentlich nicht 
wieder so ein Mist.

Gruß an Wireshark für die wirklich hilfreichen Telefonie-Tools 
(speziell: Telefonie->VoIP). Nur das mit den Würfelquellports, da fehlt 
was - da muss man erst in SIP/Invite bzw. SIP/OK in den Message-Body, 
darin das SDP, dann das Media-Description aufklappen um erst dann die 
Portnummer angucken zu können. Da geht noch was.

Kurzfassung: STUN ausschalten und 192.168er für Telefon verwenden.

Achso. Die diversen Proxydinger hab' ich jetzt noch nicht durch. Ich 
nehme an die funktionieren auch nicht.

// Sven-Ola