.titleBar { margin-bottom: 5px!important; }

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

Dieses Thema im Forum "snom" wurde erstellt von ahasver, 15 Mai 2005.

  1. ahasver

    ahasver Mitglied

    Registriert seit:
    11 Juni 2004
    Beiträge:
    230
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    München
    [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!
     
  2. der_Gersthofer

    der_Gersthofer Admin-Team

    Registriert seit:
    17 Apr. 2004
    Beiträge:
    3,585
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
  3. jui

    jui Mitglied

    Registriert seit:
    18 Dez. 2004
    Beiträge:
    229
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  4. der_Gersthofer

    der_Gersthofer Admin-Team

    Registriert seit:
    17 Apr. 2004
    Beiträge:
    3,585
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    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.
     
  5. der_Gersthofer

    der_Gersthofer Admin-Team

    Registriert seit:
    17 Apr. 2004
    Beiträge:
    3,585
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    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.
     
  6. ahasver

    ahasver Mitglied

    Registriert seit:
    11 Juni 2004
    Beiträge:
    230
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    München
    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.
     
  7. der_Gersthofer

    der_Gersthofer Admin-Team

    Registriert seit:
    17 Apr. 2004
    Beiträge:
    3,585
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    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.