sipgates intelligentes NAT-traversal

[pfeffer]

Hallo!

Eine genaue Analyse des Datenverkehrs hat ein intelligentes NAT-Traversel-System von Sipgate an den Tag gebracht:
Wird eine interne IP verwendet, wie z.B. 192.168.x.x, so verwendet sipgate für den rtp-stream (audio Daten von Sipgate zum Client) nicht die 192.168.x.x und auch nicht den angegebenen UDP-Port, sondern verwendet die IP und den UDP-Port als Zieladresse für den rtp-stream, den der vom Client ausgehende rtp-Stream hat.

Auf diese Weise funktioniert das Telefonieren rausgehend hinter jedem NAT und ohne STUN-Konfiguration, solange es über das sipgate-gateway läuft. Ich weiß nicht, ob sipgate auch die Verbindung zwischen 2 sip-Clients über ihr Gateway laufen lässt. Wenn nein, dürften Festnetzgespräche problemlos hinter NAT funktionieren, während Gespräche zwischen 2 sip-Clients Probleme machen können.

Durch diesen Trick von sipgate kann allerdings ein Problem "entstehen", wenn der Client hinter NAT per STUN die öffentliche IP herausfindet, aber wegen eines symmetrischen NAT nicht den richtigen Port. Dann nämlich verhält sich sipgate dem Standard nach RFC entsprechend und verwendet die in der SIP-Nachricht angegebene IP und Port für den Audio-Stream. Da der Port wegen symmetrischem NAT falsch ist, hat man dann einseitigen Sound.

Also: Wenn es einseitigen Sound bei rausgehenden sipgate-Festnetz-Telefonaten gibt, dann alle NAT-Traversel-Mechanismen (STUN und IP-discover) im Client ausstellen. Eingehende festnetzgespräche sollten immer mit Sound in beiden Richtungen gehen.

Gruß,
Pfeffer.

 

[Gast]

Dazu kommt noch bei einseitigem Audiosignal die Markierung "Send Internal IP" auf Never zu stellen!
Dies gilt insbesondere für softphones und Hardware,die diese Einstellung haben!
Grüße von Tom

 

[pfeffer]

Hallo Opilein,

nein, bei sipgate sollte man, wenn man hinter einer (symmetrisch NATenden) Firewall sitzt, "send Internal IP" auf "always" stellen. Denn genau dann merkt sipgate, dass die IP nicht stimmen kann und der beschriebene Mechanismus zur Überwindung von NAT-Problemen setzt ein. Zumindest Festnetzverbindungen funktionieren so vollkommen problemlos mit sipgate.

Gruß,
Pfeffer.

 

[Gast]

Genau diese Einstellung geht bei uns nicht!
Wir sind hier zu siebent und mußten alle die Einstellung auf Never machen!
Wie ist das zu erklären?
Erst Gestern haben wir im Rahmen des Supports wieder 2 X-Pro per Telefon eingerichtet mit der von mir genannten Einstellung und dann erst lief es!
Das verwundert mich jetzt aber doch ein wenig!
Gruß von Tom

 

[pfeffer]

o - seltsam. Ist meine Beobachtung dann doch nicht richtig? Oder wie waren die anderen Einstellungen? - Damit es so funktioniert, wie ich meine, muss jeder sonstige NAT-Traversal-Mechanismus im Client abgeschaltet sein. Also in X-Lite: STUN aus, vorallem Auto detect IP aus, NAT Firewall IP nichts eingetragen, kein Outbound-Proxy, Do not force Firewall type. Oder einfach sipgate als Outbound-Proxy einstellen, dann verhält sich X-Lite genauso als würde STUN usw. aus sein.

Es würde mich sehr freuen, wenn Du nochmal verifizieren könntest, ob es mit diesen Einstellungen auch klappt.

Gruß,
Pfeffer.

 

[pfeffer]

Eine noch genauere Analyse hat ergeben, dass sipgates Mechanismus noch intelligenter ist. Es wird nicht auf den privaten Adressebereich (192.168.x.x oder 10.x.x.x) getestet, sondern der Mechanismus greift immer, wenn die Absender IP des SIP-Paketes nicht mit der im Contact-Header der SIP-Nachricht angegeben IP übereinstimmt (evtl. wird auch die Übereinsitmmung von Port geprüft, das habe ich noch nicht analysiert).

Damit funktioniert deren intelligente NAT-Lösung selbst dann, wenn man hinter einer NAT-Kaskade sitzt, die öffentliche IPs NATet.

also, ich bleibe bei meiner Behauptung, dass es mit sipgate immer geht, wenn der Client NICHT die öffentliche IP angibt.

