[Gelöst] Problem: 75 IPC funktoniert nicht, 75 IP funktioniert im VPN an OCX320

[Balogh]

Hallo zusammen

Seit Tagen zerbreche ich mir den Kopf, wieso ein 75 IPC an einem abgesetzten Standort nicht richtig funktioniert, dagegen aber ein 75 IP am gleichen Standort perfekt funktioniert.

Standort A
VPN-Router: ZyXEL ZyWALL USG 100 (Fw 2.12)
OCX320 (Fw 9.01, R 1.379.2) + MGW M-100

Standort B
VPN-Router: ZyXEL ZyWALL USG 100 (Fw 2.12)
OP 75 IP (lokale Konfiguration)
OP 75 IPC (Version 1073 bzw. automatischer Update auf neuesten Release)

Am Standort B sind Telefongespräche zwischen dem IP-Telefon und dem IPC-Client problemlos möglich. Mit dem IP-Telefon lässt es sich auch problemlos mit beliebigen internen und externen Teilnehmern telefonieren, während beim IPC-Client das Problem auftritt, dass man am 75 IPC nur hört, aber nicht sprechen kann: der Gesprächspartner hört gar nichts.

Weil die Kommunikation zwischen dem 75 IP und dem 75 IPC funktioniert, kann man zum Schluss kommen, dass das Headset bzw. das Mikrofon intakt ist.

Weil die Kommunikation mit dem 75 IP am Standort B zu allen Geräten an den Standorten A, B und extern möglich ist, muss man eigentlich auch zum Schluss kommen, dass
a) das IP-Setup stimmt (v.a. richtige Gateway-Adressen der TKA und der MGW-Karte)
b) der VPN-Tunnel voll funktionstüchtig ist
c) die Hardware soweit intakt ist (speziell MGW-Karte)

Den SoftPhone-Client kann man eigentlich gar nicht falsch konfigurieren und auch mit unterschiedlichen 9.0-Firmware-Versionen zeigt sich das gleiche Bild.

Was ich auch noch berichten kann, dass das temporäre Deaktivieren der MGW-Karte und das explizite Setzen des G.711-Codecs keine Veränderung brachten. Der 75 IPC-Client bleibt stumm über das VPN.

Hat jemand eine Erklärung dafür, wieso sich das SoftPhone anders verhält als das OpenPhone 75 IP? Kann jemand von ähnlichen Erlebnissen berichten oder hätte jemand sogar eine Lösung für dieses Problem?

Beste Grüsse aus der Schweiz
Philippe Balogh

 

[mfehleisen]

Mit dem Softphone habe ich schon die "lustigsten" Sachen erlebt - ich gehe bei Problemen meistens davon aus, das der Clientrechner ein Problem hat - eventuell eine Firewall oder testweise mal bei der Soundkarteneinstellung im IPC das DirectX deaktiviert?

-Matthias

 

[Balogh]

Matthias, vielen Dank für die schnelle Antwort. Der IPC-Client funktioniert bei uns perfekt, wenn sich die Gegenstelle im gleichen LAN befindet. Die Signalisierung über das VPN funktioniert folglich problemlos, nur mit den Gesprächen hapert es in eine Richtung. Das Verhalten stellen wir nicht nur auf einem Rechner, sondern auf allen Rechnern fest und zwar über alle drei unterschiedlichen VPN-Strecken, die wir eingerichtet hatten. Der Umstand, dass bei einer Kommunikation zwischen zwei Filialstandorten auch eine direkte Kommunikation zwischen diesen beiden Orten gegeben sein muss, ist uns bekannt, aber in diesem Fall nicht relevant, denn die Kommunikation mit "normalen" 75 IP ist anstandslos möglich.

Nichts auszusetzen gibt es auch am Audio-Setup der PC: Das lokale Echo ist ebenfalls funktionstüchtig und die "Gespräche" können vom IPC sogar aufgezeichnet werden. Auf der Aufzeichnung hört man dann sowohl die Gegenstelle als auch sich selbst. Nur eben: die Gegenstelle hört gar nichts.

Wenn sich der IPC-Client per PPTP-VPN ins LAN der OCX320 einwählt, dann funktioniert das 75 IPC übrigens einwandfrei. Das ist aber auch nicht besonders verwunderlich, weil dann der PC mit einer IP-Adresse aus diesem LAN versorgt wird und die Kommunikation eigentlich nicht geroutet werden muss.

Frage: gibt es jemanden, der den IPC-Client in einem Szenario erfolgreich einsetzt, wo über VPN geroutet wird (also VPN Site-to-Site)?

Beste Grüsse, Philippe

 

[buster01]

