After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 582412 - h323 url works through cli, not through ui
h323 url works through cli, not through ui
Status: RESOLVED OBSOLETE
Product: ekiga
Classification: Applications
Component: general
3.2.x
Other Linux
: Normal major
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-12 21:28 UTC by Peter Giles
Modified: 2009-09-22 16:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
ekiga log file (130.75 KB, text/plain)
2009-05-13 16:58 UTC, Peter Giles
Details
ekiga log file of successful connection (376.18 KB, text/plain)
2009-05-13 16:59 UTC, Peter Giles
Details
Debug output of a failed call (41.29 KB, application/octet-stream)
2009-09-18 11:55 UTC, Simppa
Details
Failed call with the latest stable trunk (55.83 KB, text/plain)
2009-09-22 14:19 UTC, Simppa
Details
Output from wireshark during a failed H323 call. (61.19 KB, text/plain)
2009-09-22 14:21 UTC, Simppa
Details

Description Peter Giles 2009-05-12 21:28:04 UTC
I can connect to our team's h323 conference server from the command line like so:

ekiga -c h323:our.h323.server

but if I put the same url in the ui and hit the phone button (or return) then I get a status message on the bottom of the window stating  "The Gatekeeper cleared the call".

I tried to enable debug logging with the -d flag, but in testing the above functionality nothing was printed until I exited.
Comment 1 Eugen Dedu 2009-05-13 12:00:38 UTC
Please try "ekiga -d 4 2>out" and send us the out file.
Comment 2 Peter Giles 2009-05-13 16:58:17 UTC
Created attachment 134585 [details]
ekiga log file

failed to connect when the url was specified via the GUI
Comment 3 Peter Giles 2009-05-13 16:59:50 UTC
Created attachment 134586 [details]
ekiga log file of successful connection

connection was successful when url was specified from the command line
Comment 4 Peter Giles 2009-06-16 18:31:39 UTC
Is there still additional info needed?  Let me know what I can provide.  Thank you! -Peter
Comment 5 Peter Giles 2009-07-29 15:50:04 UTC
I can provide a very simple step by step on how to reproduce this bug if someone has time to confirm it.  I will need to provide these instructions directly via email though.
Comment 6 Yannick 2009-09-05 11:44:55 UTC
Hi,

Seems this issue is affecting 3.2.0 and 3.2.5.

Downstream report:
https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/389485

Best regards,
Yannick
Comment 7 Damien Sandras 2009-09-13 15:57:14 UTC
Peter, this does not make sense unfortunately.

In the case where it does not work, Ekiga tries to authenticate with the gatekeeper, which rejects the authentication.
In the case where it works, Ekiga does not try to authenticate at all.

I ignore why.

However, I see it is trying to open a connection with gillesp specified as origin.
Where did you put gillesp in the configuration ?
Aren't you supposed to register to the gatekeeper before calling it ? (ie have an H.323 account active)
Comment 8 Peter Giles 2009-09-14 17:08:13 UTC
I'm not sure what is going on under the hood to explain that, but I am entering the url 'h323:xxx.xxx.xxx.xxx' into the input field and clicking the 'connect' button.  I've done nothing to suggest to Ekiga that it should authenticate.  Perhaps that is telling as to where the bug lies.

I recall setting up an account with ekiga.net when I first set Ekiga up (likely that was several versions ago).  Perhaps that info is being used for some reason.  Curiously though, digging through the 'Accounts' and 'Preferences' UIs, I see no reference to user names or ekiga.net settings.  Maybe I just don't know where to look.