Inzwischen habe ich auch probiert, ob sipgate's Mechanismus auch zwischen zwei VoIP-Teilnehmern funktioniert. Er funktioniert.

Gruß,
Pfeffer.

 

[SupaRitchie]

Lösung für FBF?

Also könnte damit auch das Problem der FBF zusammenhängen, dass mit einem sipgate-Account bei einem Gespräch nur der andere Gesprächspartner (Handy,FN) mich hört, aber ich ihn auf der FBF nicht!?
Konfig: FBF ata hinter Router (SIP-Ports 5060, 70xx freigeschaltet), Primacom Kabelanschluss
Softphones & Grandstream HT486 funktionieren mit dieser Konfig. problemlos, nur die FBF nicht. Die Box kann man aber auch nicht so umfangreich konfigurieren wie X-Lite oder den Ht 486 von wegen "IP Auto Detect", "Send Internal IP", etc.

 

[rob]

Hi,

hab ähnliche Erfahrungen gemacht. Beim Tracen konnte ich sehen, daß ein RTP (!)-Port als Source eine Verbindung auf 5060/UDP aufgemacht hat. Somit war der Socket da und über diesen Port wurden dann auch die RTP-Daten abgehandelt, d.h. der Port hat 2 Funktionalitäten in sich verbunden: die SIP-Signalisierung und die Abarbeitung der Mediadaten.
Aufgrunddessen hab ich mich gefragt, ob denn ein Stun-Server denn überhaupt nötig ist. Der Effekt ist aber scheinbar abhängig von der Implementierung.
Wieso allerdings diese Implementierung nicht bei allen dergestalt aussieht, verstehe ich nicht, weil damit die NAT-Problematik recht einfach gelöst wäre.

Rob

 

[fennek]

könntet ihr vielleicht noch einmal detailiert eure xlite einstellungen posten ich sitze hinter der uni-kassel, welche ebenfalls NAT nicht zulassen... allerdings funzt xlite mit sipgate nicht!

die uni schreibt: http://www.uni-kassel.de/hrz/netze/ghknet/wlan/faq.ghk#faq021

 

[pfeffer]

@SupaRitchie:
Ja, daran wird es liegen. Allerdings weiß ich nicht, ob es genügt, bei der Fritz!Box keinen STUN-Server einzutragen, damit sie nicht die externe IP verwendet in den SIP-Nachrichten.

@rob:
Also 5060 als RTP-Port - das ist wirklich ungewöhnlich. Bist Du Dir sicher?
Bei symmetrischem NAT kann das für Verbindungen ins normale Telefonnetz was bringen, wenn der Server, der ins Telefonnetz verbindet die gleiche IP hat wie der SIP-Proxy. Aber wenn das nicht der Fall ist - und das dürfte die Regel sein - dann bringt das gar nichts. Denn bei symmetrischem NAT wird für jede Ziel-IP-Adresse ein anderer Absender-Port verwendet, auch wenn der interne Rechner den gleichen Port (in Deinem Fall 5060) verwendet.
Die intelligente Lösung von sipgate funktioniert so: Wenn sipgate merkt, dass die Absender-IP im Header der IP-Nachricht nicht mit der Absender-IP in der SIP-Nachricht entspricht, greift ihr Mechanismus. Der Mechanismus sendet die RTP-Pakete an die IP und den Port, an dem sipgate die rtp-Pakte in umgekehrter Richtung vom Client bekommt zurück. Sipgate lauscht in diesem Fall also auf einem bestimmten Ziel-UDP-Port für die RTP-Pakete und akzeptiert sie von jeder IP und jedem Port. Die RTP-Pakete, die sipgate verschickt, werden dann an den Port und die IP gesendet, von wo sipgate die rtp-Pakte in umgekehrter Audio-richtung erhält. (Evtl. ist das ein Sicherheitsproblem, aber um das beurteilen zu können, kenne ich mich nicght gut genug mit rtp-protokoll aus). Genaugenommen sendet sipgate erstmal die rtp-Pakete an die IP und den Port, der in der SIP-Nachricht angegeben wurde. Erst wenn sipgate rtp-Pakte vom Client erhält, stellt es auf die richtige IP und den richtigen Port um.

@fennek:
siehe meine Nachrichten weiter ob in diesem Thread. Alle NAT-relevanten Einstellung für X-Lite habe ich angegeben. Melde Dich, falls es damit nicht funktioniert! - Nett wäre auch, wenn Du bestätigen könntest, dass es mit meinen Empfehlungen tatsächlich geht - mit sipgate.

Gruß,
Pfeffer.

 

[petro]

Entschuldigung Doppelpost...zu schnell geklickt.

 

