An alle Cracks IP call

[LateRunner]

Hallo,
ich würde gerne wissen, ob direct IP call auch durch einen Router geht und ob es reicht per sua/nat die Ports für SIP und RTP durchzureichen.

Bei mir kann ich intern (hinter dem Router) die Telefone mit ihren lokalen IP ereichen und auch mit der WAN IP (allerdings bin ich mir nicht sicher ob der Router das nicht selbst umsetzt - loopback)

Mit dem ATA vor einem Router ging direct IP Call problemlos.


VG

LateRunner

P.S: habe gerade erfahren, daß wenn ein anderer Teilnehmer anruft (es klingelt korrekt) seine Packets an 192.168.1.1:5004 (RTP Port) geschickt werden. Die gehen natürlich ins Nirwana. Es müßte doch ein (fast) leichtes sein die Packets nach meine_wanIP:5004 zu schicken - oder???

 

[voipalex]

Ich konnte es heute mit einem Bekannten testen:
Wir beide sitzen hinter einem Router, konnten aber dank entsprechendem Portforwarding auf beiden Routern trotzdem über X-Lite miteinander telefonieren.

Gruß
Alex

 

[Borkk]

P.S: habe gerade erfahren, daß wenn ein anderer Teilnehmer anruft (es klingelt korrekt) seine Packets an 192.168.1.1:5004 (RTP Port) geschickt werden. Die gehen natürlich ins Nirwana. Es müßte doch ein (fast) leichtes sein die Packets nach meine_wanIP:5004 zu schicken - oder???

Das ist eigentlich Aufgabe von STUN (Simple Traversal of UDP through NAT ). Das VoIP Engeräte erfragt vor einem Call bei einem STUN Server welche "reale" IP Adresse es hat. Also welche IP gerade die WAN Seite des Routers hat (ist natürlich nur bei dyn.IP Vergabe nötig!). Das Endgerät baut dann diese IP Adresse in die Pakete ein. Somit erhält die gegenstelle eine plausible IP Adresse auf die sie Antworten kann. Den Rest macht dann der Router mit entsprechende Port-Forwards.

 

[rollo]

STUN funktioniert aber nur mit einem Provider, bei dem sich der Client anmeldet. Die Frage ging um Direktcalls und da ist Portforwarding das Mittel der Wahl.

jo

 

[Borkk]

Das stimmt.
Aber das Problem mit der privaten IP statt der WAN IP wird dadurch nicht gelöst, da kann aber der Trick mit der DynDNS URL helfen.

@voipalex

Wir beide sitzen hinter einem Router, konnten aber dank entsprechendem Portforwarding auf beiden Routern trotzdem über X-Lite miteinander telefonieren.

Sind die X-Lites irgendwo angemeldet?

 

[LateRunner]

@Borkk Du hast natürlich recht und Portforwarding ist eingestellt. Das Problem ist aber die Gegenstelle. Die müßte an wanIP:5004 schicken, sendet aber stattdessen an 192.168.1.39:5004!! und das kommt natürlich ie an.

 

[voipalex]

Wir beide sitzen hinter einem Router, konnten aber dank entsprechendem Portforwarding auf beiden Routern trotzdem über X-Lite miteinander telefonieren.

Sind die X-Lites irgendwo angemeldet?

Das von meinem Freund nicht. Meines ja.
Aber es geht hier um Direct IP Calls.

Gruß
Alex

 

[voipalex]

@Borkk Du hast natürlich recht und Portforwarding ist eingestellt. Das Problem ist aber die Gegenstelle. Die müßte an wanIP:5004 schicken, sendet aber stattdessen an 192.168.1.39:5004!! und das kommt natürlich ie an.

Nochmal zur Klärung für alle anderen: Ich habe das sowohl mit einem Freund, der ebenfalls X-Lite benutzt als auch mit LateRunner getestet, der über ein HT486 verfügt.
Mit X-Lite klappt es, mit dem HT486 klappt es nicht (auch nicht Ton in eine Richtung)

