- Mitglied seit
- 30 Jun 2004
- Beiträge
- 514
- Punkte für Reaktionen
- 0
- Punkte
- 16
Hallo,
ich habe Probleme bei Telefonaten über die VOIP-Provider 1&1 und GMX, welches ich schon mal gepostet hatte. Ohne aktivierten Stun-Server ist ein Login bei 1&1 nicht möglich. Dies wird mit der Fehlermeldung "SIP/2.0 479 Please don't use private IP addresses" abgelehnt. Im Router (Lancom 1611) sind jedoch alle Ports für die IP Adresse freigegeben. Dies ist jedoch nicht nur beim Lancom der Fall, sondern auch beim Draytek und beim Netgear Router. Ein Login über einen VOIP-Adapter wie z.B. Sipura 2000 klappt jedoch ohne Probleme mit 1&1. Gebe ich den Stun-Server ein, funktioniert der Login. Leider höre ich dann den Gesprächsteilnehmer nicht, während dieser mich sehr gut versteht. Nehme ich anstatt 1&1 (bzw.GMX) Sipgate als VOIP-Provider, klappt der Login mit und ohne Stun-Server ohne Probleme auch höre ich dann meinen Gesprächspartner.
Hier die Antwort vom Support:
Einige Betreiber scheinen offenbar das Problem "NAT" noch nicht richtig ernst
zu nehmen. Wir versuchen schon seit geraumer Zeit verschiedene Betreiber von
der Notwendigkeit eines Session Border Controllers zu überzeugen (siehe z.B.
http://snom.com/download/man_snom4s_natf_en_v210.pdf, pp. 10ff), offenbar bei
Ihrem Betreiber bislang ohne Erfolg.
Wie Sie vielleicht wissen, haben wir bei älteren Versionen des Telefons auch
aktiv NAT unterstützt (STUN, UPnP). Das hat in der Praxis aber mehr Probleme
gebracht als es gelöst hat. Versuchen Sie mal die Soft-Phones mit einem
DrayTek Vigor2500 oder auch einer Linux Firewall. Diese Geräte verwenden
"symmetrical NAT" und insbesondere der DrayTek unterstützt kein UDP
Fragementation. Weitere interessante Ergebnisse unter
http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-02.txt,
http://midcom-p2p.sourceforge.net.
Die Fakten:
- NAT können wir nicht wegdiskutieren. Es ist realitätsfern wenn manche
IETF-Hoheiten empfehlen, doch einfach auf IPv6 umzusteigen (dort wird es
übrigens auch Firewalls geben).
- Wenn wir Kunden empfehlen, Änderungen am Router oder am Telefon
vorzunehmen, gehen wir im Support unter. Zwei unserer Kollegen (die sich ja
ein bischen mit dem Thema auskennen!) haben mal zwei Tage gebraucht um
rauszufinden, dass sie beim Port Forwarding einen Zahlendreher drin hatten.
Das wollen wir nicht widerholen, schon gar nicht mit möglicherweise
unerfahrenen Kunden.
- Die Hersteller von Routern werden wir nicht erziehen können. UPnP war ein
netter Versuch, aber die Implementierungen waren derart buggy, dass auch
dieser Ansatz mehr geschadet als geholfen hat. Ganz zu schweigen davon, dass
ja bereits einge Geräte im Feld sind, wo symmetrical NAT als Feature
angepriesen wird ("Stateful Inspection" etc.).
- Wir werden übrigens auch nicht die anderen Hersteller von Endgeräten
überzeugen können. Schauen Sie sich doch mal die Geräte von Cisco & Co an -
die unterstützen ebenfalls kein NAT. Microsoft Messenger unterstüzt übrigens
auch kein NAT (UPnP wurde in RTC1.2 herausgenommen, da Microsoft offenbar auch
keine guten Erfahrungen damit machen konnte!).
Wir haben teilweise mit Kunden Stunden verbracht und versucht die Telefone in
diesen Umgebungen zum Laufen zu bekommen - ohne Erfolg. Eine frustrierende
Erfahrung für den Kunden und für uns auch. Solche Erfahrungen treiben die
Kunden in die Arme von Skhype, die dieses Problem ebenfalls von anfang an
ernst genommen haben. Könnten Sie sich Skype vorstellen wo die Kunden Port
Forwarding machen müssen damit es klappt?
Wir würden uns sehr freuen, wenn Sie das Problem auch noch mal an Ihren
Betreiber weitergeben. Wenn Kunden auf das Problem hinweisen hat es eine
andere Qualität. Wenn wir mit denen reden glauben sie vielleicht wir wollen
nur sinnlose Produkte verkaufen.
Your snom support Team
______________________________________
So kann man sich auch aus seiner Verantwortung drücken ...
ich habe Probleme bei Telefonaten über die VOIP-Provider 1&1 und GMX, welches ich schon mal gepostet hatte. Ohne aktivierten Stun-Server ist ein Login bei 1&1 nicht möglich. Dies wird mit der Fehlermeldung "SIP/2.0 479 Please don't use private IP addresses" abgelehnt. Im Router (Lancom 1611) sind jedoch alle Ports für die IP Adresse freigegeben. Dies ist jedoch nicht nur beim Lancom der Fall, sondern auch beim Draytek und beim Netgear Router. Ein Login über einen VOIP-Adapter wie z.B. Sipura 2000 klappt jedoch ohne Probleme mit 1&1. Gebe ich den Stun-Server ein, funktioniert der Login. Leider höre ich dann den Gesprächsteilnehmer nicht, während dieser mich sehr gut versteht. Nehme ich anstatt 1&1 (bzw.GMX) Sipgate als VOIP-Provider, klappt der Login mit und ohne Stun-Server ohne Probleme auch höre ich dann meinen Gesprächspartner.
Hier die Antwort vom Support:
Einige Betreiber scheinen offenbar das Problem "NAT" noch nicht richtig ernst
zu nehmen. Wir versuchen schon seit geraumer Zeit verschiedene Betreiber von
der Notwendigkeit eines Session Border Controllers zu überzeugen (siehe z.B.
http://snom.com/download/man_snom4s_natf_en_v210.pdf, pp. 10ff), offenbar bei
Ihrem Betreiber bislang ohne Erfolg.
Wie Sie vielleicht wissen, haben wir bei älteren Versionen des Telefons auch
aktiv NAT unterstützt (STUN, UPnP). Das hat in der Praxis aber mehr Probleme
gebracht als es gelöst hat. Versuchen Sie mal die Soft-Phones mit einem
DrayTek Vigor2500 oder auch einer Linux Firewall. Diese Geräte verwenden
"symmetrical NAT" und insbesondere der DrayTek unterstützt kein UDP
Fragementation. Weitere interessante Ergebnisse unter
http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-02.txt,
http://midcom-p2p.sourceforge.net.
Die Fakten:
- NAT können wir nicht wegdiskutieren. Es ist realitätsfern wenn manche
IETF-Hoheiten empfehlen, doch einfach auf IPv6 umzusteigen (dort wird es
übrigens auch Firewalls geben).
- Wenn wir Kunden empfehlen, Änderungen am Router oder am Telefon
vorzunehmen, gehen wir im Support unter. Zwei unserer Kollegen (die sich ja
ein bischen mit dem Thema auskennen!) haben mal zwei Tage gebraucht um
rauszufinden, dass sie beim Port Forwarding einen Zahlendreher drin hatten.
Das wollen wir nicht widerholen, schon gar nicht mit möglicherweise
unerfahrenen Kunden.
- Die Hersteller von Routern werden wir nicht erziehen können. UPnP war ein
netter Versuch, aber die Implementierungen waren derart buggy, dass auch
dieser Ansatz mehr geschadet als geholfen hat. Ganz zu schweigen davon, dass
ja bereits einge Geräte im Feld sind, wo symmetrical NAT als Feature
angepriesen wird ("Stateful Inspection" etc.).
- Wir werden übrigens auch nicht die anderen Hersteller von Endgeräten
überzeugen können. Schauen Sie sich doch mal die Geräte von Cisco & Co an -
die unterstützen ebenfalls kein NAT. Microsoft Messenger unterstüzt übrigens
auch kein NAT (UPnP wurde in RTC1.2 herausgenommen, da Microsoft offenbar auch
keine guten Erfahrungen damit machen konnte!).
Wir haben teilweise mit Kunden Stunden verbracht und versucht die Telefone in
diesen Umgebungen zum Laufen zu bekommen - ohne Erfolg. Eine frustrierende
Erfahrung für den Kunden und für uns auch. Solche Erfahrungen treiben die
Kunden in die Arme von Skhype, die dieses Problem ebenfalls von anfang an
ernst genommen haben. Könnten Sie sich Skype vorstellen wo die Kunden Port
Forwarding machen müssen damit es klappt?
Wir würden uns sehr freuen, wenn Sie das Problem auch noch mal an Ihren
Betreiber weitergeben. Wenn Kunden auf das Problem hinweisen hat es eine
andere Qualität. Wenn wir mit denen reden glauben sie vielleicht wir wollen
nur sinnlose Produkte verkaufen.
Your snom support Team
______________________________________
So kann man sich auch aus seiner Verantwortung drücken ...
. Ich habe in der Zwischenzeit alle Firmwareversionen bis hin zur neuesten ausprobiert, immer das gleiche. 
