Re: [Ekiga-list] usability

[Yannick <sevmek free fr>]

Le jeudi 05 septembre 2013 à 14:21 +0900, fred k a écrit :
> > ... you do *not* have [to] do/know all that if you use a
> commercial...
> I have a question. When you use commercial SIP provider, do you mean
> your voice/video/data goes through a server at the SIP provider before
> reaching called party (i.e., non-peer-to-peer model)? If this is the
> case, why NAT problems goes away? (Pointer to this ML archive or
> another appreciated to save your time.) My understanding is that in
> Ekiga (or SIP in general, possibly), called party address to IP
> address:port translation is done at the SIP server and following
> call-setup/negotiations and payload communications are peer-to-peer. 

I assume he was referring to a SIP proxy, i.e. the commercial SIP
provider provide a proxy to relay the communications (audio, video, i.e.
the RTP steams). In this case it is not end-to-end anymore, but it is
part of the SIP specification. This can solve the NAT issue.

The solution to avoid having a commercial provider and solve the NAT
issue is something like the p2psip effort:
https://en.wikipedia.org/wiki/P2psip
http://www.ietf.org/mail-archive/web/p2psip/current/maillist.html

Beside, we could improve the ekiga tools for supporting NAT with an ICE
implementation:
https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment
Even if it will cover most cases and improve Ekiga, ICE will probably
not be enough without a proxy somewhere, which p2psip try to implement
directly in all clients.

And I doubt IPV6 will solve this issue, as it will probably remains bad
habits from some people to put NAT, justifying it by "security", even if
the specification try explicitly to avoid NATs. Still IPv6 will
certainly help a lot.

Regards,
Yannick