[petro]

Hallo Alle und @Supa Ritchie

Ich muss sagen das mir (auch Primacomanschluss mit Thomson Kabelmodem wie Supa Ritchie) alles mit Sipgate UND Freenet mit der FBF ata wunderbar läuft. Ich kann am analogen Telefon (Mastro2030) z.B. *1# für Freenet als Internettelfonieanbieter 1 und *2# für Int.Tel.Anbieter 2 = Sipgate wählen um raus zu telefonieren. Auch eingehend ist so eingestellt bei der FBF ata alle Rufe von Allen VoIP-Anbietern rein kommen.

Heute hatte ich mal kurz ein Problem, ich konnte unter der Sipgate Rauswahl nicht direkt die 50000 und die 10000 erreichen mit der FBF ata.
Nachdem ich am SMC-Barricade-Router noch mal alles überprüft aber nichts verändert habe, gings dann aschliessend (bis jetzt) ohne Probleme.

Supa Ritchie schreib doch mal genau, bei wem (mit Primacomanschluss) die FBF ata (mit der letzten firmware 11.03.37) nicht geht. Wenn es bei mir und bei dir selbst (wie du ja zu mir sagtest) mit der FBF ata mit Primacom und Kabelmodem+Router funzt, muss es doch wo anders auch gehen oder ? Oder sind die Routereinstellungen anders usw. ?

 

[rob]

@pfeffer

ich hatte nichts von 5060/UDP als RTP-Port geschrieben, sondern von einem RTP-Port, der eine Verbindung auf 5060/UDP zur SIP-Signalisierung aufgemacht (hab mein Posting noch mal gelesen, aber so steht's auch da). Das ist auch relativ geschickt, weil Du damit automatisch auch die Verbindung für den Mediastream (RTP) offen hast.

Gruß,

Rob

 

[rob]

sorry - Doppelposting

Rob

 

[pfeffer]

@rob:
Entweder verstehe ich Dich nicht richtig, oder bei Dir scheint ein Missverständnis über die Zusammenhänge vorzuliegen. Es gibt keinen "RTP-Port als Source". Es gibt nur Portnummern. Die Portnummern sind bei rtp nicht festgelegt. Bei SIP ist die festgelegte, normale Portnummer zum Beisipiel 5060, bei http 80, aber bei rtp muss die Portnummer über ein anderes Protokoll vorher zwischen den Beteiligten ausgehandelt werden. Und genau das wird (unter anderem) von dem SIP-Protokoll erledigt.

Ach, mir fällt noch ein, woher das Missverständnis kommen könnte: Es gibt UDP und TCP-Portnummern. Da können gleiche Portnummern für unterschiedliche Sachen verwendet werden. Aber SIP und RTP laufen (normalerweise) beide über UDP.

Gruß,
Pfeffer.

 

[fennek]

@pfeffer
leider funktionieren deine Einstellungen in meinem Fall nicht... ich habe es zwar einmal geschafft ein Anruf zu bekommen, aber das war wohl eher zufall und hat danach auch nicht mehr funktioniert!
Wie gesagt ich sitze in einem Uni-Netzwerk und habe keinen Einfluss auf meine IP oder auf die Ports die geforwardet sind (sie sind mir auch nicht bekannt) Vielleicht liegt das Problem dort!!!

eine direkte absprache über Skype oder ICQ wäre mir ganz recht!!!

gruß fennek

 

[Gast]

Hallo Leute,
ich gehe davon aus,daß hier alle Windows-Systeme haben!
Habt Ihr vergessen,daß uns Microsoft freundlicherweise zusätzlich zu den ganzen Port-und NAT-Problemen 3 Sicherheitsupdates hat zukommen lassen,die die Arbeit mit softphones noch weiter erschwert!?
Sipgate könnte man ja auch ohne STUN nutzen,denn hier gibt es ja auch noch einen Outbound-Proxy,das funktionierte vorher alles einwandfrei!
Seitdem diese Sicherheitsupdates (steht hier auch im Forum!) gekommen sind,geht auch dieses nicht mehr! Bei uns jedenfalls nicht!!!
Wir mußten 2 STUN-Server eintragen,damit überhaupt was ging!
Genommen haben wir als 1.STUN den von sipsnip oder sipgate und als 2.STUN den von xten.net. Seitdem geht alles wieder perfekt!
Nun sitzen wir auch nicht an der Uni hinter ein nicht bekanntes Sicherheitssystem,was man eventuell mit "Realtunnel" umgehen kann.
Nehmt Euch vorher mal das Tool "Net -check" und prüft mal,was Euch das sagt!
Gruß von Tom