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

SPA: Ports SIP, RTP und STUN für Nikotel + Sipgate

Dieses Thema im Forum "Linksys (VoIP)" wurde erstellt von exim, 11 Juni 2004.

  1. exim

    exim Admin a.D.

    Registriert seit:
    27 Apr. 2004
    Beiträge:
    1,013
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Die Liste der weiterzuleitenden bzw. freizugebenden Ports sieht bei jedem anders aus und auch die Provider sind etwas uneins. Um möglichst mal eine hoffentlich definitive Aussage treffen zu können, welche Ports mit welchem Protokoll denn nun genau benutzt werden, habe ich zwei Stunden "tcpdump" auf dem Linux-Router laufen lassen, ein paar RFCs durchgeblättert und alle möglichen Sachen mit dem SPA versucht:

    Der SPA-2000 nutzt für SIP- und RTP-Verkehr ausschliesslich die im Webinterface eingestellten Ports, also per default für SIP die Ports 5060 u. 5061 UDP und für RTP die Ports 16384-16482, auch UDP. Nix anderes. Keine 5004-5007 (Grandstream) und keine 30000er (SIPPS-Software).
    Wenn man also diese Ports für UDP mittels Router an den internen SPA weiterleitet reicht das aus!

    STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) ist eine Sache für sich:
    Der STUN-Server läuft laut RFC 3489 auf Port 3478. Und zwar beim Provider. Der Provider hat zwei STUN-Server - einer empfängt primär die Anfragen des Clients, der zweite STUN versucht primär die Rückverbindung.
    Ablauf: Der SPA verbindet sich von einigen lokalen Ports auf den in der Konfiguration angegebenen STUN-Server des Providers. Danach versucht dieser, sich u.a. von einer anderen IP kommend (zweiter STUN-Server des Providers) zum Client auf dessen vorherige Absenderports zu verbinden. So wird erkannt, ob NAT und falls ja, welche Art von NAT benutzt wird.
    Nikotel: Läuft so wie es soll.
    Sipgate: Irgendwie ziemlich eigenartig:
    Der SPA verbindet sich von einigen lokalen Ports auf stun.sipgate.net. Laut Konfigurationsanweisungen von Sipgate soll sich der Client auf Port 10000 des STUN-Servers verbinden. Die Rückverbindung erfolgt auch von diesem ersten STUN-Server zum SPA auf die vorherigen Absenderports des SPA, auch mit Absenderport 10000 von Seiten des Sipgate-STUN-Servers. Was das bringen soll ist mir nicht ganz klar denn richtig sinnvoll ist es ja eigentlich nur, wenn die Rückverbindung von einer anderen IP (zweiter STUN des Providers) aus erfolgt, da diese zweite IP ja möglicherweise nicht in der temporären NAT-Tabelle des Routers steht. Interessanterweise lauscht der erste Sipgate-STUN-Server neben der 10000 auch auf dem STUN-Standardport 3478. Wenn man sich auf diesen Port 3478 verbindet, erfolgt die Rückverbindung zwar auch vom ersten STUN mit Absenderport 10000, jedoch diesmal auch vom zweiten STUN und da mit dem "normalen" STUN-Absenderport 3478. Zumindest bei den Tests war das immer so. Die Frage ist nur - warum verkomplizieren die das so unnötig?
    :verdaech:

    Die Sipgate-Anleitung für Portforwarding auf Port 10000 ist schlicht falsch. Also, genau genommen nicht falsch sondern unpräzise, es ist die Rede von "Weiterleitung folgender Ports". Die 10000 ist aber der Absenderport des Sipgate-STUN-Servers und nicht der lokale(!) Zielport.

    Der STUN-RFC 3489 beschreibt zwei Arten von Anfragen am STUN-Server, eine über UDP, die andere über TCP. Der SPA unterhält sich mit den STUN-Servern ausschliesslich via UDP.

    Wem das alles zuviel war:
    Der SPA-2000 benötigt Portforwarding nur für 5060/5061 UDP, die RTP-Ports sollten vom STUN geklärt werden. Auch Nikotel bietet einen STUN-Service (stun0.nikotel.com). Wenn man den Registrierungsintervall auf beispielsweise 60 Sekunden gesetzt hat (Nikotel-Default) und der Router sich die IP-Port-Zuordnung mindestens diese 60 Sekunden lang merken kann dann benötigt man zumindest für Nikotel überhaupt kein Portforwarding. STUN ja eigentlich sowieso nicht.

    Gruß,
    Exim
     
  2. ActiveMike

    ActiveMike Neuer User

    Registriert seit:
    3 Mai 2004
    Beiträge:
    79
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Also bei mir wird auch nur Port 5060 vom Router weitergeleitet.

    Allerdings habe ich bei Line1 und Line2 auch immer 5060 eingetragen (zwei unterschiedliche Provider)


    Mike
     
  3. exim

    exim Admin a.D.

    Registriert seit:
    27 Apr. 2004
    Beiträge:
    1,013
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Akzeptiert der SPA diese Konfig? Denn das wird ja eigentlich nix - wenn ein Anruf von aussen kommt und der Anrufer bzw. der Provider-Proxy bei Dir auf Port 5060 anklopft - welcher der beiden Accounts auf dem SPA ist das dann?

    Zum Vergleich: Du hast auf einem Rechner zwei Webserver laufen und beide sollen unabhängig voneinander Dienste nach aussen anbieten. Den ersten Webserver setzt Du auf Port 80. Den zweiten musst Du auf einen anderen Port setzen denn auf Port 80 lauscht ja schon der erste Webserver auf Anfragen von aussen.

    Gruß,
    Exim
     
  4. jrrp

    jrrp Mitglied

    Registriert seit:
    21 März 2004
    Beiträge:
    356
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Exim: :groesste:
     
  5. ActiveMike

    ActiveMike Neuer User

    Registriert seit:
    3 Mai 2004
    Beiträge:
    79
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Also bei mir kommen alle Anrufe von außen richtig an (Telnummer oder account1@ip1 bzw. account2@provider2). Hinaus natürlich auch kein Problem.

    Ich glaube der SPA lauscht eben auf 5060 und leitet anhand des Users an Line1 oder 2.

    Also wie z.B.: FTP Server, der aufgrund des Login jeweils ein anderes Verzeichnis anzeigt.


    Mike
     
  6. gboelter

    gboelter Mitglied

    Registriert seit:
    5 Mai 2004
    Beiträge:
    471
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Philippinen
    Das hat Exim sicherlich nicht gemeint. Der FTP-Server verzweigt entsprechend dem User-Login auf verschiedene Verzeichnisse, läuft aber in der Regel auch nur 1 x auf Deinem Server.

    Im Beispiel ging es darum, so ich's denn richtig verstanden habe, dass Du den HTTP-Server mehrfach auf dem gleichen Rechner installierst, was natürlich auch beim FTP denkbar wäre.