Re: [Ekiga-list] Ekiga.net account with Android 2.3.4 native SIP-client

[Jānis Rukšāns <thedogfarted gmail com>]

On Wed, May 25, 2011 at 10:06 AM, Bart Vandewoestyne
<Bart Vandewoestyne telenet be> wrote:
> On Wed, May 25, 2011 at 02:04:10AM +0300, J??nis Rukš??ns wrote:
>>
>> [...]
>> From the traces it looks like it doesn't support any way to traverse
>> NAT. It is not really a bug, but rather important missing feature,
>> something they should do.
>
> Wait a second... then why do the registrations at sip.poivy.com
> and sip.diamondcard.us work?  Doesn't this mean that my
> SIP-client *is* somehow able to traverse NAT? (I'm afraid i'm
> missing technical background about NAT-traversal here to be able
> to answer this question myself :-(

No, it doesn't mean that the client is able to "traverse" NAT. It
means that either the *server* is able to traverse NAT by relaying the
audio, or you will have no audio in an actual call (either incoming or
both ways).

The technical background is that when you make a call, the phone sends
an INVITE message, telling the other end your IP and the port where to
send audio. However, if you're behind NAT, that IP and port is
generally not reachable from the outside world. Which means that with
no NAT support, the audio sent by the other end will not reach you.
The same applies to the called phone, if it is behind NAT as well, you
will have no audio at all.

There are several ways to counter this:
1) "classic" STUN - the phone can discover the corresponding public IP
and port by contacting a STUN server, and then uses it in the INVITE.
However this doesn't work for more complex types of NAT, and the whole
thing is a bit sketchy. Therefore "classic" STUN has been deprecated
for some time.
2) ICE - instead of contacting a dedicated STUN server, the endpoints
communicate between themselves to find out each others public IPs and
ports used for audio. This works in most cases, except when both
parties are behind a very restrictive NAT.
3) Dedicated media relay server - instead of sending audio directly to
the other party, the audio is sent through a dedicated server with a
public IP. This works even with no NAT support in the client, but is
very costly to the provider (in terms of bandwidth, hardware and
money).

If the phone supports either STUN or ICE, it is usually indicated by a
public IP in the Contact address. I'm pretty sure diamondcard.us have
a relay server, thus they don't care whether the IP is public or
private. Ekiga.net doesn't have a relay server, therefore it's
reasonable that it rejects registrations with private IPs.

Cheers
-- 
Ian