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 580078 - Ekiga doesn't determine the remote uri and name correctly anymore
Ekiga doesn't determine the remote uri and name correctly anymore
Status: RESOLVED FIXED
Product: ekiga
Classification: Applications
Component: Call stack
GIT master
Other All
: Normal critical
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-24 07:27 UTC by Snark
Modified: 2009-05-19 20:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Snark 2009-04-24 07:27:35 UTC
I tried to call sip:foo@ekiga.net ; my call history ended with a passed call to a name "foo@ekiga.net" and uri "pc:udp$ekiga.net:5060", which is definitely wrong!
Comment 1 Snark 2009-04-24 08:28:13 UTC
I checked that in lib/engine/components/opal/opal-call.cpp, the parse_info function has the right data.
Comment 2 Snark 2009-04-24 08:39:54 UTC
Ah, ha! I made the parse_info method print when it's called, and here we have :
remote_party_name = 
remote_uri = pc:udp$ekiga.net:5060
remote_party_name = foo@ekiga.net
remote_uri = sip:foo@ekiga.net
remote_party_name = foo@ekiga.net
remote_uri = pc:udp$ekiga.net:5060

What did I do? I just called sip:foo@ekiga.net... and that method was called three times, only the second one giving the correct results!
Comment 3 Eugen Dedu 2009-04-24 08:43:58 UTC
I noticed me too that, after pressing green button, the URL bar shows an unuseful pc:udp... for 1-2 seconds...
Comment 4 Snark 2009-04-24 09:03:03 UTC
Let's hope Damien can comment, because it would take me a very long time to study that part of the woods...
Comment 5 Damien Sandras 2009-04-24 09:15:47 UTC
That's a new problem. Something changed in OPAL affecting this. The problem is that you do not necessarily have all the information depending on when that function is called. 

It took me a very long time to figure out all cases : missed call, answered incoming call, answered outgoing call, unanswered outgoing call and getting it right for all those cases.
Comment 6 Snark 2009-04-24 10:57:31 UTC
Oh -- an upstream change would indeed explain why looking in ekiga's commit log didn't turn up anything useful.
Comment 8 Snark 2009-05-19 20:14:27 UTC
Damien fixed it!