Das Problem liegt eindeutig beim HT486:
Es ist zwar X-Lite gewesen, das an die falsche IP gesendet hat, aber dies geschah nur aus dem Grund, dass das Grandstrem HT486 1.0.5.10 die interne IP (192.168.1.39) beim Verbindungsaufbau durch das SIP Protokoll geliefert hat.
X-Lite hat also nur getan, was das HT486 verlangt hat..

Es kamen auch keinerlei Pakete vom HT486 bei mir an.

Das Problem liegt wohl darin, dass das HT486 ausschließlich das From Field auswertet und daraus die Ziel-IP Adresse und den Port bestimmt für RTP.
Außerdem wird das Contact Feld in den vom HT486 gesendeten Paketen nicht korrekt gesetzt (nämlich die interne anstatt der externen IP).

In den von X-Lite gesendeten Paketen steht in den Feldern "Owner/Creator" (SDP - Session Description Protocol), "Via" und "Contact" (beide SIP Message Headers) die korrekte externe IP von mir.
Die scheint X-Lite wohl korrekt einzutragen weil ich bei Network "Auto Detect IP" eingestellt habe.
Nur im "From"-Feld (SIP) steht die falsche interne IP von mir.

Falls es jemand interessiert, woher ich das weiß: Ich habe einfach auf meinem Software-Router alle Pakete per tcpdump mitgeschnitten.

Gruß
Alex

 

[Borkk]

Ich habe schon verstanden das es um Direkt IP Calls geht!

@Voipalex
Genau das haben wir doch die ganze zeit vermutet. Danke das du dir die Mühe gemacht hast um es es nochmal genau zu erklären.

@LateRunner
Du must es schaffen das dein ATA die extene IP rausbekommt und verwendet. Kannst du sowas wie eine NAT IP oder sowas eintragen? Der Trick mit der Dnydns Url hat bei mir mit eine Cisco IP Phone auch gefunzt.

 

[rajo]

STUN funktioniert aber nur mit einem Provider, bei dem sich der Client anmeldet. Die Frage ging um Direktcalls und da ist Portforwarding das Mittel der Wahl.

jo

Das ist mir jetzt neu... ich brauch irgendeinen stun-server draussen im Netz. Wo der steht war bei mir bis jetzt eigentlich immer egal:

Ich nutze meist kphone und das hat als stun-server schon stun.wirlab.net:3478 voreingestellt und ich verschiedene Accounts (iptel, fwd, Uni, ...) damit und es tut.

Würde mich auch ehrlich wundern wenn es nicht tut, denn Stun macht ja nix anderes als öffentliche IP/Port an den Client zurückliefern.

 

[Borkk]

Das ist eigentlich Aufgabe von STUN (Simple Traversal of UDP through NAT ). Das VoIP Engeräte erfragt vor einem Call bei einem STUN Server welche "reale" IP Adresse es hat. Also welche IP gerade die WAN Seite des Routers hat (ist natürlich nur bei dyn.IP Vergabe nötig!). Das Endgerät baut dann diese IP Adresse in die Pakete ein. Somit erhält die gegenstelle eine plausible IP Adresse auf die sie Antworten kann. Den Rest macht dann der Router mit entsprechende Port-Forwards.

Meine Worte. :wink:

 

[rollo]

@voipalex

Das debugging mit X-Lite kannst Du auch einfacher haben, die Pakete stehen im Klartext im Logfile

Bei X-Lite gibt es eine Option "Auto Detect IP", die sich auf die externe IP bezieht.

Zum ATA kann ich leider nichts sagen, man müsste dem aber auch klar machen können, dass er die externe nehmen soll.

jo

 

[voipalex]

Das debugging mit X-Lite kannst Du auch einfacher haben, die Pakete stehen im Klartext im Logfile

Warum einfach, wenn es auch kompliziert geht?

Danke für den Tipp! Das wußte ich nicht.

Es werden dort allerdings nur SIP und nicht RTP Pakete geloggt, so dass es schon Sinn machte, hier tcpdump einzusetzen.

 

[LateRunner]

@Rollo genau - aber so ein Feld gibts im ata nicht oder ich habs bis jetzt noch nicht entdeckt. Etwas für die GS Entwicklunsabteilung???

VG

LateRunner