SIP Clienten funktionieren nicht hinter Speedport W 723V

[#1]

Hallo,

ich verwende diverse SIP-Clienten (Siemens Gigaset S685IP, Nokia N900, Ekiga) mit verschiedenen SIP Anbietern, hauptsaechlich sipgate.de. Das ist normalerweise kein Problem.

Nur seit ich zu Hause DT "Call & Surf Comfort VSDL 25" habe und einen von der DT gemieteten "Speedport W 723V" betreibe, koennen sich meine SIP-Clienten nicht mehr bei den externen SIP-Diensten registrieren. In anderen Netzen funktionieren meine SIP-Clienten weiterhin wunderbar.

Offenbar bin ich nicht der einzige mit diesem Problem . Keiner weiss nix genaues, aber der Tenor scheint zu sein, dass
* die "Speedport W 723V" der Uebeltaeter ist und SIP auf UDP 5060 nicht reinlaesst;
* Konfigurationstricks wie Port-Forwarding von 5060, oder die Speedport als SIP-Proxy einzutragen nicht helfen;
* es keine Moeglichkeit gibt, dem Speedport das abzugewoehnen. Betrieb von SIP-Clienten ist hinter der Speedport (ohne Tricks wie VPN, oder SIP-Dienste auf anderen Ports als 5060) schlichtweg nicht moeglich;
* es mit anderen VDSL-Routern durchaus geht.

Kann das jemand bestaetigen, oder (besser noch!) widerlegen?

Danke, y


http://foren.t-online.de/foren/read/service/dsl-festnetz/speedports/speedport-500er-serie/verbindung...

http://foren.t-online.de/foren/read/service/dsl-festnetz/speedports/speedport-700er-serie/speedport-...

http://foren.t-online.de/foren/read/service/dsl-festnetz/telefonie/voip-telefonanlage-anlage-hinter-...

[#2]

Habt ihr meinen Vorschlag mit der Änderung des SIP-Ports ausprobiert?

[#3]

Du müsstest dazu schon testweise die Daten im SP eintragen ...

Welche - die der Telekom SIP-Server (da wett' ich 'nen Bier gegen dass das hilft), oder die der Sipgate SIP-Server? Ich will ja eigentlich nicht, dass die Speedport sich neben meinen eigentlichen SIP Clienten auch noch bei Sipgate registriert.

[#4]

Habt ihr meinen Vorschlag mit der Änderung des SIP-Ports ausprobiert?

Ja, schon bevor ich dieesen Thread angefangen hatte. Vergeblich.

Es bring natuerlich nix wenn ich den Clienten-Port umstelle. Die Speedport erschlaegt alle ausgehenden Pakete, die zu UDP-Port 5060 wollen, und da lauschen nunmal die externen SIP-Server drauf - ich kann ja die Sipgate-Server nicht umkonfigurieren :-)

(Ich hatte sogar allen ernstes bei Sipgate nachgefragt, ob ihre SIP-Server auch auf einem Alternativport erreichbar sind. Wie erwartet war die Antwort ein freundliches "Nein").

[#5]

Welche - die der Telekom SIP-Server

Die des Servers, zu welchem sich auch dein Telefon verbinden soll.

[#6]

Die des Servers, zu welchem sich auch dein Telefon verbinden soll.

Arrhh - d.h. ich soll meine SIP-Accounts in der Speedport konfigurieren, so dass die Speedport sich als (weiterer) SIP-Client registriert? Genau das hatte ich vermeiden wollen!

[#7]

Wie gesagt, es ist nur ein Lösungsansatz. Du kannst die Zugangsdaten nach dem Test ja wieder entfernen. Ansonsten bleibt lust bot not least: LAN-IP des Telefons in die DMZ setzen. Zwar nicht die feine Art aber bis du kein Ersatzgerät hast, immer noch besser als nicht angerufen werden zu können ^^

[#8]

"lust but not least"... ich merke es wird spät ^^

[#9]

Laut Bedienungsanleitung des W723V Typ A läuft im Router:

siproxd
GPL v2
Thomas Ries
0.5.10-72
http://siproxd.sourceforge.net/

Lest mal in der Doku vom siproxd, insbes. http://siproxd.sourceforge.net/index.php?op=faq

Das erklärt natürlich, warum der Router alle SIP-Pakete, sowohl von innen als auch von außen, abfängt.

Ich würde die SIP-Clients ganz "normal" konfigurieren (als wenn kein W723V und kein Problem vorhanden wäre) und zusätzlich den Outbound-Proxy auf speedport.ip bzw. dessen IP-Adresse setzen. STUN, TURN, ICE und sonstiges NAT-Traversal-Reraffel würde ich abschalten.

Der Gedanke, den SIP-Port in den Clients zu ändern, führt nicht zum Ziel, da siproxd den wirklich den Zielport 5060 abfängt.

Mit den Proxy- und Outbound-Proxy-Einstellungen haben ja schon einige herum probiert, aber es scheint bisher nicht wirklich zielführend gewesen zu sein. Es ist meiner Meinung nach aber der einzig gangbare (vom Konzept vorgesehene) Weg.
Die Anleitung von AVM ist nicht zur Überwindung eines Routers mit SIP-ALG/siproxd gedacht.

Der siproxd im W723V-A wird vermutlich im Outbound-Proxy-Modus konfiguriert sein. Zusätzlich implementiert der siproxd noch einen RTP-Proxy bzw. an anderer Stelle RTP-Relay genannt. Das wird dann die nächste Hürde, obwohl der ganze Konstrukt eigentlich eine Vereinfachung sein soll.

Habt ihr schon mal über eine Alternative zum Speedport nachgedacht?

Grüße
spi

[#10]

In der FRITZ!Box scheint der Outbound-Proxy nicht über die Konfigurationsoberfläche editierbar zu sein, sodass man ihn händisch ändern muss (z.B. FBEditor).
Was hinter outboundproxy_without_route_header steckt, weiß ich allerdings nicht. Würde ich erstmal auf Default-Wert "no" lassen.

[#11]

Ich würde die SIP-Clients ganz "normal" konfigurieren (als wenn kein W723V und kein Problem vorhanden wäre) und zusätzlich den Outbound-Proxy auf speedport.ip bzw. dessen IP-Adresse setzen. STUN, TURN, ICE und sonstiges NAT-Traversal-Reraffel würde ich abschalten.

Diese Lösung hatte ich ja bereits vorgeschlagen. Wobei fraglich ist, ob der SIP-Proxy auch die STUN-Funktionen übernimmt. Aber erst mal STUN deaktiviert zu lassen macht sinn. Man kann es am Telefon ja immer noch später hinzuschalten, wenn der vorherige Versuch scheitert.

Der Gedanke, den SIP-Port in den Clients zu ändern, führt nicht zum Ziel, da siproxd den wirklich den Zielport 5060 abfängt.

Dann war mein Gedankengang ja richtig.

Mit den Proxy- und Outbound-Proxy-Einstellungen haben ja schon einige herum probiert, aber es scheint bisher nicht wirklich zielführend gewesen zu sein. Es ist meiner Meinung nach aber der einzig gangbare (vom Konzept vorgesehene) Weg.
Die Anleitung von AVM ist nicht zur Überwindung eines Routers mit SIP-ALG/siproxd gedacht.

Ja, haben schon allerdings ohne Daten im SP zu hinterlegen. Ein Unkonfigurierter SP ohne Rufnummern und somit "dummen" SIP-Proxy führt natürlich nicht zum Erfolg ^^ Deshalb auch mein Vorschlag entgegen des Threaderstellers-Wunsch, die Daten im SP zu hinterlegen.

[#12]

In der FRITZ!Box scheint der Outbound-Proxy nicht über die Konfigurationsoberfläche editierbar zu sein, sodass man ihn händisch ändern muss (z.B. FBEditor).
Was hinter outboundproxy_without_route_header steckt, weiß ich allerdings nicht. Würde ich erstmal auf Default-Wert "no" lassen.

Natürlich geht das:
http://250kb.de/u/110907/j/StpRtsgo0Z8I.jpg

[#13]

In der FRITZ!Box scheint der Outbound-Proxy nicht über die Konfigurationsoberfläche editierbar zu sein, sodass man ihn händisch ändern muss (z.B. FBEditor).
Was hinter outboundproxy_without_route_header steckt, weiß ich allerdings nicht. Würde ich erstmal auf Default-Wert "no" lassen.

Natürlich geht das:
http://250kb.de/u/110907/j/StpRtsgo0Z8I.jpg
Das ist der Proxy, nicht der Outbound-Proxy.
Der Proxy muss normal konfiguriert werden, z.B. tel.t-online.de oder sipgate.de.

Den Outbound-Proxy braucht man normalerweise nie, außer jetzt in der speziellen Situation des W723V.

Grüße
spi

[#14]

Ich würde die SIP-Clients ganz "normal" konfigurieren (als wenn kein W723V und kein Problem vorhanden wäre) und zusätzlich den Outbound-Proxy auf speedport.ip bzw. dessen IP-Adresse setzen. STUN, TURN, ICE und sonstiges NAT-Traversal-Reraffel würde ich abschalten.

Diese Lösung hatte ich ja bereits vorgeschlagen. Wobei fraglich ist, ob der SIP-Proxy auch die STUN-Funktionen übernimmt. Aber erst mal STUN deaktiviert zu lassen macht sinn. Man kann es am Telefon ja immer noch später hinzuschalten, wenn der vorherige Versuch scheitert.

Der riesige Vorteil von den Lösungen, die den SIP-User-Agent im Router integriert haben, ist, dass kein NAT-Traversal erforderlich ist. Vermutlich ist es beim siproxd auch nicht anders, also STUN o.ä. kommt im Router nicht zur Anwendung. siproxd soll ermöglichen, dass auch die externen SIP-Clients kein NAT-Traversal durchzuführen brauchen. Dazu manipuliert siproxd die abgefangenen SIP-Meldungen. Zur Behandlung der Payload (Sprachübertragung) hat er einen RTP-Proxy integriert, d.h. aus SIP-Client-Sicht besteht keine Notwendigkeit, öffentliche Ports zu erkennen und NAT-Bindings aufzufrischen.

Der Gedanke, den SIP-Port in den Clients zu ändern, führt nicht zum Ziel, da siproxd den wirklich den Zielport 5060 abfängt.

Dann war mein Gedankengang ja richtig.

Ja, wobei ich das mit dem siproxd nicht wusste, bzw. noch nicht davon gelesen hatte, und nicht glauben wollte, dass der Router alle SIP-Pakete abfängt.

Ein Unkonfigurierter SP ohne Rufnummern und somit "dummen" SIP-Proxy führt natürlich nicht zum Erfolg ^^ Deshalb auch mein Vorschlag entgegen des Threaderstellers-Wunsch, die Daten im SP zu hinterlegen.

Der siproxd wird wahrscheinlich unabhängig von der SIP-Konfiguration im Speedport immer gestartet. Das Hinterlegen von Konfigurationsdaten im Speedport sollte aber keinen Einfluss auf das Funktionieren von anderen SIP-Clients haben, außer der eigentiche SIP-Proxy (z.B. von der Telekom oder Sipgate) unterstützt kein Forking (vorstellbar als Gruppenruf) bzw. hat Fehler im Forking.

[#15]

Das ist der Proxy, nicht der Outbound-Proxy.
Der Proxy muss normal konfiguriert werden, z.B. tel.t-online.de oder sipgate.de.

Nö, das ist sehr wohl der Outbound-Proxy. Was du meinst (tel.t-online.de) ist der Registrar. Ich telefoniere ja auch ohne Proxyangabe via T-Online SIP account.

Zum SIP-Proxy: Zugegeben, das macht Sinn was du sagst. Wäre auch ziemlich bescheuert, wenn der SIP-proxy, welcher ja bereits auf dem Router Verbindung zu den Schnittstellen (insbesondere WAN-Port) hat, nicht die Funktionen des NAT-traversals übernehmen würde. Das wäre so, als würde ein Apache-Server keine PHP-Parser Ausgaben über Port 80 leiten

[#16]

Das ist der Proxy, nicht der Outbound-Proxy.
Der Proxy muss normal konfiguriert werden, z.B. tel.t-online.de oder sipgate.de.

Nö, das ist sehr wohl der Outbound-Proxy. Was du meinst (tel.t-online.de) ist der Registrar. Ich telefoniere ja auch ohne Proxyangabe via T-Online SIP account.

Du hast Recht: Der Proxy-Eintrag aus der AVM-Konfigurationsoberfläche landet in der outboundproxy-Zeile in der Config-Datei - ich habe es eben ausprobiert.

Der Vorschlag, den Outbound-Proxy mit der IP-Adresse des Speedports auszufüllen und den Rest "normal" auszufüllen, bleibt aber für andere SIP-Clients als die FRITZ!Box bestehen. Dabei sind Proxy und Registrar gleich auszufüllen. In der Bedienungsanleitung des Gigaset S685 IP beispielsweise habe ich einige Erklärungen zum Outbound-Proxy gefunden.

[#17]

Ich habs leider überlesen. Ich habe ein Speedport 723 V Typ B. Ich habe gar nichts eingestellt. Trotzdem ist das Verhalten des Speedports recht ungewöhnlich. Also noch mal von vorn.

1. Client Nokia N95 konfiguriert auf Sipgate ( funktioniert fast überall sogar über Mobfu, ausser in Dubai)
2. Client Nokia N95 konfiguriert auf Sipgate über den zusätzlich aufgebauten Accespoint am Ethernet Port des Speedport funktioniert tadellos.
3. Client Nokia N95 konfiguriert auf Sipgate über den Accespoint des Speedport 723 V nur Registrierung erfolgreich. Keine Gespräche ankommend und abgehend.
4. Gigaset kofiguriert auf SIP Telekom (tel.t-online.de) funktioniert einwandfrei (Einschränkung das Telefon habe ich nur ausgeliehen und kurz getestet)
5.Jetzt kommts ! Client Nokia N95 kofiguriert SIP Telekom (tel.t-online.de) funktioniert nur sporadisch. Manchmal kommt eine Anmeldung zustande. Telefon funktioniert nur ankommend.

Ich würde den A Router wenn er nur gemietet ist auch umtauschen. Leider habe ich meinen gekauft. Aber ich werde die gepriesene Nutzung des VDSL 50 "mit jedem bliebigen Smartfon PDA usw. am Festnetz der Telekom" einfordern. Das kann ich bei dem Preis auch verlangen.
Jetzt wird wieder was neues angepriesen.

http://www.telekom.com/dtag/cms/contentblob/dt/de/1072880/blobBinary/Datenblatt_speedphone700_web_d_...

Man achte auf folgendes: Anschluss über entsprechenden Speedport (z. B. Speedport W 723V, Speedport W 921V und zertifiziert nach CAT-iq 2.0.

Wenn das funktionieren soll muß ja noch ein dickes Update für unsern Speedport W723 V kommen. (Bitte auch Videobeitrag beachten). Natürlich werde ich mir so ein Teil bestellen.Ich freu mich schon drauf mit High Quality zu telefonieren. Was ich natürlich dann auch einfordern werde. Ich gebe also die Hoffnung nicht auf das es irgendwann mal alles tadellos funktioniert. (Ist ja nur Software)

[#18]

Zusamengefasst: Dier sipproxy auf dem SP sorgt in der momentanen Konfiguration durch die aktuelle FW für massive Probleme.

Den Besitzern einer A-Version bliebe hier lediglich ein Umtausch oder die Modifikation mittels Freetz. Setzt aber einiges an Fachkenntnissen voraus. Hat jemand mal probiert, die IP des jeweiligen SIP-Client in die DMZ zu setzen?

[#19]

Freetz! mit Huawei?

DMZ mit neueren Speedports?

[#20]

Stimmt, es war der 721V der mit speed2fritz funktionierte. Da soll sich noch einer Wundern dass die Firmware der Speedports nicht ausgereift ist, wenn alle Nase lang ein neuer Chipsatz benutzt wird...

Sag bloß der 723V hat keine DMZ? Das würde dieses Gerät aus meiner Sicht als vollwertigen Router disqualifizieren...

[#21]

Ich habs leider überlesen. Ich habe ein Speedport 723 V Typ B. Ich habe gar nichts eingestellt. Trotzdem ist das Verhalten des Speedports recht ungewöhnlich. Also noch mal von vorn.

1. Client Nokia N95 konfiguriert auf Sipgate ( funktioniert fast überall sogar über Mobfu, ausser in Dubai)
2. Client Nokia N95 konfiguriert auf Sipgate über den zusätzlich aufgebauten Accespoint am Ethernet Port des Speedport funktioniert tadellos.
3. Client Nokia N95 konfiguriert auf Sipgate über den Accespoint des Speedport 723 V nur Registrierung erfolgreich. Keine Gespräche ankommend und abgehend.
4. Gigaset kofiguriert auf SIP Telekom (tel.t-online.de) funktioniert einwandfrei (Einschränkung das Telefon habe ich nur ausgeliehen und kurz getestet)
5.Jetzt kommts ! Client Nokia N95 kofiguriert SIP Telekom (tel.t-online.de) funktioniert nur sporadisch. Manchmal kommt eine Anmeldung zustande. Telefon funktioniert nur ankommend.

Ich würde den A Router wenn er nur gemietet ist auch umtauschen. Leider habe ich meinen gekauft. Aber ich werde die gepriesene Nutzung des VDSL 50 "mit jedem bliebigen Smartfon PDA usw. am Festnetz der Telekom" einfordern. Das kann ich bei dem Preis auch verlangen.
Jetzt wird wieder was neues angepriesen.

http://www.telekom.com/dtag/cms/contentblob/dt/de/1072880/blobBinary/Datenblatt_speedphone700_web_d_...

Man achte auf folgendes: Anschluss über entsprechenden Speedport (z. B. Speedport W 723V, Speedport W 921V und zertifiziert nach CAT-iq 2.0.

Wenn das funktionieren soll muß ja noch ein dickes Update für unsern Speedport W723 V kommen. (Bitte auch Videobeitrag beachten http://tv.telekom.com/index.php/video/1653/neues-speedphone-der-telekom) Natürlich werde ich mir so ein Teil bestellen.Ich freu mich schon drauf mit High Quality zu telefonieren. Was ich natürlich dann auch einfordern werde wenns nicht klappt. Ich gebe also die Hoffnung nicht auf das es irgendwann mal alles tadellos funktioniert. (Ist ja nur Software)

[#22]

Hallo,

hab leider auch den 723V Typ A und meine 7170 will nicht mehr. Mit dem 721V davor gab es gar keine Probleme. Würde die 7170 hinter einem Typ B funktionieren? Dann gehe ich der Telekom auf die Nerven und wenn nicht kommt gleich die 7390 ins Haus, da habe ich wenigsten noch ein besseres LAN dabei und alles von AVM.

Grüße

Brati

[#23]

Zusamengefasst: Dier sipproxy auf dem SP sorgt in der momentanen Konfiguration durch die aktuelle FW für massive Probleme.

Das war schon mit der allerersten FW so, wurde auch beim betatest angemerkt, hat aber keinen interessiert...

[#24]

Das war schon mit der allerersten FW so, wurde auch beim betatest angemerkt, hat aber keinen interessiert...

Da bei Speedport-Routern nur die allerwenigsten Fehler behoben wurden und werden, hat für mich keines dieser Geräte jemals den Beta-Status verlassen. Es muss jeder selbst wissen, was er einsetzt. Ich werde zukünftig keine Zeit mehr in das Thema investieren. Dieses und die Probleme, die die Telekom heutzutage überhaupt auf ihren technologischen Irrwegen erst schafft, rauben einem nur wertvolle Lebenszeit.

[#25]

Dabei wäre es so einfach, einen "Schalter" SIP-ALG Off ins Gui, das schaffen andere Hersteller z.B. NetGear auch.
Gruss
bb123

[#26]

So,

der 723V ist Geschichte jetzt läuft eine FritzBox 7360 (ist eine abgespeckte 7390). Alles VoIp Klienten dahinter funktionieren wieder, ich kann meine Geräte auch wieder aus dem eigenen Netz über DynDNS erreichen und die Einrichtung hat vielleicht 10min gedauert.

Das wars mit Speedport(...)!

Grüße

Brati

--
(...) Wortwahl vom telekom Team angepasst.