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

["kapetr" <kapetr mizera cz>]

Hello, 

this post is for all, which are interesting about NAT problems with Ekiga,

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 ?
> 
>