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

[Anti-T]

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
2410

Was tut der Port 2410? Ich kann diesen nirgends in den Protokollen entdecken.

Einstellung Elmeg 290 (FW 2.60x)

Du meinst sicher 3.60x?

Also ich habe das jetzt mal alles eingestellt und kann tatsächlich abgehend telefonieren. Ich habe einen Rufton der Gegenstelle, ich werde vom Angerufenen gehört und der Angerufene wird von mir gehört. So weit so gut.

Aber: Ich bekomme kein Gesprächsende-Signal (es wird einfach absolut leise wenn der Angerufene auflegt) und ich kann nach wie vor nicht angerufen werden. Die ankommenden Verbindungen werden von der NAT des Routers schlicht und ergreifend verworfen:

13:41:23 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 85.25.107.114:32877 <- 212.227.15.197:5060
13:41:23 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 85.25.107.114:32891 <- 212.227.15.197:5060
13:41:23 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 85.25.107.114:32877 <- 212.227.15.197:5060
13:41:23 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 85.25.107.114:32891 <- 212.227.15.197:5060
13:41:25 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 85.25.107.114:32877 <- 212.227.15.197:5060
13:41:25 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 85.25.107.114:32891 <- 212.227.15.197:5060

212.227.15.197 (sip.1und1.de) versucht mein Snom auf den Ports 32877 ff. zu erreichen. Diese Ports werden von der NAT des Routers vergeben und dem STUN- oder SIP-Server so mitgeteilt. Das Snom will da aber gar nicht kommunizieren. Das Portforwarding von 32877 ff. bringt deshalb auch nichts, zumal der Router diese Ports nach Verfügbarkeit dynamisch vergibt. Auch antwortet das Snom nicht auf diese Ports.

Ein Anrufversuch auf dem Snom wird nach wenigen Sekunden mit "Ein Verbindungsaufbau war nicht möglich" beim Anrufeneden quittiert.

Das Problem scheint hier irgendwo bei den Verhandlungen zwischen Snom und 1und1 zu liegen und irgendwie muss 1&1 da was vermurksen, denn mit SIPGATE funktioniert es einwandfrei.

Makaber ist auch, dass wir zur Zeit (seit einigen Tagen) keine einzige FritzBox hinter den Routern mit 1&1 betrieben können (alle Rufnummern stehen auf "Nicht registriert"), weil 1&1 offensichtlich irgendwas an der SIP-Technik verändert hat und nicht sagt was. Siehe auch http://www.ip-phone-forum.de/showthread.php?t=93594

Und nun noch der Witz: Wenn ich deine Konfiguration verwende und im Router sämtliche Portweiterleitungen lösche geht alles genauso als wenn die Portforwardings drin sind. Ich kann also telefonieren, aber nicht angerufen werden. Einziger Unterschied: Im Snom-Display wir der Name meiner Leitung nicht angezeigt.

Theoretisch muss das ja auch so funktionieren, sonst bräuchte man keinen STUN-Server (falls ich das richtig begriffen habe).

Bei aktiven Portforwardings habe ich Kontakt vom Host 84.181.186.136:

14:06:46 DEBUG/INET: NAT: new incoming session on ifc 10001 prot 17 10.73.59.9:30010/85.25.107.114:30010 <- 84.181.186.136:7078

Weiß jemand was das für ein host ist (Name: p54B5BA88.dip0.t-ipconnect.de, also überhaupt nicht in meinem IP-Bereich)?

 

[m3Sa]

hallo,

habe die einstellungen von Berni43 übernommen.
Bin ebenfalls bei 1&1 allerdings habe ich noch ein problem:
wenn ich versuche jemanden anzurufen, dann bringt er mir die meldung:
[5]29/1/2006 15:29:52: timeout::callback: Registering with timeout of 0 ms
habe auch schon versucht an den enstellungen rumzuspielen, doch dann ging zeitweise gar nix mehr
wenn jemand versucht auf das telefon anzurufen wird beim abheben die leitung unterbrochen.

