Re: [Ekiga-list] NAT issues with VoIP clients

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

Jānis Rukšāns wrote:
> On Thu, Mar 18, 2010 at 3:28 PM, My Name <legenyes hotmail com> 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