VoIP/SIP über VPN: Partner hört mich nicht

[nophone]

Ich habe eine VPN Verbindung zu meiner Uni hergestellt. Dazu nutze ich den Windows XP internen VPN client. Wenn ich dann jemanden mit meinem Softphone anrufe, hört er mich zwar, aber ich kann ihn nicht hören. Ich habe es auch mit einem SIP-Proxy (bluesip) getestet und mit verschiedenen Softphones (Eyebeam, SJphone). Bei anderen SIP-Proxies funktioniert noch nichtmal die Registrierung und ein Anruf kommt gar nicht zustande.
An NAT wird es wohl nicht liegen, da der VPN Client eine öffentliche IP-Adresse erhält.
Ich weiss einfach nicht mehr weiter. Ohne VPN klappt es. Weiss jemand woran soetwas liegen könnte?

 

[SteHan]

RTP im VPN blockiert?

Hallo nophone,

ich weiß nicht, ob dein Problem schon gelöst oder erledigt ist, aber da noch nichts darauf hin deutet, gibt's doch noch eine kleine Antwort, mit der ich dann auch direkt meinen Einstand im Forum feiere. Also hallo Forum, hier bin ich.

Kürzlich durfte ich in der Uni einen kleinen Gastvortrag zum Thema VoiP hören, in dem uns erklärt wurde, daß SIP mehr oder weniger ausschließlich genutzt wird, um zwei RTP-Kanäle zu öffnen. Einer geht vom Anrufer zum Angerufenen, der andere vom Angerufenen zum Anrufer zurück.

Beide Kanäle übertragen die Daten nur in einer Richtung und nur in diesen Kanälen wird auch das übertragen, was man am jeweiligen Empfänger hören kann. Der VoiP-Fachmann sagte speziell zu deinem Problem "Wenn einer Seite nichts hört ist in 99,9999% der Fälle ein RTP-Kanal zusammengebrochen." Da RTP über UDP läuft und deshalb verbindungslos ist, d.h. einer sendet stur, der andere kann's empfangen sofern er's denn mitbekommt, haben beide Seiten keine Chance zu merken, ob der andere jetzt nur gerade still ist, oder die Verbindung wirklich abgerissen ist. Soweit das Vorlesungswissen, ob und wie richtig das jetzt ist, kann ich nicht 100% garantieren, aber vielleicht stolperst du damit ja schon über die nächsten Problemlösungs- oder -eingrenzungsmöglichkeiten.

Außerdem weiß ich aus unserer Uni, daß UDP-Datenströme je nach Verkehrsaufkommen am Gateway oder Laune des Admins mal gekappt oder so verzögert werden können, daß sie zwar irgendwann durchkoommen, den Empfänger aber dann nicht mehr interessieren. Bei uns ist sowas besonders durch das Uni-VPN, das verschiedene Dienste für unterschiedliche Benutzergruppen unterschiedlich priorisiert, relativ regelmäßig bis zuverlässig zu beobachten.

Ich weiß nicht, wie es mit den SIP-Providern grundsätzlich aussieht, aber wenn ich das richtig aufgeschnappt haben sollte, kann man SIP auch über TCP abwickeln. Das könnte vielleicht helfen, vorausgesetzt, es gibt die Möglichkeit den RTP auch irgendwie ein oder umzupacken. Wenn die Uni natürlich für externe Verbindungen eingehende UDP-Pakete filtert und du immer vor diesen Filter rennst, ist's natürlich schwierig, solange du nicht die Gegenstelle manipulieren kannst.

Vermutlich wirst du mal mit Netzwerkschnüfflern etwas testen müssen, um zu erfahren, ob die Pakete empfangen und gesendet werden. Wenn du zwei Accounts hast und von einem, der durch das VPN muß den anderen, außerhalb des VPNs, anrufen kannst, kannst du bei beiden mit Wireshark oder ähnlichen Programmen relativ gut herausfinden, was bis wo geht.

Ich hoffe, ich konnte zumindest einen bißchen bei der Fehlersuche/-eingrenzung helfen.

Stephan

Nachtrag: Habe ich gerade noch gefunden: http://wiki.ip-phone-forum.de/voip:rtp:start

 

[nophone]

Danke, SteHan!
Ich glaube inzwischen auch, dass eine Firewall der Uni sämtliche eingehenden UDP Pakete verwirft. Ich habe mir die Pakete mal mit Process Monitor angeschaut, und da tauchten keine eingehenden UDP Pakete auf. Ausgehende werden wohl weitergeleitet, denn sonst könnte mich der Partner nicht hören. Die Anmeldung beim Registrar scheint auch nur über TCP zu funktionierent. Mir ist jetzt auf die Schnelle kein Softphone bekannt, dass RTP über TCP erlaubt und ich weiss auch nicht ob die Fritzbox das unterstützt. Ich werde daher ohne VPN auskommen müssen.

 

[kriewald]

Wie wäre es mit OpenVPN? Lässt sich auch wunderbar auf TCP statt UDP konfigurieren...dann wären durch UNI-Firewall herausgefilterte UDP-Pakete kein Problem mehr.