Bin für jede hilfe dankbar!

Mit freundlichen Grüßen

Carsten Peklo

 

[der_Gersthofer]

Die von SNOM empfohlenen Einstellungen finden sich hier:
http://www.snom.com/wiki/index.php/Itsp_setup

Ansonsten ist es halt doch eine Sache des Routers und der NAT-Problematik, auch wenn manche das nicht glauben wollen.

 

[Anti-T]

Ansonsten ist es halt doch eine Sache des Routers und der NAT-Problematik, auch wenn manche das nicht glauben wollen.

Warum geht es dann mit Sipgate und mit 1&1 nicht?

 

[der_Gersthofer]

Ich habs dir ja schon ein paarmal gepostet, aber für dich auch noch einmal: Weil Sipgate freie RTP Proxies einsetzt; 1&1, GMX und blueSIP nicht.

Ich habe echt keine Lust mehr auf diese sinnlosen Diskussionen. Wenn du die Links die ich dir in dem anderen Thread gepostet habe mal wenigstens in Ruhe durchlesen würdest, würdest du die Problematik verstehen. Glaubs oder glaube es nicht, aber wundere oder beschwer dich nicht, wenn es dann eben bei dir nicht geht.

 

[Anti-T]

Ich habs dir ja schon ein paarmal gepostet,

Entschuldige bitte dass ich nicht alle deiner 2070 Beiträge gelesen habe, aber das

... aber für dich auch noch einmal: Weil Sipgate freie RTP Proxies einsetzt; 1&1, GMX und blueSIP nicht.

habe ich noch nirgends gelesen. Immerhin ist es schon mal ein guter Ansatz. Also 1&1 verwendet keine freien RTP-Proxies, was aber sipgate tut. Was benutzt denn dann 1&1? STUN? Was macht dann der verwendete STUN-Server stun.1und1.de:3478 falsch, dass mich eine ankommende SIP-Sitzung nicht ereichen kann?

Wobei ich mich schon jetzt frage, was ein "freier" RTP Proxy ist.

Zusammengefasst: 1&1 nutzt kein RTP-Proxies, sipgate nutzt RTP-Proxies. Weil 1&1 also keine RTP-Proxies verwendet kann mein Snom 190 nicht hinter meinem Router funktionieren, so deine Behauptung. Nun verstehe ich aber überhaupt nicht, warum dann die FritzBoxFon hinter meinem Router funktioniert (zumindest noch bis auf die letzten 5 Tage)! Was tut die FBF anders als das Snom 190? (Nein die Frage betrifft dich nicht persönlich, ich stelle sie mal einfach nur so in den Raum)

Ich verstehe weiterhin nicht dass ich mit dem Snom 190 abgehend telefonieren kann und hierbei auch den angerufenen Teilnehmer höre und damit sein UDP-Pakete also auch bei mir reinkommen, obwohl ich keine Portforwardings im Router eingetragen habe. Egal, auf jeden Fall kommen die UDP-Pakete hier durch die NAT durch beim Snom an, sonst könnte ich den Angerufenen nicht verstehen. sip.1und1.de kennt also den richtigen Weg zu meinem genateten Snom 190.

Was verflucht noch mal ist dann aber zwei Sekunden später wieder kaputt, dass mich die UDP-Pakete, die von draußen nach drinnen ein SIP-Gespräch aufbauen wollen (hier wird von draußen angerufen), nun doch an der NAT scheitern? Eben wusste sip.1und1.de noch den Weg zum genateten Snom und dann plötzlich nicht mehr?

Glaubs oder glaube es nicht, aber wundere oder beschwer dich nicht, wenn es dann eben bei dir nicht geht.

Glaube hin, Glaube her, die Praxis unterscheidet sich offensichtlich deutlich von der Theorie und vom Glauben. Allein beim Lesen der Beiträge in diesem Thread bin ich offensichtlich nicht der Einzige Snom190/1&1-Ungläubige.

