[FRAGE] Hat jemand 1&1 oder GMX mit einem Snom 190 benut

Hallo Anti-T,
vielleicht sind die Probleme beim snom190 ja die gleichen, wie beim snom360? Für Letzteres hat ledowski nämlich die nötigen Einstellungen ausgetüftelt und bei meinem 360 hat es dann damit auch geklappt.

Hier findest Du das Notwendige:
http://www.ip-phone-forum.de/forum/viewtopic.php?t=23078

Toi, toi, toi!

Meine Konfiguration für GMXstelle ich heute Abend online.

Mit Screenshots und Anmerkungen.

Test -GMX mit SNOM 190

Da ja angezweifelt wird, das mit dem SNOM190 GMX nutzbar ist, hier nun meine Konfiguration.
Diese funktioniert bei mir mit allen in meiner Signatur angegebenen VOIP-Anbietern ,auch mit GMX.


Vielleicht hilft es Euch ja.

SNOM 190 FW 3.56y
Linksys WRT54G Rev 2 FW 3.03.2de
Angaben stehen übrigens auch in meiner Signatur :wink:


Alle Einstellungen sind in den Screenshoots zu erkennen.

Re: Test -GMX mit SNOM 190

Anti-T schrieb:

Leider bekommt man bei GMX keine VoIP-Accounts, ohne zeitgleich eine VoIP-Flatrate zu nehmen

Zum Vergrößern anklicken....

Dazu gehts da weiter ===> http://www.ip-phone-forum.de/forum/viewtopic.php?t=27475

Hier weiter zum SNOM und 1 & 1

Das ist doch mal wieder eindeutig ein Router bzw. Kombination Router, SNOM-Problem. Aber nicht umsonst gibt es Router, die ausdrücklich "sip-aware" sind. Ihr könnt es glauben oder auch nicht. Ihr erwartet, dass jeder x-beliebige Router für SIP geeignet ist; das wäre schön, ist aber eben nicht der Fall. Also wendet euch an die Routerhersteller oder aber kauft euch gleich einen Router, der sip-aware ist (aber nicht nur irgendeinen eingebauten ATA hat - das bedeutet noch nicht "sip-aware").



Ich habe mit GMX kein Problem.

Ich benutze ein Snom190 mit 1&1 (Draytek 2600Router) und kann nur nach draußen telefonieren (vielleicht auch gar nicht verkehrt wenn man nicht angerufen werden kann ... - nervt aber dennoch)
Snom Hotline und 1&1 konnten mir bisher noch nicht weiterhelfen. Scheinbar ist das Snom bei 1&1 nicht wieder aufzufinden wenn ein Anruf eingeht.

Vielleicht machst du dir mal die Mühe und liest meine Signatur - bevor du alles nur in Zweifel ziehst ohne Fakten zu liefern? Und dann auch die Links dort. Ich habe keine Lust alles 10mal zu schreiben.

Außer Behauptungen scheint ja nicht viel von dir zu kommen. Und ja, ich habe hier auch ein SNOM 190 rumstehen, das auch mit Firmware 3.60a funktioniert hinter einem "sip-aware" Router, nicht aber hinter einem solchen, der es nicht ist.
Aber lesen bildet ja bekanntlich:


SIP Firewalls
When connecting a PC to the Internet, you do not want it to be accessible for everyone or vulnerable to attacks from hackers. That is especially important if you are constantly connected, for example via broadband or a fixed line. A firewall protects the PC by only allowing approved traffic and by rejecting attacks and illegal data packets.

On a local-area network (LAN), where several PCs or other equipment is connected, it is common to have private IP addresses on the LAN and a single common public IP address to the Internet. That is called NAT (Network Address Translation) and is often an integrated part of the firewall. Firewalls and NAT-routers are designed for data traffic that is initiated from the inside of the private network. If instead the data traffic is initiated from the outside, and even worse, must reach a specific user on the private network, serious problems occur. This is exactly what is happening with person-to-person communication via SIP. Therefore, it is highly important that all new firewalls and NAT routers now being installed are designed to support SIP properly and securely.

A Ticking Time Bomb?
Most firewalls installed today do not handle SIP in an adequate way. The problem occurs for all similar protocols (e.g., H.323) where a person on a private LAN is to be contacted. Ordinary firewalls are simply not designed for such data traffic. It is a common misunderstanding that well known firewalls can be configured to handle SIP traffic, but that is not the case. One problem is that the media streams (e.g., voice and video packets) are transferred over dynamically assigned UDP ports that are generally closed. Another problem is that the SIP clients inside the firewall cannot be reached by IP addresses since these most often are private and local to the LAN. It simply does not work, unless there is specific SIP support in the firewall.

The same applies to routers that are changing the address space, NATs. NAT routers are used when several users share a common Internet connection with a single IP address. Most carriers or ISPs only offer private IP addresses to their customers.

Enabling NATs and Firewalls With SIP
It is of course a fundamental problem that person-to-person communication does not reach the users on the LANs. Various methods and equipment have been suggested to solve this problem in a number of situations, but the most general one is to eliminate the problem where it occurs - in the firewall itself. Firewalls including a SIP server (with a SIP proxy and SIP registrar) that dynamically controls the firewall are currently available.

