GNOME.org
 

Re: [Ekiga-list] ekiga-list Digest, Vol 86, Issue 16


On 09/28/2013 08:00 AM, ekiga-list-request gnome org wrote:

On 27/09/13 19:38, Alex Frase wrote:


On 09/10/2013 10:58 AM, Eugen Dedu wrote:

On 29/08/13 21:11, Alex Frase wrote:

Hi,

(Apologies if this ends up posting twice; I sent it before subscribing
and it may have gotten lost in moderation)

I'm trying to use Ekiga v4.0.1 on Linux Mint 15 (based on Ubuntu, based
on Debian) but can't seem to transmit video via h.323.

I am able to connect to two different h.323 endpoints, and in both cases
I can see and hear the other side just fine, and they can hear me, but
they see only a black screen instead of the video from my side.

I know that the camera works and Ekiga recognizes it, because I can see
my own video preview picture-in-picture. Skype also works just fine for
both audio and video in both directions.

I can also successfully call the ekiga.net echo test
(sip:500 ekiga net), and I see my video echo (with a slight delay vs. my
local video picture-in-picture), so it seems to work okay via SIP. It's
just over h.323 that the other side does not receive my video.

While connected via h.323, the call tooltip says "Codecs: PCMU - H264";
when I call the echo test via SIP, the tooltip instead says "Codecs:
PCMA - H261". I've tried disabling the H264 video codec, but then the
remote side reports not even seeing a black screen -- instead they just
see their own camera on the whole screen, as if no video signal is being
received by them whatsoever. When the H264 codec is enabled, then they
see their video picture-in-picture on top of a black screen. So perhaps
the problem is the H264 encoder producing only black frames?

Sorry to answer so late.

You wrote that you see video on your computer.  Do the others see their
video too?  I ask this because a bug has recently been fixed about not
seeing video on local computer.

Do the other use ekiga too or not?

So when you call them, nobody sees video, but see black as image, is
that right?

It is not an error to have H261 on sip echo test, and H264 with the
others: very likely the others do not support (checked off) H261, hence
the next one on the list (H264) is chosen.  If they check off H264 as
well, then no common video codec is found: this is normal too.

Finally, please send us/me a -d 4 log from your machine when you call
and you see a black image.


A few clarifications first:

- I am testing with two call recipients: one uses a physical Polycom
device and the other is a video bridge service which allows 3-way video
calls, not sure what software/equipment is behind that

- on my end (Ekiga on Linux Mint) I see my own video, and I see remote
video; I do not see any black image on my end

- on their end (Polycom device or video bridge service) they see their
own video (and, via the bridge, eachothers video), but they do not see
my video; they see black where my video should be

- when I disable H264 in the Ekiga preferences then I can call the
Polycom using H261 video and it works correctly (they can see me), but
the video bridge service does not support H261 so that workaround
doesn't work there


However, this turns out to be a NAT/firewall problem and not a codec
problem. I didn't mention that I'm behind a NAT because I had ruled that
out previously, because a) putting my machine in my router's DMZ did
*not* fix it, and b) changing the video codec to H261 instead of H264
*did* fix it.

But apparently my router's DMZ does not do what I thought it did, and
the choice of video codec affects the ports used during the call,
because when I specifically forward all ports (1024-65535) to my local
machine (in lieu of DMZ) then it works. However this also breaks almost
all other network communication, not only for other machines on my local
network, but even for the same machine which has all ports forwarded to
it. Not sure why that is.

I had previously been forwarding only the ports listed in the Ekiga
manual (1720, 3478-3479, 5000-5100, 30000-30010). That avoids
interference with other applications and allows calls to be received by
me, but the other end does not receive my H264 video.

What still puzzles me is that Ekiga on Windows on the same local network
(a different machine behind the same NAT router) does not have this
problem. I assume Windows must be doing something smarter about
automatically configuring port forwarding (UPnP?) but I don't know how
to configure Linux to do the same, or if it even can.

Any suggestions for negotiating the NAT for H264 video?

Hi Alex,

I am puzzled of what happens, I do not understand how all this can
happen.  But having the Windows version of Ekiga working is a useful
information.  Could you send us/me the -d 4 log of the Linux machine
when the others see black, and the -d 4 log of the Windows machine when
the others see you correctly?  Perhaps an error is shown in the log.



Hi,
I work with polycom gear fairly regularly and have had similar issues. If you can connect to the unit with all your local ports forwarded, but not when only the "correct" ports are forwarded, it is probably a polycom thing. In the admin settings on the polycom, there is an option to limit the ports used. As I remember, you can set the port range, but I believe that the defaults under that option will work. Unless you do this, the polycom will use a completely random set of ports and you will see a basic connection start (which happens on udp 1725 I believe) but the connection will never complete since it's sending to a random port that you probably do not have forwarded on your router. This can only be fixed on the polycom end unless you forward all your ports as you mentioned above. For doing calls from my office, I have a a static ip that i dedicate to video conferencing and just hook my polycom directly to it. Certainly not very secure, but I physically disconnect the cable when I'm done.
On the h264 side, I have never ever been able to use it for a video codec successfully with a polycom unit. This is a shame since it would be really nice to have ekiga as a backup for my system. I'm guessing that there is some silly thing in the headers that polycom ignores or refuses to work with. My experience with them is that they are extraordinarily non-open (and in many cases, just plain unhelpful) in their technical specs. If anyone has been able to get this to work, please let me know since being able to use ekiga to diagnose problems with connections to polycom would be a big help in my work.
As far as the bridge goes, it may make a difference on who initiates the call. Many companies that do allow outside video conference connections only do so if they initiate the call. I have one client that swears their firewall does not block me but after working correctly for over a year, it stopped and would only allow calls to me if the bridge initiated the call (this is with all polycom gear, not even attempting to use ekiga). It's very possible that some security rule either in the bridge's firewall or the application itself that won't accept your call.
In general, and please don't take this the wrong way as I am a long time supporter of all Damien's (and other's) work on this great project, I've found that ekiga seems to be moving away from it's formerly strong support of h323 in favor of sip. This of course makes perfect sense since 323 is entirely unsuited for work across the internet and sip works much more reliably. I know that the project is meant to be an internet soft phone and not really a complete video conferencing system. However it used to be really nice to be able to connect up to other 323 hardware platforms like polycom, tandberg and the rest. I also realize that the difficulties are usually because vendors have implemented things in a way to make interoperability difficult so they can keep market share through lock in. Alas, I know that I'm in the minority and with limited developer hours things have to be prioritized to help the greatest number of users. I guess I'm just longing for the old days, back before I became a grumpy old man ;)
In any case, if someone needs to test with polycom gear, let me know and I can set up a unit on a public ip that you can connect to temporarily. 

thanks,

morris

--
Morris Beverly
http://www.avpresentations.com
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]