Es wäre ja schön wenn wir zusammen mal eine Lösung für alle finden könnten. Und wenn nicht wäre es schon mal okay wenn wir herausfinden, warum genau es hier und da nicht funktioniert.

 

[m3Sa]

danke der_Gersthofer funktioniert!

lief alles einwnadfrei, doch plötzlich wenn ich über sipgat telefonieren wollte hat sich mein internet verabschiedet(mein router hat einen neustart gemacht). Ist ein Teledat Router 830!
Wenn ich allerdings über 1&1 telefoniere geht alles einwandfrei!
einstellungen bei beiden Leitungen sind wie auf http://www.snom.com/wiki/index.php/Itsp_setup

was muss ich tun?

EDIT:
mitlerweile geht überhaupt nichts mehr obwohl ich an den allgemeinen einstellungen nichts verändert habe!
hab hier mal die log von einem versuch mittels 1&1 ein gespräch aufzubauen:

[8]29/1/2006 21:00:23: DNS cache_lookup: a stun.1und1.de -> 212.227.15.200
[8]29/1/2006 21:00:23: DNS cache_lookup: a stun.1und1.de -> 212.227.15.200
[8]29/1/2006 21:00:23: DNS cache_lookup: a stun.1und1.de -> 212.227.15.200
[8]29/1/2006 21:00:23: DNS cache_lookup: a stun.1und1.de -> 212.227.15.200
[8]29/1/2006 21:00:23: DNS cache_lookup: a stun.1und1.de -> 212.227.15.200
[8]29/1/2006 21:00:24: Routing to outbound proxy sip:sip.1und1.de
[8]29/1/2006 21:00:24: route_pending_packet 1000051: entry=url ? sip:sip.1und1.de
[8]29/1/2006 21:00:24: DNS cache_lookup: naptr sip.1und1.de -> 
[8]29/1/2006 21:00:24: route_pending_packet 1000051: entry=srv udp _sip._udp.sip.1und1.de
[8]29/1/2006 21:00:24: DNS cache_lookup: srv _sip._udp.sip.1und1.de -> 
[8]29/1/2006 21:00:24: route_pending_packet 1000051: entry=a udp sip.1und1.de 5060
[8]29/1/2006 21:00:24: DNS cache_lookup: a sip.1und1.de -> 212.227.15.197
[8]29/1/2006 21:00:24: route_pending_packet 1000051: entry=udp 212.227.15.197 5060
[8]29/1/2006 21:00:24: Send Packet INVITE
[5]29/1/2006 21:00:24: Dialog 8/7 going to trying
[8]29/1/2006 21:00:24: Routing to explicit plan udp 212.227.15.197 5060
[8]29/1/2006 21:00:24: route_pending_packet 1000052: entry=udp 212.227.15.197 5060
[8]29/1/2006 21:00:24: Send Packet ACK
[5]29/1/2006 21:00:24: Match challenge for user=499317105634, realm=1und1.de
[8]29/1/2006 21:00:24: Routing to explicit plan udp 212.227.15.197 5060
[8]29/1/2006 21:00:24: route_pending_packet 1000053: entry=udp 212.227.15.197 5060
[8]29/1/2006 21:00:24: Send Packet INVITE
[5]29/1/2006 21:00:24: Dialog 8/7 going to proceeding
[8]29/1/2006 21:00:30: Routing to explicit plan udp 212.227.15.197 5060
[8]29/1/2006 21:00:30: route_pending_packet 1000054: entry=udp 212.227.15.197 5060
[8]29/1/2006 21:00:30: Send Packet ACK
[5]29/1/2006 21:00:30: Dialog 8/7 going to terminated
[5]29/1/2006 21:00:30: timeout::callback: Registering with timeout of 0 ms
[5]29/1/2006 21:00:30: timeout::callback: Registering with timeout of 0 ms

Mit freundlichen Grüßen