Intertex foresaw the future impact of SIP and these problems as early as in 1998 and started developing the current architecture of the Internet Gate line with this in mind. This led to the creation of a firewall and NAT with a built-in SIP proxy and SIP registrar, the most general architecture for SIP handling. The SIP proxy dynamically controls the firewall, opening and closing ports as needed. The SIP registrar keeps track of all the users inside the firewall and makes sure that the communication is directed to the correct device. Even more remarkable is that the SIP registrar in the IX66 can be used as the main SIP server for a company and can even be configured to handle registrations from the outside, making it ideal for road warrior and telecommuters. Furthermore, with the built-in proxy and registrar it is possible to handle encrypted SIP signaling, a feature not accomplished by other architectures.

A number of firewall vendors are planning to introduce models including a SIP ALG (Application Layer Gateway). These ALGs usually work at a lower level than a proxy, adjusting the data packets “on-the-fly.”. A common limitation of the ALG architecture is that it cannot handle secure, encrypted SIP signaling via TLS (Transport Layer Security). TLS is strongly recommended by Microsoft to be used with their Live Communications Server SIP enterprise solution.

SIP capable firewalls are not more expensive than ordinary firewalls and should be considered for all new installations of firewalls and NATs. If not, there is a high risk that even newly installed firewalls and NATs have to be exchanged in the near future.

Other methods proposed for SIP firewall and NAT traversal.

STUN is a method for getting SIP through existing NATs. It works through keeping holes open in the NAT by dummy traffic and having the SIP clients emulate their “looks” from the outside of the protected LAN. STUN will not work for all NATs and not for real secure firewalls, and may have some scalability and security issues. The SIP client has to implement STUN and integrate it in the SIP stack to make it work. STUN has been enhanced with TURN and now lately work is ongoing for a further addition refered to as ICE.

There are also various tunneling approaches, creating a tunnel through the firewall and then having an far ned NAT traversal solution in a central place at the “SIP operator” to cope with the separate address space of the private LANs and their individual users. Special equipment is therefore required at the SIP operator and sometimes, special equipment and software are required on the LAN or in the SIP clients. With this approach, the users get locked into a specific SIP operator. This approach can normally not handle complex configurations, such as inter-working between an operator and the Microsoft Greenwich architecture, where a local SIP server on the LAN is used. Most of these solutions are not completely scalable as a central node has to handle all SIP traffic, including the media streams.

For home users, Microsoft has suggested an extension to UPnP (Universal Plug and Play) to allow Windows to control the NAT or firewall. Several small inexpensive NATs have implemented these UPnP extensions, and thus allow SIP traversal for Windows Messenger (which is SIP based). However, it is not secure to allow every PC on the LAN to open the firewall, so UPnP is not acceptable for a proper firewall that should protect the LAN (In the Live Communication Server architecture, even Microsoft recommends that UPnP be disabled for high security). Another limitation is of course that UPnP control from Windows clients will not help other SIP products (e.g., SIP phones) traverse a NAT or firewall.

The IP telephony that is being implemented is just the beginning. SIP is the standard that allows you to communicate free of charge with everyone worldwide, using your broadband connection. Use voice, video, presence, chat, application sharing and much more! But most broadband routers (NAT-routers and firewalls) cannot handle SIP into the LAN (It may handle one IP telephone set to a certain operator, but general and reliable SIP communication requires firewalls designed for this purpose!)"

Hallo,

möchte niemand auf den Schlips treten, aber ich glaube, die Wahrheit liegt irgendwo dazwischen.

Fakt ist, dass Snom Geräte mit Routern Probleme machen, bei denen Fritzbox, Sipura & Co. ohne Probleme funktionieren. Den Fehler generell nur bei den Routern zu suchen finde ich dehalb nicht ganz objektiv. Den Snomgeräten sieht man an, dass die Hauptkundengruppe von Snom nicht User sind, die über irgend einen Router gehen, sondern Firmenkunden. Deshalb wird in dieser Richtung auch in der Zukunft nicht wirklich viel passieren.

Ich möchte in diesem Zusammenhang auf meine Beiträge in einem anderen Thread verweisen: Firmware 3.6xx und one way audio. Unabhängig von der Diskussion, ob der Router für die Fehlfunktionen zuständig ist oder nicht: Bei mir hat das Telefon mit jeder Firmware >=3.56 auch mit GMX durch die im Bezug angegebenen Einstellungsänderungen funktioniert.

Damit will ich nicht Ausführungen zu NAT/STUN in Rede stellen, lediglich darauf verweisen, dass für Anwender, die dieses Forum ratsuchend durchstöbern, eine möglicher Lösungsweg aufgezeigt wird.

Wie ich immer sage: Wer heilt hat Recht.

Groetjes :?

@Anti-T
Daß es bei Snom Probleme mit verschiedenen Software-Router-Zugangskombinationen gibt, ist unstrittig.
Falsch ist aber Deine Behauptung "es geht nicht" (wie hier schon mehrfach wiederlegt.)
Du hast noch nichts dazu geschrieben, über welchen Zugang Du ins Internet gehst. Und wenn Du Sip-Logs/Traces von Anmelde- oder Anrufversuchen hier rein stellen tätest, könnte man vielleicht ein paar Tipps geben.

