OpenCom130 und OpenPhone 65IP

[breaker63]

Hallo,
ich versuche ein OpenPhone 65IP über einen DSL Anschluß (Homeoffice - t-com oder 1&1) an die TK-Anlage OpenCom 130 in der Firma (hinter einer Firewall an einer QSC ADSL Leitung) anzuschließen. Die Anlage funzt mit den internen Telefonen problemlos. Das IP Telefon läuft intern auch. Beim Versuch von extern über die Firewall (Laut DeTeWe Ports 9000-9200, 8100-8101 und 8200-9000 freigeschaltet) das Telefon anzumelden wird der Server gefunden aber das bootimage nicht heruntergeladen.

Was muß noch freigeschaltet/eingestellt werden, damit das sich IP Telefon über das Internet anmelden kann?

Gruß
Mark.

 

[buster01]

wie hast du den das telefon konfiguriert? normalerweiser müsste auch der tftp-port weitergeleitet werden.sollte sich das telefon registrieren, kann es immer noch sein das du einseitige verständigung hast. da die sprachdaten über rtp übertragen werden und die ports dafür zufällig gewählt werden. richtig funktioniert das nur wenn du einen router/firewall hast der so was unterstützt oder durch einen vpn-tunnel.

 

[breaker63]

wie hast du den das telefon konfiguriert?

Mit IP hinter dem Homeoffice-Router, Server-IP= Firewall-IP von der Firma (wo alle genannten Ports zur TK-Anlage umgeleitet werden.)

normalerweiser müsste auch der tftp-port weitergeleitet werden.

Laut detewe sollen die Ports 9001-9200 für tfpt sein.
Oder sind da noch andere Ports zu öffnen?

sollte sich das telefon registrieren, kann es immer noch sein das du einseitige verständigung hast. da die sprachdaten über rtp übertragen werden und die ports dafür zufällig gewählt werden. richtig funktioniert das nur wenn du einen router/firewall hast der so was unterstützt oder durch einen vpn-tunnel.

Das mit dem Tunnel haben wir ja probiert (2x Netgear VPN Firewall 50 FVS338 - und da bricht nach 10 min das Gespräch ab - äußerst ungünstig bei wichtigen Geschäftstelefonaten )
Das Telefon initialisiert sich ca 1 x pro Stunde neu - manch mal auch öfter.
Dann haben wir das Telefon in der Firma direkt ans LAN angschlossen und es funzt. Also muß unser Problem wohl an der Verbindung von außen liegen... aber dafür ist ja das IP-Telefon gerade da
Nächster Versuch war jetzt, das Telefon ohne Tunnel über Portweiterleitung an die TK-Anlage anzuschließen, um Probleme mit dem Tunne auszuschließen, aber hier scheitern wir schon beim Lades des bootimages...
Gruß
Mark.

 

[buster01]

gib noch mal den port 69 (udp) frei. das ist eigentlich der port für einen tftp-server. das telefon würde sich nur neu inizialisieren wenn die anlage für mehr als 1 min nicht erreichbar wäre (oder durch zufall dieser minuten interval gerade zu ende wäre).

ich kann dir allerdings keine großartigen hoffnungen machen, ich habe es selber ausprobiert. wenn zwischen der anlage und dem telefon ein nat router bzw. eine firewall ist, kommt es unweigerlich zu einseitigen verbindungen.

 

[breaker63]

gib noch mal den port 69 (udp) frei. das ist eigentlich der port für einen tftp-server. das telefon würde sich nur neu inizialisieren wenn die anlage für mehr als 1 min nicht erreichbar wäre (oder durch zufall dieser minuten interval gerade zu ende wäre).

Danke für den Tipp.
Ich werde das am Montag mal ausprobieren.

ich kann dir allerdings keine großartigen hoffnungen machen, ich habe es selber ausprobiert. wenn zwischen der anlage und dem telefon ein nat router bzw. eine firewall ist, kommt es unweigerlich zu einseitigen verbindungen.

Was bedeutet einseitige Verbindung?
Will die Anlage etwa auch eine Verbindung zum Telefon aufbauen?
Wenn ja, wie regeln denn öffentliche SIP Server das?

 

[buster01]

