3
Probleme mit VoIP via Office Communicator von LAN zu WAN.
VoIP nicht moeglich wenn ein Client ausserhalb des Netzwerks ist.
Servus.
Hier die Situation. Wir haben extern unseren Exchangeserver gehostet und darueber auch Office Communicator 2007 R2.
Innerhalb unseres LAN (Win2008 R2 Domain) alles in Ordnung, keiner Probleme.
Befindet sich jetzt ein Client ausserhalb des LANs ist ein VoIP-Gespraech nicht moeglich. Der Office Communicator bringt folgende Meldung:
"The call was disconnected because "User" stopped receiving audio. Please try the call again."
Das merkwuerdige ist, versucht man dieses 10 mal, kommt etwa einmal ein Gesprach zustanden, die restlichen Male diese Meldung.
Unsere Clients nutzen Win XP und Win 7 (Professional) haben aber alle das selbe Problem. Die locale Firewall (EndPoint) ist ebenfalls nicht das Problem. (Testweise deaktiviert)
Unsere SonicWALL blockt ebenfalls keine Verbindung.
Hinzu kommt, dass das selbe Problem auftritt wenn 2 Notebooks beide versuchen ueber das 3G Netz ein VoIP Call zu starten.
Logischer Weise habe ich bereits den Support des Hosters kontaktiert, die haben "alles" gecheckt und schieben das Problem auf meine Seite. Sie koennen z.B. mit zwei Clients die mit 3G verbunden sind VoIP Calls durchfuehren.
Weiter funktioniert das "Screen-sharing" sowie das Datei versenden auf diesem Wege nicht.
Via Google finet man zu dieser Fehlermeldung eine Menge jedoch nichts was auch nur im Ansatz einer Loesung gleichkommt.
Ich hoffe jemand weiss hier Rat da ich wirklich am verzweifeln bin.
Dank und Gruss
Servus.
Hier die Situation. Wir haben extern unseren Exchangeserver gehostet und darueber auch Office Communicator 2007 R2.
Innerhalb unseres LAN (Win2008 R2 Domain) alles in Ordnung, keiner Probleme.
Befindet sich jetzt ein Client ausserhalb des LANs ist ein VoIP-Gespraech nicht moeglich. Der Office Communicator bringt folgende Meldung:
"The call was disconnected because "User" stopped receiving audio. Please try the call again."
Das merkwuerdige ist, versucht man dieses 10 mal, kommt etwa einmal ein Gesprach zustanden, die restlichen Male diese Meldung.
Unsere Clients nutzen Win XP und Win 7 (Professional) haben aber alle das selbe Problem. Die locale Firewall (EndPoint) ist ebenfalls nicht das Problem. (Testweise deaktiviert)
Unsere SonicWALL blockt ebenfalls keine Verbindung.
Hinzu kommt, dass das selbe Problem auftritt wenn 2 Notebooks beide versuchen ueber das 3G Netz ein VoIP Call zu starten.
Logischer Weise habe ich bereits den Support des Hosters kontaktiert, die haben "alles" gecheckt und schieben das Problem auf meine Seite. Sie koennen z.B. mit zwei Clients die mit 3G verbunden sind VoIP Calls durchfuehren.
Weiter funktioniert das "Screen-sharing" sowie das Datei versenden auf diesem Wege nicht.
Via Google finet man zu dieser Fehlermeldung eine Menge jedoch nichts was auch nur im Ansatz einer Loesung gleichkommt.
Ich hoffe jemand weiss hier Rat da ich wirklich am verzweifeln bin.
Dank und Gruss
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 153314
Url: https://administrator.de/forum/probleme-mit-voip-via-office-communicator-von-lan-zu-wan-153314.html
Ausgedruckt am: 23.12.2024 um 19:12 Uhr
3 Kommentare
Neuester Kommentar
Wieso hast du denn überhaupt eine Sonicwall im Netz wenn die nichts blockt ? Diese Aussage ist vermutlich schlicht falsch, mal ganz abgesehen davon das eine FW dann vollkommen sinnlos wäre.
Welche Ports hast du denn geprüft, gerade im Hinblick auf VoIP mit dem Communicator ?
Vermutlich macht die NAT und wenn du die dir Protokoll Mechanismen von SIP, RTP bzw. H.323 also den VoIP Protokollen einmal genau ansiehst wirst du sehen das aufgrund der dynmaischen Port Aushandlung beim Verbindungsaufbau VoIP deshalb meist niemals NAT oder eine FW überwinden kann.
In der Regeln setzt man ein VPN mit dieser Anwendung an allein schon aus Sicherheitsgründen, da die Communicator Daten nicht verschlüsselt sind und jeder im Internet mit freien Tools jegliche eurer Kommmunikation mitbelauschen kann. Mehr oder weniger also ein sehr bedenkliches Bastel Design was du da machst aber du wirst ja sicher wissen was du da tust...
3G Netze haben fast immer Providerseitig eine NAT Firewall aktiv wenn du billige Consumer Surf Accounts nutzt und keine Business Accounts. Über diese APNs werden dann meist nur RFC 1918 IP Adressen (Private IPs) vergeben. Siehe hier:
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
Du solltest also erstmal etwas mehr Informationen besorgen bevor man hier ins Eingemachte geht. Ohne das ist eine qualifizierte Hilfe nicht möglich bzw. gibt sie in deiner Konstellation auch gar nicht !
Welche Ports hast du denn geprüft, gerade im Hinblick auf VoIP mit dem Communicator ?
Vermutlich macht die NAT und wenn du die dir Protokoll Mechanismen von SIP, RTP bzw. H.323 also den VoIP Protokollen einmal genau ansiehst wirst du sehen das aufgrund der dynmaischen Port Aushandlung beim Verbindungsaufbau VoIP deshalb meist niemals NAT oder eine FW überwinden kann.
In der Regeln setzt man ein VPN mit dieser Anwendung an allein schon aus Sicherheitsgründen, da die Communicator Daten nicht verschlüsselt sind und jeder im Internet mit freien Tools jegliche eurer Kommmunikation mitbelauschen kann. Mehr oder weniger also ein sehr bedenkliches Bastel Design was du da machst aber du wirst ja sicher wissen was du da tust...
3G Netze haben fast immer Providerseitig eine NAT Firewall aktiv wenn du billige Consumer Surf Accounts nutzt und keine Business Accounts. Über diese APNs werden dann meist nur RFC 1918 IP Adressen (Private IPs) vergeben. Siehe hier:
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
Du solltest also erstmal etwas mehr Informationen besorgen bevor man hier ins Eingemachte geht. Ohne das ist eine qualifizierte Hilfe nicht möglich bzw. gibt sie in deiner Konstellation auch gar nicht !
Wow, da habe ich ja wohl wirklich was verbrochen. Aber dennoch mal denke fuer deine "freundliche" Antwort.
"Sie block nichts" war bezogen auf den MOC traffic. - Hier aber danke fuer deine ueberaus hilfreichen und belehrenden Worte. Dennoch werde ich versuchen das naechste mal mich genauer auszudrucken.
Die Ports die ich geprueft hatt sind 443 und 50000-59999.
Weiter hast du auch recht... ich weiss was ich hier "bastel" aber danke dass du Dir direkt mal soviele freundliche Gedanken machst.
Weiter nutze ich 3G businiess accounts ohne NAT Firewall und keine billigen Conusmer Surf Accounts.
Welche Informationen sollte ich mir denn jetzt noch besorgen dass ich hier um qualitifizierte Hilfe bitten darf?
Allgemein gesprochen, habe ich gehofft dass jemand sich auf der Seite des MOC Servers ausskennt und ein aehnliches Problem schonmal hatte und das es vielleicht an einer fehlerhaften Einstellung liegen kann.
"Sie block nichts" war bezogen auf den MOC traffic. - Hier aber danke fuer deine ueberaus hilfreichen und belehrenden Worte. Dennoch werde ich versuchen das naechste mal mich genauer auszudrucken.
Die Ports die ich geprueft hatt sind 443 und 50000-59999.
Weiter hast du auch recht... ich weiss was ich hier "bastel" aber danke dass du Dir direkt mal soviele freundliche Gedanken machst.
Weiter nutze ich 3G businiess accounts ohne NAT Firewall und keine billigen Conusmer Surf Accounts.
Welche Informationen sollte ich mir denn jetzt noch besorgen dass ich hier um qualitifizierte Hilfe bitten darf?
Allgemein gesprochen, habe ich gehofft dass jemand sich auf der Seite des MOC Servers ausskennt und ein aehnliches Problem schonmal hatte und das es vielleicht an einer fehlerhaften Einstellung liegen kann.
Das Internet ist voll von solchen Dokumenten:
http://www.gilham.org/Blog/Lists/Posts/Post.aspx?List=aab85845-88d2-409 ...
usw.
Ob du RFC 1918 IP Adressen bekommst auf deinen 3G Clients / Accounts kannst du mit ipconfig sehen wenn die Clients im 3G Netz aktiv sind. Die Vergabe der 3G IPs ist abhängig vom verwendeten APN !
Den für den MOC relevanten SIP Port für Voice hast du gar nicht getestet nach deinen obigen Ausführen ! So kann das dann natürlich auch nichts werden.
http://de.wikipedia.org/wiki/Session_Initiation_Protocol
Wenn du also nur 443 getestet hast (50000-59999 sind irrelevante Ports) ist die Aussage "Sie block nichts" für die MOC Ports ja schlicht falsch ! 443 ist lediglich simples HTTPS nicht mehr und nicht weniger !
http://www.gilham.org/Blog/Lists/Posts/Post.aspx?List=aab85845-88d2-409 ...
usw.
Ob du RFC 1918 IP Adressen bekommst auf deinen 3G Clients / Accounts kannst du mit ipconfig sehen wenn die Clients im 3G Netz aktiv sind. Die Vergabe der 3G IPs ist abhängig vom verwendeten APN !
Den für den MOC relevanten SIP Port für Voice hast du gar nicht getestet nach deinen obigen Ausführen ! So kann das dann natürlich auch nichts werden.
http://de.wikipedia.org/wiki/Session_Initiation_Protocol
Wenn du also nur 443 getestet hast (50000-59999 sind irrelevante Ports) ist die Aussage "Sie block nichts" für die MOC Ports ja schlicht falsch ! 443 ist lediglich simples HTTPS nicht mehr und nicht weniger !
