Le vendredi 26 février 2010 à 10:32 +0100, Damien Sandras a écrit : > Le vendredi 26 février 2010 à 09:01 +0100, kapetr a écrit : > > > I have spend many hours in studying wireshark and twinkle logs, and I > > 99,999% sure, I'm right: Ekiga can't work behind comon ((port)restricted) > > NAT. > > > I'm sorry to contradict you, but it does work :-)
This is not really helpfull Damien. The user claims Ekiga fails to call 500 where twinkle works, we need to understand how, at least, don't you think? kapetr, I'm sorry but in short I agree with Damien: it does work. But not for all "common ((port)restricted) NAT". e.g. It works for Eugen behind a "port restricted NAT", but not work for you. There is no such beast as a "common ((port)restricted) NAT"; the classic NAT classification failed, and the STUN mechanism, understood as "a complete solution to the NAT traversal problem", is now deprecated. Further information about this here: http://tools.ietf.org/html/rfc5389#section-2 Fact is, NAT routers designers failed to get a common agreement about NAT traversal (if they ever intented to get to such goal). NAT routers is just a jungle; they just do as it pleases them and enough of them do not pay attention to a universal NAT traversal solution. How does ekiga work in case of "port restricted NAT"? As you noticed, the signaling part of the protocol (SIP) use some new ports it gets from the STUN server. Thus you can register to ekiga.net and try to place a call. Your issue is with the audio and video streams; once the call is placed you do not get audio or video back as your router just refuse inbound connection using "classic" ports, i.e. in the range 5060-5100. In your case, Ekiga use a technique often referred as "hole punching". e.g. see here: http://en.wikipedia.org/wiki/UDP_hole_punching In your bug report here: https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/517580 in the wireshark log, events number 57 to 60 are "hole punching" (ekiga tries to use 4 ports for audio+video streams, 1 for audio, 1 for video and 2 more additional for statistics about those streams like packet order, packet late etc.) In the view of the classical classification of NATs, this technique should work because "An external host (hAddr:hPort) can send packets to iAddr:iPort [i means internal or local] by sending packets to eAddr:ePort [e means external or remote] only if iAddr:iPort had previously sent a packet to hAddr:hPort." as you can read here for "Port-Restricted cone NAT": http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT But we can take for granted that in your case, there is some additional rules in your NAT router that forbid using some ports, like the ones ekiga tries to use for audio and video streams, even if it tries first "hole punching". For some other people, like Eugen, "hole punching" does work. As I told before, the classical NAT classification is just wrong when applied universally. I hope this will help you understand why such assumption like "NOBODY behind NAT can use Ekiga", as you wrote in your bug report for Ubuntu, is just wrong. It does work for most people behind a NAT if you agree the classical NAT classification, not being universally right, is also not completely wrong and most probably right in most cases, as lots of valuable people defined it, and as some Ekiga users behind NATs can rely on it. Make no mistake, the new way of dealing with NAT: ICE http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment is just another more complex workaround for this bad situation and ultimately recommend using a proxy to establish end-to-end communication. Finally, as I asked on the bug report, could you provide a wireshark log in the report using twinkle to see how it deals in your case? Best regards, Yannick _______________________________________________ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
