[GELÖST] Firmware 3.60x benötigt zwinged offenen Port 3478

[der_Gersthofer]

Hallo,

merküwridgerweise benötigt das SNOM mit der Firmware 3.60x zwingend einen offenen Port 3478 (von innen nach außen). Wenn dieser von der Firewall geblockt wird, dann kommt keine Verbindung zu stande - und das, obwohl ich gar keinen STUN Server konfiguriert habe (und das auch nicht brauche/will).

SNOM schrieb mir dazu

bei allen snom Produkten ist es so, daß wenn ein STUN Server in DNS SRV
eingetragen ist, dieser auch erreichbar sein muß.
Kein STUN Server ist OK, aber ein nicht-erreichbarer STUN Server nicht.

DAs verstehe ich nicht ganz: Ich habe ja nirgends einen STUN Server eingetragen, also auch nicht manuell in der DNS SRV. Was läuft also schief oder ist das wieder ein SNoM Fehler in der Programmierung?

 

[Maik]

Ich nehme mal an, dass bei deinem Provider im DNS ein STUN-Server eingetragen ist und das Telefon will den dann halt verwenden. Der Server sollte dann auch im DNS-Cache angezeigt werden (sowas wie _stun._udp.sipgate.de).

Ist natuerlich nicht so toll, dass man die STUN-Abfrage nicht einfach deaktivieren kann, aber in 97% aller Faelle sollte das halt keine Probleme machen. Die restlichen 3% muessen sich dann wohl erst mal was einfallen lassen.

 

[der_Gersthofer]

Im SNOM Menü (DNS Cache) findet sich


Id Type Address Content Expires
149 srv _sip._udp.northamerica.sipphone.com 3559
148 srv _sip._tcp.northamerica.sipphone.com 3559
147 srv _sips._tcp.northamerica.sipphone.com 3559
146 naptr northamerica.sipphone.com 3559
145 srv _sip._udp.calamar0.nikotel.com 1749
144 srv _sip._tcp.calamar0.nikotel.com 1749
143 srv _sips._tcp.calamar0.nikotel.com 1749
142 naptr calamar0.nikotel.com 1749
137 srv _sip._tcp.bluesip.net 3535
136 srv _sips._tcp.bluesip.net 3535
135 naptr bluesip.net 3535
134 srv _sip._tcp.sip-gmx.net 3534
133 srv _sips._tcp.sip-gmx.net 3534
132 naptr sip-gmx.net 3534
85 a northamerica.sipphone.com 198.65.166.131 66547
75 a stun.bluesip.net 217.74.179.29 43473
74 srv _stun._udp.bluesip.net 0 0 stun.bluesip.net 3478 43473
65 a bluesip.net 217.74.179.29 60408
61 cname sip.sip-gmx.net sip-gmx.schlund.de 59456
57 a calamar0.nikotel.com 63.214.186.6 59138
56 a sip-gmx.net 212.227.15.196 59335
25 cname proxy01.sipphone.com northamerica.sipphone.com 50331
21 a sip-gmx.schlund.de 212.227.15.196 22088
16 srv _sip._udp.sip-gmx.net 0 0 sip.sip-gmx.net 5060 10952
15 srv _sip._udp.bluesip.net 0 0 bluesip.net 5060 46332



In den meisten Fällen (die, die auf STUN sowieso angewiesen sind) ist das wohl kein Prolem, nur, wenn man keinen STUN braucht, ja, diesen zwingend deaktivieren muss, dann ist das natürlich mehr als blöd. Weshalb das SNOM das abfragt wenn man eh keinen STUN-Server in der Leitung eingetragen hat, erschließt sich mir nicht. In meinen Augen ist das ein Programmierfehler.

 

[der_Gersthofer]

Ich hatte mich unklar ausgedrückt: wenn ein STUN Server per DNS SRV
eingetragen ist, erwartet der snom SIP stack, daß dieser STUN Server auch erreichbar ist.

Ich nehme an, dass genau das das Problem bei vielen ist, die mit der Firmware 3.60x Probleme haben (und die in der 3.56 NAT Erkennung auf "aus" haben).


