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

["kapetr" <kapetr mizera cz>]

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 ?