GNOME Bugzilla – Bug 592363
H323 broken?
Last modified: 2012-11-24 14:09:00 UTC
Hi, I've 2 reports with call failure using H323 and Ekiga 3.2.0. I've not enough skills to understand the debug outputs: 1st one: http://launchpadlibrarian.net/28206951/ekig 2nd one: * Gatekeeper: 198.129.252.168 (Energy Sciences Network (ESnet)) * Calling number: h323:8894@198.129.252.168 (MCU unit, MCU3.es.net) http://launchpadlibrarian.net/30510470/error.log Downstream bug: https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/389485 Best regards, Yannick
Only Craig is able to comment on this. I don't see what's wrong.
Having seen similar symptoms I found that it does work from the command line, see bug# 582412
Created attachment 141867 [details] Output from ekiga -d 4 -c h323:8894@198.129.252.168 2>ekiga_out.log I confirm that using command line to call h323 works. Using UI still doesn't.
The log indicates the GK can not be reached.
Created attachment 164037 [details] Output from ekiga -d 4 2>err.txt Output from calling h323:8843325@192.168.252.168 from GUI
Created attachment 164038 [details] Output from ekiga -d 4 -c h323:8843325@198.129.252.168 2>ekiga_out.log The same call on the same network, this time calling using command line
I've attached two new logs with Ekiga 3.2.6 with a ~1 min interval, first calling from a GUI, second - from a command line. The computer was on the same network during both attempts.
Created attachment 229383 [details] [review] Register H323 accounts on Gatekeepers The H323 endpoints did not registered because all the accounts were processed as SIP endpoints. This patch enable the H323 endpoints registering by validating the protocol name, and if the account is an H323 one, the endpoint is requested to the core and registered. Otherwise, the code follows its normal path.
I confirm with H323 accounts the thread to handle the gatekeeper subscription is not handled at all. With the proposed patch (attachment id=229383) the thread is launched. But still, in my environment I can't handle the H323 conferences correctly yet. Perhaps something else is missing, or I'm forgetting something in the configuration.
Damien, it's you who added in http://git.gnome.org/browse/ekiga/commit/?id=b5249a91 the second part of the if: - if (account.get_protocol_name () != "SIP") + if (account.get_protocol_name () != "SIP" || account.is_active ()) whereas Victor wants to remove it in this patch. Do you have any comment? Otherwise, the patch is good. Victor, have h323 worked in your environment before this patch?!
(In reply to comment #10) > Victor, have h323 worked in your environment before this patch?! Just lately I had to test the gatekeeper registration and it didn't work, that's why I dug and cooked this patch. Before of that, I had never dealt with this scenario.
Victor, do you think that bug #622477 is a duplicate of this bug? Are you sure?
(In reply to comment #12) > Victor, do you think that bug #622477 is a duplicate of this bug? Are you > sure? It looks quite similar, indeed. The trick is to look for GkMonitor message in the opal's log (Gatekeeper monitor). In the attachment 164476 [details] they are there In the attachment 164478 [details] they are not So, something changed from 3.2.6 to 3.9. I did not bisect the code, just traced it and tried to fix it.
*** Bug 622477 has been marked as a duplicate of this bug. ***
This is fixed by a much more complex commit: c1ce2d29bb309e2d00205539289fd8773f387601
I did not fix release 3.2, only the upcoming 4.0 which replaces it.