Hi,
da ich mir gerade PhonerLite etwas genauer ansehe, ist mir aufgefallen, dass es bei aktivierter UPnP Option den SIP-Keep Alive per STUN Nachrichten alle 30 Sekunden realisiert. Theoretisch könnte man sich dies auch noch mit UPnP einsparen, oder?

Grüße,
neo

Das mit der Inaktivität stimmt, macht meiner auch so. Aber das könnte man dann bestimmt auch mit wiederholten UPnP Anfragen offen halten. Das mit den internen/externen Ports trifft doch auch auf die RTP Port Mappings zu oder? Wo ist der Unterschied?
Das mit der IP ist tatsächlich ein Vorteil, wobei ich gerade gesehen habe, dass Phoner die auch per UPnP (GetExternalIPAddress) abfragt.
Hm, also ganz überzeugt bin ich noch nicht. Ich glaub immernoch, man könnte stattdessen UPnP benutzen. Dann würde man natürlich in der Implementierung nicht mehr zwei Fliegen mit einer Klappe schlagen und müsste um ein paar Bytes zum Internet zu sparen eine UPnP Alternative einbauen.

Ok, überzeugt. In einer idealen Welt wärs sicher möglich, aber aus Kompatibilitätsgründen ist der STUN Keep Alive hier wohl besser. Ich kenne einen anderen Client, der den keep-alive per OPTIONS macht, allerdings ist natürlich STUN viel sparsamer. Auf den RFC bin ich auch schon indirekt über eine Newsgroup Nachricht gekommen, wobei dort was ähnliches gefragt wurde. Nämlich warum es überhaupt funktioniert, dass wenn man keep alive an einen Server mit irgendeinem Port (z.b. sipgate:10000) macht, dass dann trotzdem andere Adressen/Ports dieses offene UDP/NAT-Loch nutzen dürfen. Aber ich schätze, so funktioniert das eben. Bei TCP ists sicher schwieriger.

Stimmt, NAT Typen, ganz vergessen. Angenommen man hätte ein symmetrisches NAT und jemand würde versuchen, dich anzurufen, aber nicht per Festnetz oder mit SIP-Proxy sondern per direkter IP Verbindung. In dem Fall dürfte das ja garnicht gehen, wo wieder mein UPnP ins Spiel kommt D.h., könnte man in dem Fall auf die Proxybenutzung (wird in Phoner eigentlich Proxy benutzt?) verzichten, wenn der SIP Port mit UPnP aktiv ist (und der SIP Provider auch den richtigen Port beim Register benutzt..)?

Edit: Mir ist gerade aufgefallen, dass Phoner vorhin tatsächlich STUN an den SIP Port (wie beschrieben) gemacht hat, aber später (nach Neustart z.B.) nur noch "keep-alive" an den eigentlichen Stunserver durchgeführt hat, was natürlich sinnlos ist und tatsächlich auch gerade dazu geführt hat, dass mich jemand nicht anrufen konnte. Achja, und noch was: beim STUN an den SIP-Port kam keine Antwort zurück, evtl. unterstützt sipgate das nicht? Vielleicht hat Phoner dann einen Fallback auf den normalen Stunserver gemacht, aber kA ob das dann noch was nutzt.

Also irgendwas haut hier nich hin... sorry, dass ich den Thread irgendwie zweckentfremde vom ursprünglichen Thema, aber irgendwie passts schon rein.

Nach außen anrufen kann ich natürlich immer, aber einkommende Anrufe sind nur teilweise möglich, siehe unten. Also, folgendes passiert:

A) STUN an, UPnP aus -> öffentliche IP wird korrekt registriert, aber alle 30 sek erfolgen STUN-Anfragen an stun.sipgate.net:10000 und _nicht_ an den SIP-Server&Port; Ergebnis: Telefon nicht erreichbar nach kurzer Zeit (= klingelt nicht, Pakete kommen nicht an)

B) STUN an, UPnP an -> wie A

C) STUN aus, UPnP aus -> private IP wird im Register geschickt, aber Antwort: '<sip:xxxxx@192.168.20.101:5061>;expires=600;received="sip:83.221.70.xx:5061"', d.h. sipgate ist clever genug und rport/received funktioniert; UND: Phoner sendet kein Keep-Alive, da Sipgate auf dem Sip-Port seinerseits alle 15sek ein keep-alive sendet (kein STUN, nur UDP-Paket an 5061 mit 00000000 als Inhalt), das passierte bei A nicht -> Ergebnis: Telefon bleibt erreichbar!

D) STUN aus, UPnP an -> wie C

Ich habe keine Ahnung, wieso ich es nicht mehr hinkriege, dass STUN über den SIP-Port nach RFC 5626 gesendet wird. Es liegt natürlich daran, dass bei C/D der Kanal noch Aktivität hat durch die eingehenden Keep-Alives von Sipgate, aber gestern wars halt anders, da kamen von Sipgate keine Keep-Alives, soweit ich mich erinnere. Wie auch immer, es funktioniert.

OK, fassen wir mal zusammen.... Phoner registriert sich ohne eingetragenen STUN-Server mit der privaten IP, was nur mit Glück gutgehen kann. Wenn ich aber einen STUN-Server eintrage und damit im Contact alles korrekt wird mit öffentlicher IP, wird ab dann aber nicht STUN auf dem SIP-Port verwendet, sondern STUN mit dem STUN-Server, was schlecht ist, da dann das NAT-Mapping verloren gehen kann (wie in Fall A,B).

In meinem Fall ist die Lösung, auf STUN zu verzichten und die etwas unschöne Angabe der privaten IP im Contact-Feld zu akzeptieren, aber geht's denn nicht besser? Ich glaube, hier ist ein Bug drin. Wenn ein STUN-Server eingetragen wird, sollten dann nicht trotzdem nach der 1. Anfrage an den STUN-Server die Keep-Alives an den SIP-Port gehen? Falls der SIP-Server diese integrierte Form von STUN nicht kennt und dadurch keine Antwort sendet, schadet es ja nicht, da dadurch zumindest das NAT Mapping bestehen bleibt. Allerdings sollte man dann bei fehlender Antwort zusätzlich den angegebenen STUN-Server ab und zu befragen, um einen IP-Wechsel mitzubekommen. Macht das Sinn?