Jānis Rukšāns wrote: > On Thu, Mar 18, 2010 at 3:28 PM, My Name <[email protected]> wrote: > >> The article says, "For that, before registering, A and B must discover their >> public IP addresses (corresponding to NATA and NATB respectively) and send >> it to ekiga.net, so that they can be contacted afterwards (*TODO why >> ekiga.net cannot simply use ip/port from ip packet header?*)". >> >> Indeed, this requires explanation. This is surely the job of the SIP >> server. > > It is possible with rport and friends but it works in a bit different > way. The server cannot use IP/port from the packet because there can > be one or more proxy between the client and server and the IP/port in > the packet will be that of the last proxy. Thus the client still has > to discover it's public IP but it can be done w/o STUN. > > First the client sends a REGISTER with private IP in *both* Contact > and Via, Via also containing rport parameter. The server will reject > the request, adding received and rport parameters with the IP and port > from the packet. This is done by each proxy in the path, therefore > when the client receives the response, the top (and only one) Via > contains the external IP and port. Now the client can resubmit the > REGISTER with the external IP and port in the Contact (but private IP > in Via), which should be accepted. With some more magic (which > requires the private address in Via) this can work with almost any > type of NAT. > > Notice that this is how Linphone and Nokia N900 (and probably other > clients) work. However ekiga.net rejects REGISTERs with private Via, > which breaks these clients. > >> I certainly do not need a separate STUN server to use a Web >> browser. The Web site has no trouble determining my external IP address. > > You don't need STUN to use a web browser because with web browser > you're making only outgoing connections - from the browser to the > server. NEVER the other way around, it is not even possible. The web > site has no trouble determining your external IP because it doesn't > have to. Among other reasons why people are using HTTP proxies, Tor > and similar tech is to hide their IP address - the web server can do > without it. So don't compare apples to oranges.
Ok, thanks for the info (sorry for the delay), I added it to the wiki (http://wiki.ekiga.org/index.php/Understanding_NAT/firewall_issues_with_SIP_clients_%28eg_ekiga%29#Realistic_network.2C_with_NAT). Is there any reason for ekiga.net to refuse private IP addresses? Maybe because, if I understand correctly, even if received and rport allow to find out the correct public address/port, they still do not solve the symmetric nat problem for initiating communication, is that right? -- Eugen _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