das deutet nicht nur auf eine firewall hin, sondern das problem wird nur durch eine firewall erzeugt. es stellt sich nur die frage in welchem router. da es ja so ist, das am op75 ipc der audiostream an kommt, nur der am anderen ende nicht hört was man am op75ipc sagt. würde ich davon ausgehen das entweder in x320 auf dem lan-port die firewall an ist, oder in dem vpn router davor nat aktiv ist bzw. die firewall an ist.
zur erklärung, sip nutzt für die audiostreams ein protokoll namens rtp (realtime transport protokoll). dieses protokoll nutzt beliebige ports aus einem relativ großen bereich. da diese ports peer zufall gewählt werden, hat eine nat oder eine firewall ein problem. bei nat (network adress translation) wird der ankommende datenstrom einfach verworfen, da es keine dazu passende ausgehende verbindung von einem hinter der nat befindlichen gerätes gibt. sollte eine firewall eingesetzt werden, so muss dieser portbereich für ankommende verbindungen nur freigeben werden.

und um deine frage zu beantworten, ja wir haben mehrere solcher konstellationen in betrieb.

 

[Balogh]

Vielen Dank für die umfassende Stellungnahme. Obwohl keine Firewall-Regeln auf dem VPN greifen, haben wir zur Sicherheit auf beiden Seiten die Firewall komplett deaktiviert, was aber keine Änderung gebracht hat. Die Logs auf den Firewall zeigen keinen einzigen Drop oder Reject an. Wir gehen daher davon aus, dass dort nichts geblockt wird. Auf der OCX sind ebenfalls alle Filterlisten deaktiviert.

Die VPN-Tunnels sollten zudem vom NAT völlig unbeeinflusst sein und mit allen OpenPhone 75 IP funktionieren diese schliesslich absolut problemlos. Einzig mit den SoftPhone 75 IPC hat es audiomässig in die abgehende Richtung noch nie geklappt, was wir nur so erklären können, dass sich diese Clients netzwerktechnisch anders als das Hardware-Vorbild verhalten.

Wir werden im nächsten Versuch ein geroutetes Netzwerksegment einrichten, so dass wir die möglichen Störeinflüsse NAT und Firewall zu 100% ausschliessen können. Wenn es dann noch immer so ist, dass es mit den 75 IP geht und mit den 75 IPC nicht geht, dann muss es an den Clients liegen.

Beste Wochenendgrüsse, Philippe

 

[buster01]

die windows firewall ist aber aus? bzw. in machen virenscannern verstecken sich auch noch welche.

 

[buster01]

manchmal ist im soundmixer das mikrofon bei den aufnahmegeräte ausgeschalten. das würde den gleichen effekt erzeugen.

 

[Balogh]

Nachdem der IPC-Client im lokalen Netzkwerk funktioniert und immer auch das lokale Echo zu hören ist, kann ein fehlerhaftes Audiosetup zu 100% ausgeschlossen werden. Wenn sich der PC über ein PPTP-VPN verbindet, so funktioniert alles und wenn sich der PC über den Site-to-Site-VPN-Tunnel verbindet, so geht das abgehende Audio nicht. Bevor man nun mutmasst, dass etwas an diesem VPN-Tunnel nicht in Ordnung sei, soll noch erähnt werden, dass über diesen VPN-Tunnel die Kommunikation mit den normalen OpenPhone 75 IP ohne Einschränkungen möglich ist.

Die Frage ist nach wie vor, wieso sich ein 75 IPC so derart anders verhält als ein 75 IP. Wenn ich mir die vielen Problemerichte anschaue, dann zweifle ich langsam daran, dass jemand erfolgreich den 75 IPC-Client in einem Site-to-Site-Szenario mit IPSec betreibt. Denn ich will es nochmals sagen: mit dem PC-to-Site-VPN geht es problemlos.

Ich habe bisher kein technisches Dokument gefunden, das genau eine IPSec-Verbindung zwischen zwei LAN-Standorten ausschliesst. Es gibt sogar die gegenteilige Aussage, wonach sich ein OpenPhone IPC genauso wie ein OpenPhone IP verhalten soll.

Ich bin gespannt, ob jemand nun noch einen konkreten Hinweis geben oder -- noch besser -- von seinen Erfahrungen berichten könnte.

Beste Grüsse, Philippe Balogh

 

[Balogh]

Hallo zusammen

Nach dem Update der OCX320 auf den Release 9.02 (R 1.379.3.3) funktioniert nun der IPC-Client über zwei verschiedene VPN-Strecken klaglos, ohne dass am Netzwerk-Setup etwas verändert worden ist. Auch die PC sind die gleichen geblieben. Vorher war an beiden abgesetzten Standorten immer nur Hören möglich.

Im Dokument zum erwähnten Release habe ich aber keinen Hinweis auf Änderungen gefunden.

Mit bestem Gruss, Philippe

 

[Rosenheimer54]

Danke dir, das sind interessante Infos die man eigentlich von DeTeWe erwartet. Aber die scheinen es auch so zu machen wie die Telekom. Wenn man dort wegen einer Störung anruft. Das Ergebnis der Überprüfung eines Anrufes bei der Störungsstelle ist fast immer, daß sie keinen Fehler finden konnten. Trotzdem funktioniert das ganze danach. Welch ein glücklicher Zufall

Franz