das problem ist entweder die firewall oder falls ein router eingesetzt wird eben dieser. eine telefonverbindung über tcp/ip benötigt 3 voneinander getrennte verbindung. eine für die signalisierung und jeweils eine verbindung für die sprache der beiden teilnehmer. diese ist bei ip-telefonie egal welcher art ob nun wie dein openphone 65 oder sip-telefonie immer das gleiche. nur das protokoll für die signalisierung eine unterschiedliche ist.

das ip telefon registieriert sich bei der tk-analge, hier lößt das telefon die verbindung aus und du muss deshalb den port 8100/8101 in deiner firewall freischalten. jetzt ist es zumindest möglich das auf deinem endgerät lampen leuten, das es klingelt und das du wählen kannst. jetzt müssen noch deine sprachdaten zu einem anderen teilnehmer kommen bzw. das was der andere redet bei dir an. dazu werden wiederum zwei verbindungen beötigt. einmal von deinem telefon zum anderen oder zum mediagateway und zurück. hier ist das protokoll rtp (realtime protokoll) im einsatz. die ports für die sprachübertragung werden aber zufällig gewählt. außerdem werden z.b. verbindungen zwischen 2 ip-telefonen immer direkt abgehandelt. nur wenn ein medienbruch erfolgt, d.h. du von deinem ip-telefon auf ein normels digitales endgeräte oder einen a/b teilnehmer oder eine isdn-amtsverbindung herstellt wird das mediagateway verwendet. hier kommt nun deine firewall wieder ins spielt bzw. ein nat router. die muss nun so konfiguriert werden das sie möglichst eine verbindung von einem endgerät was sie nicht kennt zu einer internen ip-adresse (telefon oder mediagatway) herstellt das die verbindugn von innen nicht angefordert hat. eine nat router kann das nicht und eine firewall sollte sowas nicht machen.

sip provider lösen dieses problem mit einem STUN-server. das sip-telefon stellt zu diesem eine verbindung her. der stun-server übergibt die ip-adresse des sendenden telefons damit das empfangende telefon eine verbindung zum sendenden herstellen kann.

 

[breaker63]

das problem ist entweder die firewall oder falls ein router eingesetzt wird eben dieser. eine telefonverbindung über tcp/ip benötigt 3 voneinander getrennte verbindung. eine für die signalisierung und jeweils eine verbindung für die sprache der beiden teilnehmer. diese ist bei ip-telefonie egal welcher art ob nun wie dein openphone 65 oder sip-telefonie immer das gleiche. nur das protokoll für die signalisierung eine unterschiedliche ist.

das ip telefon registieriert sich bei der tk-analge, hier lößt das telefon die verbindung aus und du muss deshalb den port 8100/8101 in deiner firewall freischalten. jetzt ist es zumindest möglich das auf deinem endgerät lampen leuten, das es klingelt und das du wählen kannst. jetzt müssen noch deine sprachdaten zu einem anderen teilnehmer kommen bzw. das was der andere redet bei dir an. dazu werden wiederum zwei verbindungen beötigt. einmal von deinem telefon zum anderen oder zum mediagateway und zurück. hier ist das protokoll rtp (realtime protokoll) im einsatz. die ports für die sprachübertragung werden aber zufällig gewählt. außerdem werden z.b. verbindungen zwischen 2 ip-telefonen immer direkt abgehandelt. nur wenn ein medienbruch erfolgt, d.h. du von deinem ip-telefon auf ein normels digitales endgeräte oder einen a/b teilnehmer oder eine isdn-amtsverbindung herstellt wird das mediagateway verwendet. hier kommt nun deine firewall wieder ins spielt bzw. ein nat router. die muss nun so konfiguriert werden das sie möglichst eine verbindung von einem endgerät was sie nicht kennt zu einer internen ip-adresse (telefon oder mediagatway) herstellt das die verbindugn von innen nicht angefordert hat. eine nat router kann das nicht und eine firewall sollte sowas nicht machen.

sip provider lösen dieses problem mit einem STUN-server. das sip-telefon stellt zu diesem eine verbindung her. der stun-server übergibt die ip-adresse des sendenden telefons damit das empfangende telefon eine verbindung zum sendenden herstellen kann.

Vielen Dank für die ausführliche Erklärung.
Ich schaue morgen mal, was das Öffnen aller Ports bringt...

 

[breaker63]

