.titleBar { margin-bottom: 5px!important; }

An alle Cracks IP call

Dieses Thema im Forum "Grundsätzliches" wurde erstellt von LateRunner, 19 Okt. 2004.

  1. LateRunner

    LateRunner Mitglied

    Registriert seit:
    24 Mai 2004
    Beiträge:
    253
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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???
     
  2. voipalex

    voipalex Mitglied

    Registriert seit:
    18 Okt. 2004
    Beiträge:
    319
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  3. Borkk

    Borkk Neuer User

    Registriert seit:
    25 März 2004
    Beiträge:
    141
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  4. rollo

    rollo IPPF-Promi

    Registriert seit:
    5 Juli 2004
    Beiträge:
    8,266
    Zustimmungen:
    1
    Punkte für Erfolge:
    38
    Ort:
    JO30SK
    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
     
  5. Borkk

    Borkk Neuer User

    Registriert seit:
    25 März 2004
    Beiträge:
    141
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
    Sind die X-Lites irgendwo angemeldet?
     
  6. LateRunner

    LateRunner Mitglied

    Registriert seit:
    24 Mai 2004
    Beiträge:
    253
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @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.
     
  7. voipalex

    voipalex Mitglied

    Registriert seit:
    18 Okt. 2004
    Beiträge:
    319
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Das von meinem Freund nicht. Meines ja.
    Aber es geht hier um Direct IP Calls.

    Gruß
    Alex
     
  8. voipalex

    voipalex Mitglied

    Registriert seit:
    18 Okt. 2004
    Beiträge:
    319
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  9. Borkk

    Borkk Neuer User

    Registriert seit:
    25 März 2004
    Beiträge:
    141
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  10. rajo

    rajo Admin-Team

    Registriert seit:
    31 März 2004
    Beiträge:
    1,958
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    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.
     
  11. Borkk

    Borkk Neuer User

    Registriert seit:
    25 März 2004
    Beiträge:
    141
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Meine Worte. :wink:
     
  12. rollo

    rollo IPPF-Promi

    Registriert seit:
    5 Juli 2004
    Beiträge:
    8,266
    Zustimmungen:
    1
    Punkte für Erfolge:
    38
    Ort:
    JO30SK
    @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
     
  13. voipalex

    voipalex Mitglied

    Registriert seit:
    18 Okt. 2004
    Beiträge:
    319
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  14. LateRunner

    LateRunner Mitglied

    Registriert seit:
    24 Mai 2004
    Beiträge:
    253
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @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