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 _______________________________________________ ekiga-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/ekiga-list
