Hallo Leute!
Auch mit der aktuellsten Firmware krieg ich's irgendwie noch nicht ganz hin ...
Ich versuche mich von einem entfernten Standort aus mit einem Sip-Client (egal ob Soft- oder Hardware-Client) am 1722 im Büro anzumelden. Habe hierfür einen separaten SIP-Benutzer angelegt. Der 1722 - also mein Büro-Netz - ist über xyz.dyndns.org erreichbar.
Nach ein bisschen ausprobieren mit den Einstellungen im Sip-Client erscheint dieser bei mir im LAN-Monitor am 1722 als angemeldet und registriert. Der Sip-Client kann dann auch Anrufe tätigen und Anrufe unter der ihm zugewiesenen Rufnummer entgegen nehmen. !!! ABER: es kann nicht kommuniziert werden - es werden offensichtlich in keine der beiden Richtungen Sprachdaten übertragen.
Woran kanns liegen - was mache ich falsch?
Über die WAN-Schnittstelle am 1722 als SIP-Client anmelden
Moderator: Lancom-Systems Moderatoren
Meine Versuche (gesnifft mit Packetyzer) zeigen im wesentlichen folgendes Verhalten.
REGISTER über public IP (also WAN-Port) ist ok, wenn der SIP User vorher
mit Passwort im VCM eingetragen wird.
Beim INVITE gibts das Problem, das im SDP private IP stehen und daher
keine Sprachverbindung zusammenkommt.
Das Schlimmste !!! Wenn der externe SIP-User eine ISDN-Leitung gewählt
hat geht dann das BYE verloren und der ISDN-Call wird nicht beendet €€€
Andre
REGISTER über public IP (also WAN-Port) ist ok, wenn der SIP User vorher
mit Passwort im VCM eingetragen wird.
Beim INVITE gibts das Problem, das im SDP private IP stehen und daher
keine Sprachverbindung zusammenkommt.
Das Schlimmste !!! Wenn der externe SIP-User eine ISDN-Leitung gewählt
hat geht dann das BYE verloren und der ISDN-Call wird nicht beendet €€€
Andre
Habe im Prinzip das gleiche Problem, nur dass ich über SIP-PBX Leitung reinkomme. Über ISDN kann ich weiterwählen und es kommt auch eine Verbindung zustande. Zwar ist es noch etwas Glücksache, welcher Codec zum Einsatz kommt, aber es geht...
Wenn ich über SIP weitergehen will, dann höre ich zwar noch das Läuten, sobald die Verbindung dann aufgebaut wird, ist nichts mehr zu hören.
Heißt es hier auch das nächste Update warten?
ML
Wenn ich über SIP weitergehen will, dann höre ich zwar noch das Läuten, sobald die Verbindung dann aufgebaut wird, ist nichts mehr zu hören.
Heißt es hier auch das nächste Update warten?
ML
Hi ML
Über die BPX-Line kannst du durch einen VPN-Tunnel erstmal nur direkt im entfernten LAN angeschlossene Telefone (und auch die ISDN-Lines) erreichen. Wenn's aber ins Internet raus geht, müßte das LANCOM in beide Richtungen (also nicht nur für den abgehenden RTP-Srom, sondern auch für den einkommenden) ein Proxy sein - oder aber du erstellst passende VPN-Regeln (d.h. deine Default-Route muß durch den VPN-Tunnel gehen).
Eine weitere Möglichkeit wäre, eine PPTP-Verbindung über den VPN-Tunnel zu legen. Dann hast du zumindest nicht mehr das Problem mit den VPN-Regeln, Aber das generelle Problem der Default-Route bleibt: Die Firewall würde den einkommenden RTP-Strom verwerfen, weil er über das falsche Interface kommt (er kommt ja über die PPTP-Strecke und nicht über die Internetverbindung). Um das zu umgehen kannst du eine zusätzliche getagte "Default-Route" auf die PPTP-Verbindung legen...
Gruß
Backslash
das dürfte eher daran liegen, daß die VPN-Regeln der LAN-LAN-Kopplung den RTP-Traffic von beliebigen Adressen (also dem über SIP im Internet angerufenen Telefon) nicht zulassen.Wenn ich über SIP weitergehen will, dann höre ich zwar noch das Läuten, sobald die Verbindung dann aufgebaut wird, ist nichts mehr zu hören.
Über die BPX-Line kannst du durch einen VPN-Tunnel erstmal nur direkt im entfernten LAN angeschlossene Telefone (und auch die ISDN-Lines) erreichen. Wenn's aber ins Internet raus geht, müßte das LANCOM in beide Richtungen (also nicht nur für den abgehenden RTP-Srom, sondern auch für den einkommenden) ein Proxy sein - oder aber du erstellst passende VPN-Regeln (d.h. deine Default-Route muß durch den VPN-Tunnel gehen).
Eine weitere Möglichkeit wäre, eine PPTP-Verbindung über den VPN-Tunnel zu legen. Dann hast du zumindest nicht mehr das Problem mit den VPN-Regeln, Aber das generelle Problem der Default-Route bleibt: Die Firewall würde den einkommenden RTP-Strom verwerfen, weil er über das falsche Interface kommt (er kommt ja über die PPTP-Strecke und nicht über die Internetverbindung). Um das zu umgehen kannst du eine zusätzliche getagte "Default-Route" auf die PPTP-Verbindung legen...
Gruß
Backslash
Hi Backslash,
die Erklärung hört sich schlüssig an. Doch das würde bedeuten, dass mein Vorhaben nur von hinten durch die kalte Küche zu erreichen ist. Ist es angedacht, dies als Feature einzubauen, dürfte doch sicher mehr Leute interessieren?
Du kannst natürlich einwenden, dass man den SIP-Verkehr von der Filiale abgehen lassen kann und nur eine backup-Route über ISDN der Zentrale schaltet. Doch gibt es durchaus Gründe für die "Zentrale Lösung":
A) Ausnutzung von SIP-flatrate bei der Zentrale
B) SIP-Probleme im Ausland: Oftmals ist tagelang keine SIP-Anmeldung möglich, der VPN-Tunnel steht jedoch meist stabil
Gruss,
ML
die Erklärung hört sich schlüssig an. Doch das würde bedeuten, dass mein Vorhaben nur von hinten durch die kalte Küche zu erreichen ist. Ist es angedacht, dies als Feature einzubauen, dürfte doch sicher mehr Leute interessieren?
Du kannst natürlich einwenden, dass man den SIP-Verkehr von der Filiale abgehen lassen kann und nur eine backup-Route über ISDN der Zentrale schaltet. Doch gibt es durchaus Gründe für die "Zentrale Lösung":
A) Ausnutzung von SIP-flatrate bei der Zentrale
B) SIP-Probleme im Ausland: Oftmals ist tagelang keine SIP-Anmeldung möglich, der VPN-Tunnel steht jedoch meist stabil
Gruss,
ML
Hi ML
Ich schätze mal, daß das irgendwann kommen wird, nur da ich selbst mit dem SIP nichts am Hut habe, kann ich auch keine weitere Aussage dazu treffen
Solange es nur um Filialen geht, die über die Zentrale telefonieren wollen, ist das ganze mit der filialseitigen Defaultroute in Richtung Zentrale erledigt. Wenn die Zentrale aber auch mal den umgekehrten Weg nutzen will, ist das Problem wieder da...
Gruß
Backslash
Z.Zt wirst du es nur so umständlich hinbekommenDoch das würde bedeuten, dass mein Vorhaben nur von hinten durch die kalte Küche zu erreichen ist.
es wurde zumindest schonmal diskutiert. Das Problem ist, daß du auch nicht willst, daß das LANCOM für alle Gespräche (also z.B. die im internen LAN) den Proxy spielt - dann wird es sehr schnell überlastet... Also muß man erstmal versuchen herauszufinden, wann das LANCOM denn als beidseitiger Proxy agieren muß und wie sich das elegant umsetzen läßtIst es angedacht, dies als Feature einzubauen, dürfte doch sicher mehr Leute interessieren?
Ich schätze mal, daß das irgendwann kommen wird, nur da ich selbst mit dem SIP nichts am Hut habe, kann ich auch keine weitere Aussage dazu treffen
Den Einwand möchte ich gar nicht machen.Du kannst natürlich einwenden, dass man den SIP-Verkehr von der Filiale abgehen lassen kann und nur eine backup-Route über ISDN der Zentrale schaltet. Doch gibt es durchaus Gründe für die "Zentrale Lösung":
Solange es nur um Filialen geht, die über die Zentrale telefonieren wollen, ist das ganze mit der filialseitigen Defaultroute in Richtung Zentrale erledigt. Wenn die Zentrale aber auch mal den umgekehrten Weg nutzen will, ist das Problem wieder da...
Gruß
Backslash