As an aside, I notice that when I hit the connect button the url changes briefly to 'pc:tcp$xxx.xxx.xxx.xxx:xxxx' before I see 'The Gatekeeper cleared the call' in the status message on the bottom of the window at which point the url is reset to 'sip:'.  I doubt that's very helpful, but I thought I would mention it.
Comment 9 Eugen Dedu 2009-09-14 19:56:41 UTC
(In reply to comment #8)
> As an aside, I notice that when I hit the connect button the url changes
> briefly to 'pc:tcp$xxx.xxx.xxx.xxx:xxxx' before I see 'The Gatekeeper cleared

Maybe this is the answer: tcp is used instead of udp!  And tcp support is not yet well tested.
Comment 10 Damien Sandras 2009-09-14 20:34:39 UTC
H.323 is TCP.
Comment 11 Damien Sandras 2009-09-18 06:21:32 UTC
Peter, can you paste the result of :
gconftool -g /apps/ekiga/protocols/accounts_list
Comment 12 Snark 2009-09-18 06:31:14 UTC
Uh... aren't the password readable there!?
Comment 13 Simppa 2009-09-18 11:53:10 UTC
I have related H.323 experience:

I Registered to a gatekeeper, made a GDS call, which worked fine.
I changed some details of my account.
On the following day I am no more able to make calls.

Notes:
 - confirm 'pc:tcp$xxx.xxx.xxx.xxx:xxxx' sighting
 - packet sniffer sees no traffic to the gatekeeper
 . update to latest ekiga version does not help.
 - gconftool -g /apps/ekiga/protocols/accounts_list
[1|1|e06b2d0b-fea1-de11-9b06-00234ee1c003|vp3206|H323|193.166.3.123|193.166.3.123|00358945722335555|00358945722335555| |3600]
 - ubuntu 9.04
 - the Command line trick does not help. (Possibly because I use a GDS-number as address.)
Comment 14 Simppa 2009-09-18 11:55:52 UTC
Created attachment 143436 [details]
Debug output of a failed call
Comment 15 Peter Giles 2009-09-18 16:08:48 UTC
Here it is:

gilesp@yage:~$ gconftool -g /apps/ekiga/protocols/accounts_list
[1|1|xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|ekiga.net SIP Service|SIP|ekiga.net|ekiga.net|gilesp@ekiga.net|gilesp@ekiga.net|xxxxxxx|3600,1|1|xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|?? GK|H323|xx.xx.edu|xx.xx.edu|Giles\, Peter|3600|0|0]

Okay, now I see the accounts in the ui.  Don't know how I missed it before.   I have now removed the ?? GK account:

gilesp@yage:~$ gconftool -g /apps/ekiga/protocols/accounts_list
[1|1|xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|ekiga.net SIP Service|SIP|ekiga.net|ekiga.net|gilesp@ekiga.net|gilesp@ekiga.net|xxxxxxx|3600]

and tried to connect again again.  Not sure if the "under the hood" view has changed, but from the ui side it's the same.  I see the pc:tcp$xxx.xxx.xxx.xxx:xxxx address for a moment, then "The Gatekeeper cleared the call" on the status bar.  I can attach another "ekiga -d 4 2>out" if you'd like.
Comment 16 Damien Sandras 2009-09-18 18:09:24 UTC
Yes, I would appreciate another updated -d4 output.
Comment 17 Damien Sandras 2009-09-18 18:35:51 UTC
simppa: I tried your settings and number, and it works from here.

Can you try latest stable trunks of ptlib/opal/ekiga?
Comment 18 Peter Giles 2009-09-18 20:48:30 UTC
After restarting and trying to connect again it is working for me.  I guess it was the account that was creating the problem.  Thank you very much for the assistance!
Comment 19 Snark 2009-09-18 20:53:54 UTC
Closing then...
Comment 20 Damien Sandras 2009-09-19 08:29:13 UTC
Excellent!
Comment 21 Simppa 2009-09-22 10:46:54 UTC
(In reply to comment #17)
> simppa: I tried your settings and number, and it works from here.
> 
> Can you try latest stable trunks of ptlib/opal/ekiga?

I have had no success in establishing a call :-(

I tried to compile the svn version of ptlib/opal/ekiga, per 
http://wiki.ekiga.org/index.php/Compile_your_own_SVN_version_of_Ekiga_on_Ubuntu
I successfully compilad the libraries, but was unable to compile ekiga from trunk or from the latest tag. So, how do I recognise latest *stable* trunk?

The trunk ekiga compilation dies here:

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../lib -I../../../../lib/gmconf -I../../../../lib/toolbox/ -I../../../../lib/engine/ -I../../../../lib/engine/account -I../../../../lib/engine/addressbook -I../../../../lib/engine/chat -I../../../../lib/engine/hal -I../../../../lib/engine/presence -I../../../../lib/engine/protocol -I../../../../lib/engine/videooutput -I../../../../lib/engine/videoinput -I../../../../lib/engine/audioinput -I../../../../lib/engine/audiooutput -I../../../../lib/engine/framework -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DPTRACING=1 -D_REENTRANT -fno-exceptions -I/usr/include/opal -DPTRACING=1 -D_REENTRANT -flibtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../lib -I../../../../lib/gmconf -I../../../../lib/toolbox/ -I../../../../lib/engine/ -I../../../../lib/engine/account -I../../../../lib/engine/addressbook -I../../../../lib/engine/chat -I../../../../lib/engine/hal -I../../../../lib/engine/presence -I../../../../lib/engine/protocol -I../../../../lib/engine/videooutput -I../../../../lib/engine/videoinput -I../../../../lib/engine/audioinput -I../../../../lib/engine/audiooutput -I../../../../lib/engine/framework -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DPTRACING=1 -D_REENTRANT -fno-exceptions -I/usr/include/opal -DPTRACING=1 -D_REENTRANT -fno-exceptions -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT pcss-endpoint.lo -MD -MP -MF .deps/pcss-endpoint.Tpo -c ../../../../lib/engine/components/opal/pcss-endpoint.cpp  -fPIC -DPIC -o .libs/pcss-endpoint.o
In file included from ../../../../lib/engine/components/opal/pcss-endpoint.cpp:42:
../../../../lib/engine/components/opal/opal-call-manager.h:158: error: conflicting return type specified for ‘virtual OpalCall* Opal::CallManager::CreateCall()’
/usr/include/opal/opal/manager.h:1454: error:   overriding ‘virtual ptlib_virtual_function_changed_or_removed****** OpalManager::CreateCall()’
In file included from ../../../../lib/engine/components/opal/opal-call-manager.cpp:41:
../../../../lib/engine/components/opal/opal-call-manager.h:158: error: conflicting return type specified for ‘virtual OpalCall* Opal::CallManager::CreateCall()’
/usr/include/opal/opal/manager.h:1454: error:   overriding ‘virtual ptlib_virtual_function_changed_or_removed****** OpalManager::CreateCall()’
/usr/include/opal/rtp/rtp.h:1158: warning: ‘PFactoryLoader::RTP_Encoding_loader’ defined but not used
/usr/include/opal/opal/recording.h:179: warning: ‘PFactoryLoader::OpalWAVRecordManager_loader’ defined but not used
/usr/include/opal/h323/h235auth.h:223: warning: ‘PFactoryLoader::H235AuthSimpleMD5_loader’ defined but not used
/usr/include/opal/h323/h235auth.h:264: warning: ‘PFactoryLoader::H235AuthCAT_loader’ defined but not used
/usr/include/opal/h323/h235auth.h:305: warning: ‘PFactoryLoader::H235AuthProcedure1_loader’ defined but not used
no-exceptions -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT pcss-endpoint.lo -MD -MP -MF .deps/pcss-endpoint.Tpo -c ../../../../lib/engine/components/opal/pcss-endpoint.cpp  -fPIC -DPIC -o .libs/pcss-endpoint.o
In file included from ../../../../lib/engine/components/opal/pcss-endpoint.cpp:42:
../../../../lib/engine/components/opal/opal-call-manager.h:158: error: conflicting return type specified for ‘virtual OpalCall* Opal::CallManager::CreateCall()’
/usr/include/opal/opal/manager.h:1454: error:   overriding ‘virtual ptlib_virtual_function_changed_or_removed****** OpalManager::CreateCall()’
In file included from ../../../../lib/engine/components/opal/opal-call-manager.cpp:41:
../../../../lib/engine/components/opal/opal-call-manager.h:158: error: conflicting return type specified for ‘virtual OpalCall* Opal::CallManager::CreateCall()’
/usr/include/opal/opal/manager.h:1454: error:   overriding ‘virtual ptlib_virtual_function_changed_or_removed****** OpalManager::CreateCall()’
/usr/include/opal/rtp/rtp.h:1158: warning: ‘PFactoryLoader::RTP_Encoding_loader’ defined but not used
/usr/include/opal/opal/recording.h:179: warning: ‘PFactoryLoader::OpalWAVRecordManager_loader’ defined but not used
/usr/include/opal/h323/h235auth.h:223: warning: ‘PFactoryLoader::H235AuthSimpleMD5_loader’ defined but not used
/usr/include/opal/h323/h235auth.h:264: warning: ‘PFactoryLoader::H235AuthCAT_loader’ defined but not used
/usr/include/opal/h323/h235auth.h:305: warning: ‘PFactoryLoader::H235AuthProcedure1_loader’ defined but not used
Comment 23 Simppa 2009-09-22 14:16:16 UTC
Thanks! Compiled successfully. No help :-(

So, I have the latest stable trunk now.
Nothing really changed. Ekiga still says "the gatekeeper cleared the call".
Below You'll find another debug output.

What's funny, is that ekiga tries to call ekiga.net with SIP-protocol, but never sends anything to the H.323 gatekeeper. All packets from the NIC connected to the internet are in an attachment below.

gconftool -g /apps/ekiga/protocols/accounts_list
[1|1|b06ad9a1-e8a5-de11-931f-00234ee1c003|vidPark|H323|193.166.3.123|193.166.3.123|003589457223394510123|003589457223394510123| |3600]

Also, still no help from using the CLI.
Comment 24 Simppa 2009-09-22 14:19:13 UTC
Created attachment 143702 [details]
Failed call with the latest stable trunk

Debug output of a ekiga H323 call with GDS. The call fails. GUI tells: 'cleared by the gatekeeper'
Comment 25 Simppa 2009-09-22 14:21:20 UTC
Created attachment 143703 [details]
Output from wireshark during a failed H323 call.

The workstation never sends anything to the dedicated gatekeeper
(193.166.3.123), but tries to talk to ekiga.net.
Comment 26 Damien Sandras 2009-09-22 14:39:02 UTC
This seems to be the problem:	
Write PDU failed (0): No such file or directory
Comment 27 Eugen Dedu 2009-09-22 16:47:32 UTC
The involved code is in opal, src/h323/h323trans.cxx :

PBoolean H323TransactionPDU::Write(H323Transport & transport)
{
  PPER_Stream strm;
  GetPDU().Encode(strm);
  strm.CompleteEncoding();

  // Finalise the security if present
  for (H235Authenticators::iterator iterAuth = authenticators.begin(); iterAuth != authenticators.end(); ++iterAuth)
    iterAuth->Finalise(strm);

  H323TraceDumpPDU("Trans", PTrue, strm, GetPDU(), GetChoice(), GetSequenceNumber());

  if (transport.WritePDU(strm))
    return PTrue;

  PTRACE(1, GetProtocolName() << "\tWrite PDU failed ("
         << transport.GetErrorNumber(PChannel::LastWriteError)
         << "): " << transport.GetErrorText(PChannel::LastWriteError));
  return PFalse;
}