Re: [Ekiga-list] Ekiga on Ubuntu using DSL

[yannick <sevmek free fr>]

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:500 ekiga net
> 
> 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:500 ekiga net
> 
> 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" <kapetr mizera cz>
> > To: ekiga-list gnome org
> > Subject: Re: [Ekiga-list] Ekiga on Ubuntu using DSL
> > Message-ID: <b1b707c42985dbd10f30023eff82db5e www2-mail volny cz>
> > 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 <sevmek free fr>
> > > To: Ekiga mailing list <ekiga-list gnome org>
> > > 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
> ekiga-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-list
> 


-- 
Me joindre en téléphonie IP / vidéoconférence ?
sip:yannick ekiga net
Logiciel de VoIP Ekiga : http://www.ekiga.org
http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F