[Berlin-wireless] SIP Rant

[Hendrik Scholz]

Hi,

On 06/03/2013 11:15 AM, Sven-Ola Tuecke wrote:
> muss mal eine Runde stänkern. SIP und STUN sind *DER ALLERGRÖBSTE
> HANDWERKLICHE MIST*. Welche Trottel waren das...?

IETF, nicht ITU.

> 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.

Jupp. Millennium rules waren frisch geschrieben, aber sie haben es
dennoch falsch gemacht. Aktives FTP war ja auch schon etwas her.
Andererseits muss man sagen, dass SDP in MGCP und Co schon
auf die eine oder andere Art vorhanden war. Und mit WEBRTC
werden wir das ggf. bald wieder sehen.

> NAT tut das. Dann hat irgend ein anderer $Schlauberger
> sich das STUN-Protokoll ausgedacht.

Irgendwer muss es ja machen :)

> 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.

Jein, dazu gehoert auch noch, dass die korrekten NAT bindungs
bzw. Firewallloecher offengehalten werden (STUN oder SIP keepalives).

Btw: setz dein Registrierungsinterval bei SIPgate mal auf 60 Minuten
und versuche Dich nach 55 Minuten anzurufen.

> RTP wird aufgebaut $Ermittelte-Portnummer zu
> $SIP-Provider-Portnummer. Und was passiert? Der SIP-Provider sendet an
> $Ermittelte-Portnummer.

Auf SIP oder RTP-Ebene?
Die Tatsache, dass media gateways und SBC media auf dem 'umgedrehten 
5-tuple' zurueckschicken ist ein normales Verhalten, um an NATs
vorbeizukommen.

> 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.

Jein, SIP != RTP und ein media gateway controller (MGC) hat idR eine
andere IP als die ggf. geographisch verteilten MGWs (media gateways).

Deine Problembeschreibung hoert sich eher danach an, dass Dein client
nicht korrekt (tm) funktioniert.

> 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.

Diese Module (insbesondere Cisco 'sip inspect' auf PIX+ASA) machen mehr
kaputt als heil, weil sie verhindern, dass Session Border Controller und
z.B. SIPgate sehen, ob der client hinter einem NAT ist.

> 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.

ICE funktioniert, wenn man es benutzt. Andererseits kenne ich bisher
nur ein Netzwerk in dem IPv6 ICE Kandidaten angeboten werden - und das
auch nur im core.

Ich kann Deinen rant verstehen - ich habe Jahrelang >1,000,000 parallele
Endpunkte verwalten duerfen. Grundsaetzlich kann man mit SIP und
entsprechenden extensions alles moeglich machen, aber die clients
implementieren idR einfach nicht alles.
RTCP nutzt den RTP port+1 ... auch eine Quelle unglaublicher Freude.

Aber demnaechst gibt es ja port multiplexing und sowas.

Wer Spass haben moechte, dem empfehle ich die ersten 6 Wochen der
IETF WEBRTC mailinglist - da werden alle Probleme angesprochen :)

Cheers,
  Hendrik

-- 
Hendrik Scholz <hs at 123.org>