Das Anschließen des OpenPhone über das Internet ist wohl ein größeres Problem. Mit dem neuen Port wird das bootimage zwar geladen, auf das, was nach "Please Wait..." kommen soll, wartet man aber vergeblich...
Mal schauen, ob detewe sich noch meldet - sonst werden wir die Aktion beerdigen und uns einen anderen Telefoniezugang über IP überlegen... evtl eigenen Asteriskserver an einer Nebenstelle o.ä....

 

[buster01]

versucht doch mal zu klären warum der vpn tunnel solch ein merkwürdiges verhalten hat. mit vpn tunnel muss das funktionieren. habe die router den die aktivelle firmware hängen da noch andere geräte dran die traffic erzeugen?

 

[breaker63]

versucht doch mal zu klären warum der vpn tunnel solch ein merkwürdiges verhalten hat. mit vpn tunnel muss das funktionieren. habe die router den die aktivelle firmware hängen da noch andere geräte dran die traffic erzeugen?

Habe auch eine Mail mit dem Problem an netgear geschickt... bisher leider noch keine antwort.
Die Router sind natürlich für das ganze Netzwerk zuständig (sowohl in der Firma als auch im Homeoffice) und wir haben Traffic erzeugt ohne Ende. Mal läuft das Telefonat problemlos und irgendwann ist wieder eine Unterbrechung da. Nicht auf den Punkt nachvollziehbar - und sehr zeitaufwändig.
Im Moment hat detewe ein paar Tracelogs von uns bekommen. Mal schauen, ob die was erkennen können...

 

[buster01]

ist doch klar dann. ihr habt kein quality of service. immer wenn die bandbreite zu ende geht hast du abbrüche. was du mal versuche könntest, das openphone 65 ip hat einen kleinen switch integriert. wenn du den router an den lan anschluss des telefons und den rest des netzwerkes an den pc anschluss des telefons klemmst ob es dann noch abbrüche gibt. der switch im telefon priorisiert nämlich die voip daten.

 

[breaker63]

ist doch klar dann. ihr habt kein quality of service. immer wenn die bandbreite zu ende geht hast du abbrüche. was du mal versuche könntest, das openphone 65 ip hat einen kleinen switch integriert. wenn du den router an den lan anschluss des telefons und den rest des netzwerkes an den pc anschluss des telefons klemmst ob es dann noch abbrüche gibt. der switch im telefon priorisiert nämlich die voip daten.

Danke für den Tipp. Das haben wir jetzt mal probiert und etwas intensiver beobachtet. Dabei mußten wir feststellen, daß sich das Telefon mehrfach in einer Stunde neu initialisiert... ohne daß ein Telefonat lief oder großartig gesurft wurde.
Woran kann das denn liegen?
Wie können wir ermitteln, warum die Initialisierung einfach so startet?
Gruß
Mark.

 

[buster01]

die telefonanlage prüft normalerweiser jede minute nach ob das endgerät noch da ist. bekommt das endgerät in dieser zeit kein anfrage von der analge versucht es sich noch mal dort anzumelden.
so was deutet eigentlich immer auf eine fehlende verbindugn zu anlage hin oder auf einen fehlenden qualitiy of service.

habt ihr den die aktuelle firmware auf der anlage?

EDIT:

du kannst unter "pbx konfiguration/system/voip profil" und dann in dem entsprechenden profil den 'keep alive'-wert vielleicht auch mal noch etwas höher setzten. vielleicht so auf zwei oder drei minuten.

 

[breaker63]

die telefonanlage prüft normalerweiser jede minute nach ob das endgerät noch da ist. bekommt das endgerät in dieser zeit kein anfrage von der analge versucht es sich noch mal dort anzumelden.
so was deutet eigentlich immer auf eine fehlende verbindugn zu anlage hin oder auf einen fehlenden qualitiy of service.

habt ihr den die aktuelle firmware auf der anlage?

Revision R 1.289.10.1 detewe-modular
Release 8.06

OpenPhone 65IP 1.03.8

du kannst unter "pbx konfiguration/system/voip profil" und dann in dem entsprechenden profil den 'keep alive'-wert vielleicht auch mal noch etwas höher setzten. vielleicht so auf zwei oder drei minuten.

Das habe ich jetzt mal auf 3 min gesetzt...

 

[buster01]

das ist aber eigentlich die aktuelle version. mal sehen wie es mit 3 min funktioniert.

 

[segelfreak]

Opencom und IP Telefon

Hallo,

für die Opencom gibt es mittlerweile das Release 8.09
Lat Aussage Detewe wurden einige bugfixes im voip bereich gemacht.
auch die software für das mediagateway muß neu eingespielt werden.