Carsten Peklo

 

[der_Gersthofer]

@Anti-T

Du hattest aber diesen Thread gelesen (denn du hast damals ja sogar in der Diskussion gemeint, dass das alles mehr oder weniger Humbug sei):
http://www.ip-phone-forum.de/showthread.php?t=71749
und da steht alles drin.

Und dann habe ich dir gestern in einem anderen Thread von dir http://www.ip-phone-forum.de/showthread.php?t=93857 noch mal extra diesen Link gepostet:
http://www.florianmessner.com/support/themen/voip/firewall-nat-wlan/voip-nat-1.htm
und wenn man sich das dann dort mal komplett durchliest (einschließlich der Folgeseiten), dann wird einem die Problematik bzw. die Ursache des Problems klar. Insbesondere:

http://www.florianmessner.com/support/themen/voip/firewall-nat-wlan/voip-nat-1-2.htm

Auf Grundlage des OSI (Open System Interconnection) Reference Model lassen sich sieben Layer unterscheiden:

• Physical Layer (Layer 1; die "Hardware"),
• Data Link Layer (2; "Media Access Control", MAC),
• Network or Internet Layer (3; "Internet Protocol", IP),
• Transport Layer (4; "TCP"; "UDP"),
• Session Layer (5; Session Initiation Protocol, SIP; Session Description Protocol; SDP, siehe dazu unter NAT/eingehende Anrufe/RTP),
• Presentation or Syntax Layer (6; "Übersetzung" der Daten in eine Form, die Layer 7 interpretieren kann) und
• Application Layer (Layer 7; Anwendungs-"Programme", z.B. FTP oder Telnet).

Network Address Translation im engeren Sinne (siehe dazu oben unter b.) arbeitet nur im Layer 3, aber nicht in den anderen Layern, insbesondere nicht im Layer 4 aufwärts. Hauptfunktion von Layer 3 ist das Routing der Daten. Die "Übersetzung" von privater in öffentliche IP-Adresse kann also nur für Datenpakete des Layer 3 erfolgen. Datenpakete der darüber liegenden Layer sind dagegen nicht NAT-fähig.

Und dann insbesondere die verschiedenen Lösungsmöglichkeiten
http://www.florianmessner.com/support/themen/voip/firewall-nat-wlan/voip-nat-1-2.htm
und warum diese trotzdem nicht immer funktionieren.

Bei den RTP Proxies wird der RTP Audiostream über diese geleitet und nicht direkt zwischen den Endgeärten - das hilft zar, Probleme zu lösen, geht aber zu Lasten der Sprachqualität, da sämtlicher Audioverkehr über diesen Proxy laufen muss, was bei 1000en von Usern viel Datenverkehr (und damit Kostem) erzeugt. Bei zahlreichen Providern sind die kostenlos (frei) andere bieten sie gar nicht oder nur kostenpflichtig an.
http://www.florianmessner.com/support/themen/voip/firewall-nat-wlan/voip-nat-2-3.htm
http://www.florianmessner.com/support/themen/voip/firewall-nat-wlan/voip-nat-4.htm

Bei sipsnip heißt es z.B.

Es gibt aber leider auch sehr viele Konfiguration, die von diesem Standard-Protokoll nicht unterstützt werden können. In diesem Fall dürfen die Gesprächsdaten nicht direkt zwischen den Gesprächsparteien ausgetauscht werden, sondern müssen über einen dritten Computer, den "RTP Relay", geführt werden. Diesen stellen wir unter "Verbesserte Router/NAT Unterstützung" zur Verfügung

Wenn man das Ganze sicher lösen will, hat man 2 Möglichkeiten:

1) ein Router mit eingebauten SIP Registrar und Proxy Server ("sip-aware") oder
2) man muss einen Provider wählen, der kostenlose RTP Proxies (oder andere ähnliche Hilfsmittel) anbietet und dann eben Endgerät und Router entsprechend konfigurieren und hoffen, dass dann alles funktioniert.

 

