On Wed, May 25, 2011 at 10:06 AM, Bart Vandewoestyne <[email protected]> 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 _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
