Re: [Ekiga-list] no video: is video transferred on separate connection?
- From: Jānis Rukšāns <thedogfarted gmail com>
- To: Ekiga mailing list <ekiga-list gnome org>
- Subject: Re: [Ekiga-list] no video: is video transferred on separate connection?
- Date: Mon, 28 Jun 2010 10:58:21 +0300
On Thu, Jun 24, 2010 at 9:49 AM, Zhang Weiwu <zhangweiwu realss com> wrote:
> The page contain a lot of useful information, but still reads confusing to
> me.
> Quote from the wiki page:
>
> what ports are used (RTP audio/video, SIP etc.):
>
> RTP AUDIO stream is usually 5061/5062 (the first port is the steam itself,
> the second is for statistics; only the first one really matter. Maybe the
> second one does improve quality under some circumstances)
>
> RTP VIDEO stream is usually 5063/5064 (same as for audio)
Actually it is 5062/5063 for audio and 5064/5065 for video (even port
for RTP and odd for RTCP). This should be fixed in wiki.
> This is rather unclear to me. For example, for video "5063/5064" have 4
> different meaning to me:
>
> does it mean the receiver will use port 5064 and sender using 5063? Like in
> ftp and nfs protocol, the port of both ends of the connection is restricted
> to certain ports.
> does it mean it works either 5063 or 5064 is open for listening on firewall
> setting?
> does it mean it works if both of 5063 and 5064 are open for listening on
> firewall setting?
> does it mean the connection establishing end of ekiga will try connect to
> 5063, and failing that, try to connect to 5064? And the connection receiving
> end of ekiga will listen on both?
It means what it says - "the first port is the stream itself, the
second is for statistics". That is, Ekiga will listen for video on
port 5064 and AFAIK send from port 5064 as well. The second port is
used for stream statistics and to control QoS. Some codecs might
benefit from that but generally it's not a big deal if it is closed.
One could say it works if port 5064 is open on firewall (but that's a
wee bit oversimplification).
More correctly a port range is used (by default 5060 through 5100) and
each stream (audio or video) takes two ports - even for the media and
odd for statistics. IIRC if you're behind NAT each account also uses
one port. So if you're behind NAT and have one account configured,
Ekiga will use port 5060 for SIP signalling, 5062 for audio and 5064
for video. If there are two calls (eg the first one is put on hold),
ports 5066 and 5068 will be used for audio and video for the second
call, etc.
So if you have only one account and plan on having only one call at a
time, you should be safe with opening/forwarding ports 5060, 5062 and
5064.
> More confusing is it did not say who connects to whom. Suppose the quoted
> wiki means 5063 is a listening port for video, then should the caller
> connect to callee's port 5063, or should the video sender connect to the
> video receiver's port 5063?
Noone connects nowhere. SIP uses UDP for audio and video, there is no
connection, and it doesn't matter who is caller and who is callee.
Assuming port 5064 is used for video, Ekiga just listens on incoming
UDP packets on port 5064 and sends them to wherever the other end asks
(if the other end is using Ekiga too, it is very likely that it will
be 5064).
> They are not the same thing! For example in my
> case I am being called by my colleague but I have camera, he doesn't, so I
> am callee and video sender, it raises the question should I listen on 5063
> or him. For me to receive phone call and send video to caller, whose
> NAT/firewall setting should I touch? It might be basic knowledge to some but
> really confusing to people who just want to use it.
The ports listed on wiki (well, as I said - they're not correct) are
the ones *you* should open/forward if you want to *receive* video
and/or audio, if *you are* behind symmetric NAT. If your colleague is
behind symmetric NAT and wants to receive video, he/she has to
open/forward ports on his/her firewall. The ports depend on the client
used, if it's Ekiga, they're 5060 for SIP signalling, 5062 for audio
and 5064 for video.
> P.S. this is about the 5th time I try to use ekiga. I try it about once a
> year since 2005 with that year's latest version, and never managed to make
> it work on anything beyond text message, neither audio nor video. Despite
> trying in multiple different networks, I am usually reported my NAT is
> symmetric. Since the article says most NAT are not symmetric, I must assume
> there is something wrong in China, since we have too much particularity
> here. I guess it's a bit too complicated to me. Even though being computer
> science graduate I never understood how this thing work (yes, I had many
> understandings, but each conflict with practical observation), but still
> trying very hard to figure out how to use it. Or, is it easier to fall back
> to old H.232? I remember I used to use video stuff without knowing how it
> worked in campus back in 2003, on NetMeeting that came default with Windows
> 2000, but I could not recall if there was NAT firewall by that time thus not
> sure what really bring so much trouble, NAT or new protocol.
Unfortunately most consumer grade routers and wireless access points
are symmetric NAT. At least here (Eastern Europe) I have yet to see an
off-the-shelf "wifi router" that wasn't symmetric NAT. And one tend to
have very restrictive firewall policies at work too. Just like SIP,
H.323 uses RTP for audio and video (it was originally designed for LAN
use only) and the same NAT issues apply to H.323 as well.
--
Ian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]