Wenn da bei Deinem Internetzugang mehrfach NAT passiert, könnte das z.B. ein Problem sein. Sipgate hat für die ganze NAT-Geschichte 'ne eigene Intelligenz in den Servern, die dann die SIP-Packete anpaßt, so daß sie auch Dein Snom erreichen.

Bei 1&1/GMX gibt es noch einige andere Hürden. Z.B. errreichte mich ein Anruf eines 1&1-Teilnehmers an meinen GMX-Acount nicht (bzw. das Snom klingelte kurz und lehnte ab), weil als Empfänger nicht [email protected] gesendet wurde, sondern meineNumme@1&1.de (oder so ähnlich).

HI, ich versuche auch das Snom190 unter 1&1 zum klingeln zu bringen (raus telefonierten geht)
Das 1&1 Softphone funktioniert. Was mir dabei auffält ist:
Softphone ermiitelt eine eingen IP-Adresse am Server (10.xx irgendwas) und verwednet dazu Port 5070-5090. (alles bei CLient eingetragen)
Im Serverbereich ist Port 5060 eingetragen (wird beim Snom unter Netzwerkidentität eingetragen - ist also Cleint?)
Kann dazu jemand näheres erklären?

Gruß

Frank

@Franknstick
Welche FW verwendest Du?
1) Wenn Raustelefonieren geht (und die Kommunikation klappt) probier mal bei FW 3.60s:
Leitung x/SIP/Unterstützung für kaputte Registrar: ja
Wahrscheinlich hilft das schon und löst Dein Problem.

2) Was die Ports und dessen Bedeutung betrifft: Im Snom trägst Du als Netzwerkidentität einen SipPort ein, über den von außen Dein Telefon angesprochen wird. Dieser Port muß also von Deinem Router ans Snom weitergeleitet werden, entweder durch simples, fixes Portforwarding an die lokale IP Deines Telefons oder bei sogannten Sip-Aware-Routern mit einer mir im Detail nicht genau bekannten eigenen Intelligenz durch Analyse der Sip-Packete.
Jedenfalls sollte die Netzwerkidentität der Port sein, der von außen (von der Gegenstelle, also vom Provider oder von einem eventuell verwendeten Proxy) angesprochen wird. Und dieser Port wird in den versendeten SIP-Packeten der Gegenstelle mitgeteilt, ebenso die IP-Adresse. Letztere muß vom SIP-Telefon oder SIP-Softphone vorher ermittelt werden (z.B. mit Stun), wenn da eine 10.x.x.x nach außen geht, macht gmx (und so vermutlich auch 1&1) Probleme.
Was Dein Softphone mit Client meint, weiß ich nicht, warscheinlich sich selber. Und unklar ist auch, ob das Softphone aus Port 5070-5090 einen SIP-Port (entsprechend der "Netzwerkidentität" beim Snom) wählt oder aber als Mediaport (im Snom: "Dynamischer RTP-Port"-Bereich) verwendet oder beides.

Hallo Zusammen! Bin schon fast am verzweifeln Leute!

Ich habe den Snom190 am Fritz!Box angeschlossen. Provider ist 1&1. Habe alles so eingestellt wie es oben beschrieben ist. Leider funktioniert es dennoch nicht.

Ich kann zwar raustelefonieren, hör allerdings nichts obwohl die Gegenstelle spricht. Egal wohin ich anrufen mag.

Kann mir hier jemand helfen? Ich wäre über jede Hilfe seeeer dankbar. Die Software am Snom ist die 3.60i.

Geht Doch mit 1&1

Hallo Leute

Elmeg 290/Snom 190 mit 1&1 läuft bei mir nach stundenlangen nervtötenden Versuchen jetzt wohl einwandfrei.

Einstellung Router:
Portweiterleitung auf folgende Ports
5060-5090
3478
30000-30019
2410

Einstellung Elmeg 290 (FW 2.60x)
Leitung 1 Login:
Angezeigter Name:
Nutzerkennung: 49xxxxyyyyyy
Passwort: xxxxx
Registrar: 1und1.de
Authorisierungsname: 49xxxxyyyyyy

Leitung 1 Sip:
Outbound Proxy: sip.1und1.de
Automatisch annehmen: Aus
Langer SIP-Contact (RFC3840): An
Unterstützung für kaputte Registrar: An

Leitung 1 Nat:
ICE anbieten: An
STUN Server: stun.1und1.de:3478
Symmetrisches RTP: Aus

Erweiterte Einstellungen
Netzwerk:
DHCP: Aus
IP Adresse: freie IP vergeben
Netzmaske: norm. 255.255.255.0
IP Gateway: IP Router
DNS Server 1: IP Router (normalerweise)
NTP Timeserver: 192.53.103.103
Dynamischer RTP Port start: 30000
Dynamischer RTP Port stop: 30019
Netzwerkidentität (Port): 5070-5090

Viel Erfolg