[Berlin-wireless] SIP Rant

Di Jun 4 22:58:16 CEST 2013

Am 03.06.2013 11:54, schrieb Patrick:
> Hi > Ich hoffe dein frust level ist nicht uebergelaufen.
> Bei mir kamen auch schon die ersten "Beschwerden" das sip nicht mehr
geht > Vorschlag von Frithjohf: > > Ich schlage vor, einfach komplette
IP-Bereiche von typischen
> > Providern via wan zu routen. Das wären Dus.net
> > 83.125.8.0/22 pbx-network.de         46.182.250.0/25
> > 178.238.128.0/20 freevoipdeal               77.72.174.0/24 sipgate
> > 217.10.64.0/20
>
> also am vpn tunnel vorbei.
>
Ich konkretisiere: SIP hat auch über den VPN-Tunnel funktioniert (habe
nur ausgehende Gespräche getestet), jedoch war der Jitter der Verbindung
so stark, dass es kaum Freunde machte. Es erinnerte eher an eine
schlechte GSM-Verbindung mit den typischen Unterbrechungen.

Dem gegenüber kann ich feststellen, dass Patricks Kabelanbieter sein
Netz sehr gut unter Kontrolle hat. Egal was man auf der Leitung macht,
SIP geht immer Jitterfrei. Und da man zu abgegrenzten IP-Bereichen
keinen Schaden anrichten kann, lag der Vorschlag auf der Hand. Der
NAT-Problematik hingegen hilft mein Vorschlag nicht.

Gruss
Frithjof

> Gruss
>            Patrick
>
>
> Am 03.06.13 11:15, schrieb 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
>
> > _______________________________________________ Berlin mailing
> > list Berlin at berlin.freifunk.net
> > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>

-- 
Frithjof Hammer, Smetanastraße 4, 13088 Berlin, 030-30 82 43 29, 0176-96
88 23 97, Fax: 030-20 16 92 56

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20130604/872df4b6/attachment.html>