Le dimanche 28 février 2010 à 12:31 +0100, kapetr a écrit : > Hello, > > this post is for all, which are interesting about NAT problems with Ekiga, >
Hi, Upstream has been notified (the OPAL project), I'm waiting their answer as I've not much time. Still I highly appreciate your effort to work this out :) Best regards, Yannick > especially for: > ---- Yannick Defais > ---- Eugen Dedu > ---- Damien Sandras > > I was go into Deep ... > > As suggested by Yannick, this problem with NAT (even if not symmetric) > and Ekiga could be a problem with NAT implementation on my DSL router. > > It is ZyXEL P-660HW-T3 v2 > > So ... I have also other modems: > - ZyXEL P660RU-T3 and > - HUAWEI EchoLife HG520i > > I have try them all - with the same result! > > RTP goes out, but not in - by calling sip:[email protected] > > Problem of this "blackbox" routers is, that theirs logs are unusable. > > So I did that: > > - I have installed 2. PC with Ubuntu 10.04 > - -"- connect to it the modem in BRIDGE mode, so this host gets public > IP address via PPPoE > - -"- setup on it DHCPd and routing/forwarding with NAT > > [iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o ppp0 -j MASQUERADE] > > > And then, on 1. PC I have run Ekiga (no proxy, 1 (Ekiga) account, network > detection enabled) > > --->>> call to sip:[email protected] > > AND .... I can hear my echo :-) > > So - I have run on 2. PC (NAT-router) wireshark and I see, that linux > NAT maps port to the same (i=5060 to e=5060, i=5072 to e=5072, and so > on). > > *********************************** > In such case, I'm not surprised, that it works :-| > *********************************** > > In such case is not problem, that Ekiga in INVITE packet (SDP) sends > his iPort, then if NAT maps it to the same, then the other side sends > his RTP audio output to (eAddr/iPort) and it goes through. > > So I have changed the linux NAT behaviour with replacing masquerade > rule with: > > [iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o ppp0 -j MASQUERADE > --random] > > So now are the ports of ekiga NOT mapped to the same numbers (e.g. 5062 > to 5062). > > Now is wireshark output at 2. PC (NAT) much more interesting. > > - Ekiga make STUN request for his local RTP port and gets from STUN server > mapping: > e.g. 192.168.10.2/5062 to 88.83.179.98/55906, but as I wrote may times, > Ekiga sends to the other site 88.83.179.98/5062 as the port to which > the other side have to sends his audio. > > Of course it fails, then in NAT table on 2. PC is no mapping for > 88.83.179.98/5062 > coming in. This packets are dropped by 2. PC. > > Maybe acts iptables NAT with "--random" as symetric NAT (so it would > not work even if Ekiga would not be buggy), but this is absolutely not > the Point. The point is, that Ekiga send to the other side bad RTP contact. > > Now I have evidence of that. > > The "hole punching" can't help. > My Ekiga sends punch packets to 96.64.162.35/16584 (RTP contact of other > side get from replay to INVITE), but the other side sends his "punch > packets" and then audio to wrong 88.83.179.98/5062 instead of proper > 88.83.179.98/55906 (which would be remapped by NAT to proper > 192.168.10.2/5062). > > Uff ... > > ************* > conclusion: > ************* > > Ekiga can work only behind such (port) restricted NAT, which maps posts > to the same. > But that behaviour, expecting such things, is faulty. > > So it is not random/exception that Ekiga do not work for me, it is rather > random/exception that Ekiga works for others. > > Even if I am in minority :-) > > ------------- Damien Sandras wrote: > > I'm sorry to contradict you, but it does work :-) > > Sorry, Damien, it does not :-) > > ******* > > With this behaviour of Ekiga could probably not call out 2 people (PCs) > behind the same NAT. Or maybe Yes, but only with Luck. > > If both Ekigas would chose the same RTP port (e.g. 5075) for making call, > then NAT could not map them to the same (5075) for both. > > If e.g. 192.168.10.2/5075 would by "NATed" to 88.83.179.98/5075, then > 192.168.10.3/5075 could not be mapped to 88.83.179.98/5075 too. > > So if 192.168.10.3/5075 would be mapped e.g. to 88.83.179.98/4321, then > 192.168.10.3 would not get audio back. > And maybe ?!?! this audio would get 192.168.10.2 !!! > > > > Thanks to all, > > > I'm looking forward to Yours responses > > --kapetr > > > > > ----- PŮVODNÍ ZPRÁVA ----- > > ------------------------------ > > > > Message: 2 > > Date: Sat, 27 Feb 2010 08:21:32 +0100 (CET) > > From: "kapetr" <[email protected]> > > To: [email protected] > > Subject: Re: [Ekiga-list] Ekiga on Ubuntu using DSL > > Message-ID: <[email protected]> > > Content-Type: text/plain; charset="us-ascii" > > > > Hello, > > > > Thank You very much, yanick, for detailed explanation. > > > > Unfortunately, momentarily I don't understand it - > > probably my bad English > > (and maybe I have "double take" :-). > > > > > > ---------------- yanick wrote > > > Message: 3 > > > Date: Fri, 26 Feb 2010 15:28:27 +0100 > > > From: yannick <[email protected]> > > > To: Ekiga mailing list <[email protected]> > > > Subject: Re: [Ekiga-list] Ekiga on Ubuntu using DSL > > > > > > > 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. > > > > > > > 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. > > > > Of course router refuse them. Whether STUN or UDP_hole_punching > > is > > used, the communication from outside must go to the > > mapped (eAddr:ePort) > > and not to "mixed" (eAddr:iPort) ! > > > > Or does Ekiga expect, that the NAT router should use > > for iPort=5062 ePort=5062 > > ? I hope not ! > > > > > > > > > > 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. > > > > Well ... > > > > in my case: in packet #57 I send UDP from > > 10.6.6.6/5062 (RTP audio) to > > 86.64.162.35/19544, which is the RTP contact of other > > side, which I have > > get in packet #55 (SIP/SDP OK replay (to my INVITE)) > > > > But his packet #57 comes to 86.64.162.35/19544 not > > from port 5062 (iPort), > > but from NATs (ePort). > > > > I can not see difference between that UDP_hole_punching > > and STUN behavior. > > The STUN bind request has the same aim - to resolve > > and primarily OPEN > > UDP port in NAT router. > > > > Now then - where is the problem. If the "echo service" > > would send RTP > > packets to my (eAddr:ePort), they should go through > > ? > > > > With STUN bind it works, and this is absolutely the > > same ?! > > So I can not figure oneself other reason, as the "echo > > service" send > > packets not to (eAddr:ePort). > > > > What do You mean ? > > > > ---------------- > > And another thing > > > > If I have good understand the *** Algorithm *** at > > http://en.wikipedia.org/wiki/UDP_hole_punching > > > > then the UDP_hole_punching technique must be supported > > by every SIP > > server (registrar) to be possible to call there with > > Ekiga. > > > > (acts as the "S" in Algorithm) > > > > Because this server must receive this punch packets > > and then change the > > SDP body of INVITE request (which then redirect to > > his client (target > > of call), then the Called MUST KNOW, to which destination > > have to send > > his RTP audio. He must know the ePort. > > > > If it is so, than I mean it is "dirty" work. On the > > other hand - STUN > > solution, where I send to the other side proper RTP > > (eAddr:ePort) in > > INVITE, seem to me to be clear and clean. > > > > Also if Ekiga do not use STUN for getting his (eAddr:ePort) > > which should > > be send in SDP in INVITE request .... > > > > it can for Example not make direct calls PC-to-PC, > > then it do not sends > > to the other side proper (eAddr:ePort) contact ... > > > > I really do not understand this proprietary technique > > of Ekiga :-( > > And I don't still understand , why Ekiga sends in SDP > > body of INVITE > > packet wrong RTP port (iPort). > > > > > > Thank You very much again, I hope You will help me > > to understand it. > > > > --kapetr > > > > P.S.: If is it possible, could You add to the > > > > https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/517580 > > > > Yours wireshark libcap ? > > > > > > > _______________________________________________ > ekiga-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/ekiga-list > -- Me joindre en téléphonie IP / vidéoconférence ? sip:[email protected] Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