[Master-Basti]

Hallo zusammen!

Bin heute auch zum ersten mal mit dieser Internettelefonie in Kontakt getreten. Habe hier nun auch das Snom190 stehen und verwende 1und1.

Raustelefonieren ist auch soweit kein Problem, allerdings weiß ich nicht, was ich einstellen muss, damit mich jemand anrufen kann. Funktioniert derzeit leider nicht. Es heißt dann immer, dass der angegeben Teilnehmer im Moment nich erreichbar ist.

Hier die SIP-Logs:

Sent to udp:212.227.15.225:5060 at 4/2/2006 15:53:07:040 (1121 bytes):

INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.178.26:5060;branch=z9hG4bK-tv39l3t8gvjb;rport
Route: <sip:212.227.15.225;ftag=8ovxsr39pc;lr=on>
Route: <sip:217.188.58.167;ftag=8ovxsr39pc;lr=on>
From: <sip:[email protected]>;tag=8ovxsr39pc
To: <sip:[email protected];user=phone>;tag=58095408
Call-ID: 3c26800be57e-95xgeh09pq3t@192-168-178-26
CSeq: 4 INVITE
Max-Forwards: 70
Contact: <sip:[email protected]:5060;line=3hh93mob>
P-Key-Flags: keys="3"
User-Agent: snom190-3.56m
Accept-Language: en
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer
Supported: timer, 100rel, replaces
Session-Expires: 3600
Content-Type: application/sdp
Content-Length: 273

v=0
o=root 2056612106 2056612108 IN IP4 192.168.178.26
s=call
c=IN IP4 192.168.178.26
t=0 0
m=audio 10010 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=alt:1 0.9 : user 9kksj== 192.168.178.26 10010
a=sendrecv



--------------------------------------------------------------------------------

Received from udp:212.227.15.225:5060 at 4/2/2006 15:53:07:190 (386 bytes):

SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 192.168.178.26:5060;branch=z9hG4bK-tv39l3t8gvjb;rport=63429;received=80.131.166.60
From: <sip:[email protected]>;tag=8ovxsr39pc
To: <sip:[email protected];user=phone>;tag=58095408
Call-ID: 3c26800be57e-95xgeh09pq3t@192-168-178-26
CSeq: 4 INVITE
Server: OpenSer (0.9.5 (i386/linux))
Content-Length: 0




--------------------------------------------------------------------------------

Received from udp:212.227.15.225:5060 at 4/2/2006 15:53:07:240 (413 bytes):

SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 192.168.178.26:5060;received=80.131.166.60;branch=z9hG4bK-tv39l3t8gvjb;rport=63429
From: <sip:[email protected]>;tag=8ovxsr39pc
To: <sip:[email protected];user=phone>;tag=58095408
Call-ID: 3c26800be57e-95xgeh09pq3t@192-168-178-26
CSeq: 4 INVITE
Contact: <sip:[email protected]:5060>
Content-Length: 0




--------------------------------------------------------------------------------

Sent to udp:212.227.15.225:5060 at 4/2/2006 15:53:07:240 (531 bytes):

ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.178.26:5060;branch=z9hG4bK-tv39l3t8gvjb;rport
Route: <sip:212.227.15.225;ftag=8ovxsr39pc;lr=on>
Route: <sip:217.188.58.167;ftag=8ovxsr39pc;lr=on>
From: <sip:[email protected]>;tag=8ovxsr39pc
To: <sip:[email protected];user=phone>;tag=58095408
Call-ID: 3c26800be57e-95xgeh09pq3t@192-168-178-26
CSeq: 4 ACK
Max-Forwards: 70
Contact: <sip:[email protected]:5060;line=3hh93mob>
Content-Length: 0

Wäre dankbar für Hilfe.

Gruß

MasterBasti

 

[der_Gersthofer]

