1. feststellen (per STUN), ob symmetrisches NAT vorliegt. 2. prüfen (per STUN) , ob evtl. eine Weiterleitung der relvanten Ports im NAT-device konfiguriert ist. Wenn ja: kein Problem 3. Falls nein: a) in der SIP-INVITE-Nachricht "rport" ohne Portangabe einfügen. Das führt laut RFC dazu, dass der Aufbau der rtp-Verbindung in umgekehrter Richtung erfolgen soll. Also vom Anrufer zum Angerufenen. Das löst das Problem, solange der Angerufene nicht auch hinter einem symmetrischen NAT sitzt. b) Falls der Angerufene per rport-Angabe signalisiert, dass auch er hinter einem symmetrischen NAT sitzt, sollte Phoner nicht die öffentliche, sondern die interne IP in dem Contact- Header und in dem SDP-Teil verwenden. Denn dann schalten einige VoIP-Provider (wie z.B. sipgate) automatisch eine rtp-proxy dazwischen. - Jetzt fällt mir gerade ein, dass die entsprechende INVITE-Nachricht vom Anrufer dann natürlich schon raus ist, wenn die Information vorliegt, ob der Angerufene auch hinter symmetrischem NAT steckt. Beim Angerufenen liegen diese Informationen rechtzeitig vor. Er kann sich so verhalten, wie beschrieben. Also wenn der Angerufene selbst hinter symmetrischem NAT sitzt und eine SIP-INVITE-Nachricht bekommt mit rport, dann sollte Phoner die interne IP senden, damit der VoIP-Provider einen rtp-Proxy dazwischen schaltet. Beim Anrufer liegt die Info, ob der Angerufene auch hinter einem symmetrischen NAT sitzt, zu spät vor (d.h. erst, nachdem der Anrufer seine INVITE-Nachricht rausgeschickt hat). Oder besteht die Möglichkeit zunächst eine INVITE-Nachricht zu verschicken ohne SDP, um herauszufinden, ob die Gegenstell auch hinter symmetrischem NAT sitzt? Verhält sich der Angerufene wie beschrieben, so ist es nicht nötig, dass der Anrufer die interne IP sendet. Nur Falls der Angerufe auch hinter symmetrischem NAT sitzt und nicht die interne IP sendet, sollte das der Angerufene machen. Es würde die Kompatibilität erhöht werden, wenn der Anrufende die Möglichkeit hätte, bevor er seine SDP-Nachricht verschickt, herauszubekommen, ob der Angerufene ebenfalls hinter einem symmetrischen NAT sitzt und entsprechend die interne IP senden. Aber nötig ist das eigentlich nicht. Eine einfache Möglichkeit wäre auch: Immer die interne IP senden, wenn symmetrisches NAT (und keine Portweiterleitungen) entdeckt wurde. Dann schaltet der VoIP-Provider (hoffentlich) immer einen rtp-Proxy dazwischen und es sollte einfach immer funktionieren. Nachteil ist bloß, dass der Traffic dann einen weiteren Weg laufen muss (eben über den rtp-proxy). Ich denke, das ist erstmal eine gute Zwischen-Lösung, die immer funktioniren sollte (außer mit providern, die nicht automatisch einen rtp-proxy dazwichen schalten, z.B. GMX. Aber mit denen kann zwischen zwei Leuten, die hinter symmetrischem NAT sitzen eh keine Verbindung aufgebaut werden). Hmm so toll ist diese Zwischenlösung doch nicht. Denn wenn der Angerufene nicht hinter symmetrischem NAT sitzt, ist ja durch die Angabe von rport ein Verbindungsaufbau problemlos möglich. Fazit: wenn Phoner einen Anruf erhält mit dem rport-Eintrag ohne Portangabe und selbst hinter symmetrischem NAT ohne Portforwaring hängt, dann sollte es in der SIP und SDP-Nachricht die interne IP verwenden, um den VoIP-Provider zu veranlassen einen rtp-Proxy dazwischen zu schalten. Wenn der VoIP- Provider das dann macht und sich alle Clients nach diesem Schama verhalten, so ist es immer ohne Portweiterleitung möglich, hinter jedem NAT zu voipen. Was hälst Du von dem Vorschlag? - Es müsste sich erst noch genau getestet werden. Gruß, Pfeffer.
|