Firmware
Revision
R 1.289.13.3 detewe-modular

Release
8.09

Das Netgear FVS338 unterstützt lt. Netgear QoS und sollte von daher nicht für die Unterbrechung verantwortlich sein. (Hier schon einmal Firmware gecheckt?)

Wir haben hier ein OC130 mit zwei abgesetzten ip Tels über VPN (Netgear FVS318 ohne QoS) laufen. Die ständige Neuinitialisierung kommt bei uns aber nicht vor!

Ich würde mir nocheinmal die VPN Einstellungen vornehmen. Könnte vielleicht sein, dass der Tunnel zu schnell neu ausgehandelt oder neu aufgebaut wird? Dann wäre die Antwortzeit so schlecht, dass die Neuanmeldung ausgelöste wird.

Haben hier AES-128 mit relativ kurzen Schlüssel (wg. Durchsatz). Lifetimes auf 86400 sekunden (24 Std) gesetzt.

Eine weitere Möglichkeit wäre die DSL Leitung.
Ist die ständig online? Time out? Keep alive? Eigentlich sollte durch die ständige Kommunikation des Telefons mit der Anlage ja die Leitung auch immer offen bleiben, checken würde ich es aber auf jeden Fall.
Letztenendes bleibt noch auf beiden Seiten des Tunnels ein Ethernet Trace zu machen. Nicht nur den eingebauten von der DeTeWe. (z.B. mit Wireshark)

Evtl. auch mal einen Tunnel über zwei PC's über SSH aufbauen und die ports durchrouten?

Gruß
segelfreak

 

[buster01]

Firmware
Revision
R 1.289.13.3 detewe-modular

Release
8.09

diese firmware ist definitiv noch beta. weder auf dem ftp-server noch im extranet gibt es ein neueres release als 8.06.

 

[maglore]

Steht der Tunnel auf Keep Alive?

 

[maglore]

Hallo,

für die Opencom gibt es mittlerweile das Release 8.09
Lat Aussage Detewe wurden einige bugfixes im voip bereich gemacht.
auch die software für das mediagateway muß neu eingespielt werden.

Firmware
Revision
R 1.289.13.3 detewe-modular

Release
8.09

Das Netgear FVS338 unterstützt lt. Netgear QoS und sollte von daher nicht für die Unterbrechung verantwortlich sein. (Hier schon einmal Firmware gecheckt?)

Wir haben hier ein OC130 mit zwei abgesetzten ip Tels über VPN (Netgear FVS318 ohne QoS) laufen. Die ständige Neuinitialisierung kommt bei uns aber nicht vor!

Ich würde mir nocheinmal die VPN Einstellungen vornehmen. Könnte vielleicht sein, dass der Tunnel zu schnell neu ausgehandelt oder neu aufgebaut wird? Dann wäre die Antwortzeit so schlecht, dass die Neuanmeldung ausgelöste wird.

Haben hier AES-128 mit relativ kurzen Schlüssel (wg. Durchsatz). Lifetimes auf 86400 sekunden (24 Std) gesetzt.

Eine weitere Möglichkeit wäre die DSL Leitung.
Ist die ständig online? Time out? Keep alive? Eigentlich sollte durch die ständige Kommunikation des Telefons mit der Anlage ja die Leitung auch immer offen bleiben, checken würde ich es aber auf jeden Fall.
Letztenendes bleibt noch auf beiden Seiten des Tunnels ein Ethernet Trace zu machen. Nicht nur den eingebauten von der DeTeWe. (z.B. mit Wireshark)

Evtl. auch mal einen Tunnel über zwei PC's über SSH aufbauen und die ports durchrouten?

Gruß
segelfreak

www.zyxel.de

2x Zywall 5 kaufen, sichere IP Sec Tunnel haben, funktioniert und gut.


Also ich erinnere mich, dass man bei Tunneln keine Ports durchrouten muss!?
Ich nutze es auch im Homeoffice, mit einer DSL Light Leitung (386 Kbits).
Softphone oder IP RFP. keine Probleme.

 

[blaky]

Bin auch der Meinung das der Tunnel hier die Probleme bereitet...

Habe hier einen VPN mit zwei Lancom-Routern und richtig eingestellt laufen die OP65IP tadellos seit FW 7.03


MFG
blaky