[GELÖST] mit FW 3.60x wird private IP nach außen gegeben

ahasver

Mitglied
Mitglied seit
11 Jun 2004
Beiträge
234
Punkte für Reaktionen
0
Punkte
16
[Herausgelöst aus diesem Thread: http://www.ippf.tk/forum/viewtopic.php?t=5749&start=26 ]

Bezüglich NAT und SIP hat sich mit 3.60i ja einiges getan.
Danke Snom, Sipgate geht damit jetzt bei mir wieder, das hier:
http://www.ippf.tk/forum/viewtopic.php?t=16399&start=12&highlight=Contact-Zeile
ist gelöst! Zumindest ohne Router direkt am Kabelmodem gehen damit alle bei mir eingerichteten Provider.

Nicht hinbekommen habe ich es bislang, die nur bei bei GMX und Bluesip auftretende einseitige Kommunikation (die Gesenseite hört mich, aber ich nicht die Gegenseite, egal ob ich anrufe oder die Gegenstelle) hinter meinem Router zu beseitigen. Der in der 3.60er Firmware-Reihe neue Providerspezifische Schalter "symetrisches NAT" (der bei mir in 3.56 global immer ein war), scheint keinen Einfluß zu haben. Hab den Eindruck, daß die RTP-Packete vom Provider an die private IP geschickt werden, da beim Router keine Pakete an nicht geforwardete Ports aufschlagen.

Auffälliger Unterschied im SIP-Protokoll ist beim Verbindungsaufbau, daß in der Message des Snoms an die Gegenstelle die Orgin-Zeile
Code:
o=root 772991934 772991934 IN IP4 MeineÖffentlicheIP
bei der mit dem Router funktionierenden Variante (3.56*) steht, beim 3.60 aber
Code:
o=root 772991934 772991934 IN IP4 PrivateIP
Irgendwie klappt das mit der STUN-verwendung noch nicht ganz (ICE-Anbieten hab ich aus)

---
EDIT von August 2005: Seit FW 3.60s ist dieses Problem für das Snom 190 behoben!
 
Ich bin heute mit meinem 190er fast verzweifelt und war überzeugt, dass es an meinem auf iptables/ip-cop basiertem Router/Firewall liegt. Auch ich habe nur eine einseitige Kommunikation teilweise hinbekommen. Und zwar mit Sipgate und 1&1. Aber wenn ich das hier lese liegt es wohl eher am Telefon selbst!!!!
Auch mit STUN ging nix und zuletzt habe ich siproxyd eingesetzt aber auch keinen Erfolg gehabt. Da ging ein ganzer Tag drauf.

Gruß

Jui
 
Interessant ist auch, dass mit einem Linksys WRT54GS DD-WRT Firmware und SNOM 190 Firmware 3.60x folgendes Szenario erscheint

SIP Leitungsstatus:
Leitung 1 Status: @web.de: OK
Leitung 2 Status: @nikotel.com: OK Authenticated
Leitung 3 Status: @sipgate.de: OK
Leitung 4 Status: @bluesip.net: OK
Leitung 5 Status: @sip-gmx.net: Please don't use private IP addresses
Leitung 6 Status: @sipsnip.com: OK
Leitung 7 Status: @sipgate.de: OK


Zwar ist man bei blueSIP angemeldet (was eigentlich erstaunlich ist, weil man es bei GMX nicht ist; aber wahrscheinlich holt sich das SNOM per DNS SRV einen STUN Server), hat aber nur einseitige Kommunikation


Was noch erstaunlicher ist: mit der selben Routerfirmware DD-WRT funktioniert dagegen alles wenn man SNOM 3.56y NAT Erkennung auf "aus" stellt. Da scheint das SNOM nicht automatisch den DNS SRV Eintrag auszuwerten und zu verwenden.
 
Nach weiteren Tests. Es ist wohl so, dass das SNOM bei blueSIP per DNS SRV einen STUN-Server findet (nicht aber bei GMX, da GMX wohl keine derartigen Einträge in der DNS SRV gemacht hat).

Die Folge ist: Das SNOM verwendet den STUN-Server bei blueSIP und kann sich damit bei blueSIP anmelden, jedoch gibt es wohl einen Fehler bei der Implementierung, so dass die Audio-Kommunikation nur in eine Richtung funktioniert.

Bei GMX dagegen erfolgt erst gar keine Anmeldung, weil kein STUN-Server dort aufgefunden wurde und das SNOM dann die private IP nach außen gibt.

Alle Testreihen mit einem Linksys WRT54GS.


Mit dem Intertex (der eben sip-aware ist) klappt es dagegen grundsätzlich (wenngleich auch die entsprechenden Ports 3478 offen sein müssen, was eigentlich nicht der Fall sein sollte).

ERGO: Wer keinen Router hat, der als Proxy- und Registrar-Server fungiert, der sollte wohl besser bei der 3.56y bleiben.
 
Die DNS SRV Einträge können noch nicht die ganze Wahrheit sein. Die Sache wird für mich immer diffuser (wobei ich mich bislang zu doof angestellt habe, mir die SRV Einträge mit dig o.ä. mal sichtbar zu machen...)
Das Snom scheint bei FW 3.60i (u.a.) immer irgendeinen Stun-Server (egal von welchenm Provider) zu suchen, und wenn einer gefunden ist, diesen auch für alle anderen Provider (bei vermeintlichen Bedarf?, gegebenenfalls auch fehlerhaft) zu verwenden und zu cachen. Und auch die Reihenfolge der Providereinträge scheint eine Rolle zu spielen.
Das Fehlverhalten hinter meinem Router ist bei BlueSip und GMX bei mir in allen getesteten Konstellationen (BlueSip ist auf der vorletzten Line, GMX auf der zweiten Line, also andersrum, als bei) gleich verkehrt: Wenn kein Stun eingetragen ist, bekomme ich "Please don't use private IP", mit Stun dann die einseitige Kommunikation.
 
Wenn man STUN braucht/möchte dann würde grds. ja auch ein STUN Server genügen. Dieser dient ja nur dazu, die WAN IP herauszufinden. Insgesamt würde ich aber zustimmen: Da scheint mir irgendein Fehler drin zu sein und der beginnt für mich dort, dass das SNOM automatisch nach einem STUN Server sucht und diesen zwingend verwendet - ob man will oder nicht.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.