Ich trage genau deshalb keinen STUN Server ein, damit das SNOM auch nicht erwartet, dass ein STUN Server erreichbar ist, egal ob über DNS SRV, direkt von mir eingegeben oder sonst irgendwie. Die meisten Provider werden auf ihrer Seite einen solchen Eintrag haben (was für die meisten User ja auch ganz praktisch ist, da der STUN Server so automatisch gefunden wird; ich weiß noch vor rund 6 Monaten wurden die PRovider gebeten, einen solchen Eintrag zu machen, damit das SNOM den STUN Server automatisch auffinden kann). Nur: In meinem Fall (sowie in allen anderen Fällen in denen ein sip-aware Router eingesetzt wird) *muss* STUN komplett deaktiviert sein.

Das SNOM erwartet, wie Sie schreiben, die Erreichbarkeit eines STUN Servers. Warum? Weil wohl eine entsprechende Programmierung vorliegt. Bis zur Firmware 3.60a (oder auch bei 3.56y mit NAT Erkennung auf "aus") trat dieses Problem für mich nicht auf.

Alles worum ich Sie also bitte ist, einen entsprechenden Schalter zu programmieren, dass dieses SNOM "Feature" optional ist (und ich es dann auf "aus" stellen kann. Wenn ich zwingend keinen STUN Server will bzw. brauche, dann sollte das SNOM einen solchen auch nicht aus dem DNS SRV-Eintrag des Providers ziehen.

 

[jui]

Gibt es da was neues?
Ich bin heute daran verzweifelt hinter einer auf IP-COP aufgebauten Firewall ein snom190 mit 3.60d-Firmware in Betreib zu nehmen. Ich konnte mit dem externen SIP-Provider registrieren, auch bestimmte Rufnummern (komischerweise nur Mobiltelefone) anwählen, hatte aber dann nur in eine Richtung Sprache (Das Handy hat geklingelt, das SNOM hat das Klingeln nicht signalisiert, das Handy hat alles gehört, am SNOM herrschte Stille. eigentlich ein klassisches NAT-Problem, aber meine Weiterleitungen waren alle sauber hinterlegt ... dann habe ich euren Thread und einen anderen gefunden. STUN hatte ich auch verwendet, aber auch mal rausgelassen ... half alles nix. Selbst der Einsatz von siproxyd auf der Firewall hat bisher nichts gebracht!

Vielleicht gibt es ja was neues? Insbesondere wie man für 1&1 und SIPGATE die SNOMS mit FW 3.60x korrekt einridchtet wäre mal interessant.

Viele Grüße,

Jui

 

[der_Gersthofer]

Nein, beim SNOM 190 kann man auf die Firmware 3.56y zurückgehen mit NAT Erkennung auf "aus". Beim 360er bleibt dir nur, bei SNOM ein Ticket aufzumachen, damit die sehen, wie viele Leute von diesem Problem betrofen sind.

Ich verstehe es wirklich nicht, warum das SNOM per DNS SRV abfragt, ob es einen STUN Server gibt. Das konterkariert doch die Einstellung, wenn man gerade keinen STUN Server eingetragen hat.

Das kommt mir so vor wie: User: "Ich will keinen STUN Server, brauche auch keinen" SNOM:" Ich weiss es besser, schauen wir mal, ob es nicht doch einen STUN Server gibt".

 

[jui]

Aber ich habe ja versucht STUN zu verwenden, da 1&1 und Sipgate ja beide auch STUN-Server bieten und man die schön eintragen kann. Aber trotz dieser STUN-Server und eines Port-Forwarding zum Telefon habe ich nur Sprache in einer Richtung gehabt. Ich weiss nicht ob der Fehler an meiner auf IP-Cop basierten Firewall liegt und hier einfach Probleme mit SIP von iptables her sind, oder ob das Problem nun die Firmware ist. Das macht die Fehlersuche nicht leichter :-(

Gruß,

Jui

 

[snomy]

Ich verstehe es wirklich nicht, warum das SNOM per DNS SRV abfragt, ob es einen STUN Server gibt. Das konterkariert doch die Einstellung, wenn man gerade keinen STUN Server eingetragen hat.

Das kommt mir so vor wie: User: "Ich will keinen STUN Server, brauche auch keinen" SNOM:" Ich weiss es besser, schauen wir mal, ob es nicht doch einen STUN Server gibt".

Tatsächlich war geplant und in der 3.60er Reihe auch umgesetzt, daß sich kein STUN Server mehr von Hand eintragen läßt, sondern nur automatisch gefunden wird, falls vorhanden. Wir haben es auf Kundenwunsch wieder rein genommen, allerdings mit dem Kommentar, daß wir dafür keinen Support mehr übernehmen. STUN löst das NAT Problem aus technischer Sicht leider nicht zu 100% und dann sitzen die User eben wieder da und wundern sich (guckt hier doch mal rum, wie oft jemand über 1 way Audio klagt!). Die 100% Lösung ist ein Session Border Controller beim Provider, das würde allen (User, Provider, snom) helfen !

 

[snomy]

Aber ich habe ja versucht STUN zu verwenden, da 1&1 und Sipgate ja beide auch STUN-Server bieten und man die schön eintragen kann. Aber trotz dieser STUN-Server und eines Port-Forwarding zum Telefon habe ich nur Sprache in einer Richtung gehabt. Ich weiss nicht ob der Fehler an meiner auf IP-Cop basierten Firewall liegt und hier einfach Probleme mit SIP von iptables her sind, oder ob das Problem nun die Firmware ist. Das macht die Fehlersuche nicht leichter :-(

Hier haben wir genau das Problem, das sich durch STUN nicht lösen läßt: Symmetrical NAT bedingt durch die Linux Firewall, willkommen im Club. Du brauchst einen Provider mit SBC!

 

[der_Gersthofer]

Tatsächlich war geplant und in der 3.60er Reihe auch umgesetzt, daß sich kein STUN Server mehr von Hand eintragen läßt, sondern nur automatisch gefunden wird, falls vorhanden.

Und genau das macht Probleme. Ich will und brauche keine automatische Auffindung. Wie kann ich das abstellen?

Ich finde das auch eine nicht nachvollziehbare Haltung: auf der einen Seite zu sagen, dass STUN nur Probleme macht (da stimme ich auch zu, weshalb ich mir einen nicht billigen "sip-aware" Router gekauft habe, welche von einem Mitglied des Vorstands und GRünder der SNOM Technology AG noch vor einiger Zeit ausdrücklich empfohlen wurden um reibungslose VoIP-Kommunikation zu ermöglichen (damals noch zum IX66)),

Daher wird kein Weg daran vorbeiführen, das NAT-Gateway "SIP-aware" zu machen. Entsprechende Produkte sind bereits verfügbar (zum Beispiel von Intertex, www.intertex.se).

http://66.102.9.104/search?q=cache:331MYky2en4J:[url]www.lanline.de/O/148/Y/82692/VI/2429545/default.aspx+sip-aware+SNOM&hl=de&lr=lang_de&client=firefox-a[/url]

auf der anderen Seite aber das automatische Auffinden überhaupt zu ermöglichen und diesen dann auch automatisch zu verwenden (bzw. verwenden zu wollen).

Es muss doch dem Kunden möglich sein, zu sagen: Ich brauche kein STUN, ich will kein STUN und ich darf kein STUN verwenden (wie in meinem Fall) - egal ob manuell oder automatisch.
Was bringt es, wenn manuell keiner eingegeben wird, das SNOM aber einen solchen automatisch sucht (und vor ca. 9 Monaten wurden viele Provider darum gebeten, einen entsprechenden Eintrag zu machen, um dem SNOM das automatische Auffinden zu ermöglichen) und dann verwendet.

PS: Ich habe es bislang nicht geschafft, einen LinksysWRT54GS mit einem SNOM Firmware3.60x ordentlich zum Laufen zu bringen (einseitige Kommunikation etc.). Mit 3.56y und NAT Erkennung au "aus" funktioniert es dagegen. Das ist mit einem SNOM360 aber nicht möglich. Nun bin ich auch nicht der Einzige, der das trotz einiger Erfahrung und Pioniergeist nicht hinbekommt. Aus meiner Sicht liegt das an dem automatischen Auffinden von STUN-Servern. Ist es wirklich so schwierig oder zu viel verlangt, einen entsprechenden Schalter zu programmieren: "Auomatisches Auffinden von STUN Servern per DNS SRV: an/aus"?

 

[der_Gersthofer]

Problem ist mit neuester Firmware (wohl seit 3.60k) gelöst.