Bitte lies doch erstmal
http://www.ip-phone-forum.de/showthread.php?t=65579
deswegen ist der Thread auch als WICHTIG markiert.

Da stehen unter anderem so Dinge wie Signatur anlegen, Firmware auf den neuesten Stand bringen usw. All diese Dinge hast du leider nicht beachtet.

 

[Master-Basti]

So, habe nun die Firware jeweils auf dem Aktuellsten Stand, sowie eine Signatur erstellt mit den nötigen Angaben!

Was mir jetzt nach diesem Update auf dem Snom-Webinterface aufgefallen ist:

 SIP Leitungsstatus: 
 Leitung 1 Status: [email protected]: Keine RFC1918-IPs erlaubt

Habe auch leider hier noch keinen Hinweis gefunden, der mich weiterbringt, weil ich diese Materie noch
nicht so verstehe!

Gruß

 

[der_Gersthofer]

Das ist das altbekannte "Please don´t use private IP addresses" Problem (Die Nachricht von dir an den Server enthielt eine interne, nicht öffentlich existierende IP-Adresse (Internal RFC1918 IP address). Daher gibt es keine Möglichkeit für den Server Audiodaten an dich zu senden.). Und dazu findet man grds. http://www.ip-phone-forum.de/showthread.php?t=71749 was aber auch schon in dem Post 4 weiter oben.

Lösungsversuch: STUN-Server versuchen, Portweiterleitung an der FBF, evtl. DMZ - wenn das alles nichts bringt entweder einen anderen Router kaufen oder das SNOM verkaufen und mit einem anderen Telefon versuchen oder aber Provider wechseln.

 

[Master-Basti]

Nun, jetzt kann ich zwar anrufen und auch angerufen werden, jedoch
kann ich mein Gegenüber nicht verstehen!!! Jedoch mein Gegenüber mich!?!?!?!

Wenn ich unsere Festnetznummer anrufe, dann funktioniert es übrigens einwandfrei!

Hat noch jemand eine Idee ?

 

[der_Gersthofer]

One Way Audio ist immer eine NAT/Firewall Geschichte. Wenn du eine SIP URI anrufst (also VoIP-Call) dann kann es natürlcih auch an der anderen Seite liegen.

Wenn es ein Anruf in das PSTN ist und du hast One Way Audio, dann ist es ein Problem an deinem Router
http://www.florianmessner.com/support/themen/voip/firewall-nat-wlan/voip-nat-1.htm
und wenn dann STUN-Server, Portweiterleitung und/oder DMZ nichts bringen, dann kannst du nur einen "sip-aware" Router einsetzen, es mit einem andern SIP-Client versuchen oder aber den Provider wechseln. Sorry, mehr Möglichkeiten hat man nicht.

 

[maxdumm]

Es funktioniert

Habe gerade ein elmeg IP 290/snom 190 (firmware 3.60x) erworben und kann bestätigen, dass Telefonie über die fritz box wlan 7050 (firmware 14.03.101) und 1&1 als Provider mit den Einstellungen von 'Berni 43' (09.01.2006) einwandfrei funktioniert.
http://www.ip-phone-forum.de/images/smilies/mobilephone.gif
hone:
Ich bin allerdings - als Laie - zunächst an der Portfreigabe gescheitert; die findet sich allerdings unter
http://faq.1und1.de/voip/11_softphone/3.html
sehr anschaulich dokumentiert. Dort sind auch die exakten freizugebenden Ports aufgezählt.
Nach der richtigen Portfreigabe war auch das von Master-Basti beschriebene Problem des 'one-way-audio' gelöst.

 

[Master-Basti]

Japp, bei mir funktioniert es jetzt GOTT sei DANK auch!

 

[FonFan]

Als Besitzer eines snom 360, mit dem 1&1 klappt, habe ich die Sache von Anfang an verfolgt. Jetzt bin ich (vorausgesetzt, das hier ist reproduzierbar) auf eine ganz bestimmte Reaktion äußerst gespannt! :mrgreen: