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 576486 - Implement Ekiga-callto handling of telephone numbers
Implement Ekiga-callto handling of telephone numbers
Status: RESOLVED WONTFIX
Product: ekiga
Classification: Applications
Component: Call stack
3.0.x
Other All
: Normal enhancement
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2009-03-23 20:59 UTC by Alec Leamas
Modified: 2020-06-06 16:29 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Sketch for a backend. (12.59 KB, application/x-compressed-tar)
2009-03-23 21:02 UTC, Alec Leamas
Details
Ekiaga-callto stories (3.17 KB, text/plain)
2009-03-25 11:10 UTC, Alec Leamas
Details
User stories, with added comments (4.23 KB, text/plain)
2009-03-25 22:19 UTC, Alec Leamas
Details
Refactored, Doxygen-clean revised version (11.83 KB, application/x-compressed-tar)
2009-03-30 09:14 UTC, Alec Leamas
Details

Description Alec Leamas 2009-03-23 20:59:44 UTC
That Ekiga should be able to handle ordinary phone numbers as they are present in documents, email, PIM databases etc. This means that formatting characters should be removed, and missing country code should be added in the context of user's country. Bottom line is that Ekiga should be able to call to numbers like 0920-346777, 0046 (0)78-33 44 55,  1.800.567.345 etc.
Comment 1 Alec Leamas 2009-03-23 21:02:04 UTC
Created attachment 131217 [details]
Sketch for a backend.

See README for details.
Comment 2 Snark 2009-03-24 08:03:12 UTC
The engine is already extensible for new types of uri :
- in the PresenceCore interface, using the method void add_supported_uri (sigc::slot1<bool,std::string> tester);, you can make known to the engine that some uri is supported ;
- in the PresenceCore interface, using the method void add_presentity_decorator (gmref_ptr<PresentityDecorator> decorator);, you can make the actions you support on such an uri available for each and every uri-based contact ;
- in the ContactCore interface, using the method void add_contact_decorator (gmref_ptr<ContactDecorator> decorator);, you can make the actions you support on such an uri available for each and every contact.
Comment 3 Alec Leamas 2009-03-24 12:11:02 UTC
OK, there will be some questions...

- The add_supported_uri seems reasonable: I just provide a slot1 closure testing the supplied string, and returns true if there is no '@', which means that it's something to make a try on(?)

- The add_presentity_decorator: where is the menu referenced in the current
Ekiga GUI? Is there hooks to rewrite the url somewhere?( yes, there are, but don't tell me this is easy for a newbie...)

- I think I'll leave the contacts stuff aside for the moment, it's a bit to manage anyway.

- Here is some stuff I should call. But how do I get some control flow, who calls me?

Sorry for asking, but I really need some start help. It might possibly be an idea to move this discussion away from the bug, it's a little bit out of scope for  bugzilla(?)

--a
Comment 4 Snark 2009-03-24 21:07:33 UTC
If you look at the presentity decorator, you'll see you get the Presentity, for which uri you're supposed to add actions, and the MenuBuilder ; how a MenuBuilder works is documented in lib/engine/framework/menu-builder.h, and you'll find an example of a PresentityDecorator in lib/engine/components/opal/sip-endpoint.h (you'll even see it's also a ContactDecorator, and both methods call the same method to provide the actual "Call"/"Transfer" and "Message" actions.

I hope it answers your questions : feel free to ask for more.
Comment 5 Alec Leamas 2009-03-25 11:09:22 UTC
This is a somewhat tricky situation, I think we have dived to deep into details before reaching an agreement what we want to do. It's my own fault, I presented this RFE in a clumsy way, and also gave the wrong reply #3.  I want to step back  little, reach some kind of agreement on what we want to do, and what's possible within limited resources.

So: I spent a late evening writing some stories/use cases which I enclose. For two of them I think I think understand how things should work, but I don't know if it's feasible. For the two other, I havn't really the idea how this should work at all.

If we could modify these stories in a way which are reasonable both from a user and implementation perspective I think it would be Good Thing. Or?
Comment 6 Alec Leamas 2009-03-25 11:10:25 UTC
Created attachment 131337 [details]
Ekiaga-callto stories
Comment 7 Snark 2009-03-25 20:57:04 UTC
I'd rather have had the stories within comments.

Concerning what we show to the user about the uri : I already discussed (was it with Damien?) the idea of just removing that uri bar...

For the rest, I must admit that I don't exactly get what you want...
Comment 8 Alec Leamas 2009-03-25 22:19:25 UTC
Created attachment 131385 [details]
User stories, with added comments
Comment 9 Alec Leamas 2009-03-26 08:26:40 UTC
Thinking more about it, I think the problem from a UI perspective is how to handle the "paste" situation: what should the user do after pasting something like "+47 (0)55-66 77 77" into the URL window to place a call? There must be a menu entry/button/whatever to clean up this number to a proper url.  How is this accomplished in the best way?

As for the other cases, I think I now have a reasonable understanding how to integrate them with small or no impact at all on the UI. The exception is if just the number should be displayed,  but this is,  as noted in comment #7, a separate issue.
Comment 10 Alec Leamas 2009-03-30 09:14:25 UTC
Created attachment 131691 [details]
Refactored, Doxygen-clean revised version

This is using Trace/Assert.
Comment 11 Alec Leamas 2009-03-30 09:18:38 UTC
The User Stories attachment is obsoleted by http://mumin.dnsalias.net/ekiga-callto-ui/stories.html .
Comment 12 Duncan Lithgow 2009-11-13 08:26:17 UTC
From downstream Ubuntu Launchpad at https://bugs.edge.launchpad.net/ubuntu/+source/ekiga/+bug/481787

At the moment if I put in a regular telephone number in the format +12 3 45678945 Ekiga will not only play stupid and ignore everything after the first space, but it will actually delete everything after the first space. So actually ringing out with ekiga doesn't just work.

I suggest off the top of my head one of two solutions: a.) ignore non number characters and treat them as if they are not there, or b.) check entered telephone numbers for correctness before allowing them to be used, then give guidance as needed.
Comment 13 Yannick 2010-06-15 04:07:44 UTC
An article with some code for the logic based on how it's done in Maemo 5 (I've no clue how good this is):

http://blog.barisione.org/2010-06/handling-phone-numbers/
Comment 14 André Klapper 2020-06-06 16:29:27 UTC
Ekiga is not under active development anymore:
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273

Ekiga saw its last release 7 years ago. The last code commits were 4 years ago.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.