GNOME Bugzilla – Bug 334470
Address books - call phone numbers
Last modified: 2008-08-10 19:43:00 UTC
It's currently not possible to call phone numbers directly from the address book (for example from Evolution's addresses). Most people probably don't know what a "VoIP URL" should look like - they have an account at some SIP provider and want to call phone numbers from their address book. Cheers, Thomas Gelf
What would you suggest? I could display all phone numbers supported by Evolution, but in that case, how would the user choose : - the number to call - the provider to use ? Some users will probably also want to store voip urls like sip:dsandras@ekiga.net.
For contacts with more than one phone number it should obviously be up to the user to choose the right one to call. And as long as there is no LCR in Ekiga (is it planned? I prefer LCR on server side - but others may think different) the primary account should be used for all calls to numbers that are not "VoIP URLs". 001 555 123456 -> sip:001555123456@primary.provider.tld This should work with most SIP providers - maybe add the possibility to define prefixes.
Since it's tightly connected with this I'm going to make this comment here rather than open a new feature request: RFC3966 defines the "tel:" URI which would fit in here really well. It lets you specify PSTN numbers in a URI like "tel:+44-1234-5678901", so you replace the "+" with "00" and strip out the other punctuation.
IMHO the best solution is to define some regular exprssions to rewrite telephone numbers to sip urls. For example (perl regexps): s/[^0-9+]//g #to remove any weed s/^\+4899// #*sometimes* local numbers do not require leading 0 s/^\+48/0/ #country-wide numbers s/^\+/00/ #world-wide ones s/$/\@example.com/ #provider s/^/sip:/ #required??? or h323:??? would turn +48-99-1237654 into sip:1237654@example.com +48-98-4567654 into sip:0984567654@example.com and +49-555-987456 into sip 0049555987456@example.com There should be two ways to define those. First for avarage joe the user using gui like this Country |Poland (48)|v| #dropdown list Locality | | #textbox required only if locality (city/network) #numbers can be ommited Second and third regexps would be built from these data. Domain is from the default account and spacers? Hardcoded? This seems to be reasonable? The other option is an "Advanced" button giving a multiline textbox to input regular expressions line by line like those ones above.
That sounds good. We should also provide an option (probably selected by default until the user enters some location details) to just leave the number in E.164 format (i.e. sip:+44123456789@example.com). Although this is a minor problem because it seems Ekiga can't dial URIs with punctuation like '+' in them - why not?
The overall problem is, the format to dial a phone number may differ from provider to provider.
*** Bug 416478 has been marked as a duplicate of this bug. ***
Few people have their IP phone constantly connected, so I think it's important to make calling "normal" phones easy. If a user has a PC-to-Phone account somewhere and phone numbers in the address book, it will be hard to understand for him that calling it requires typing the number manually. Maybe we should collect a little data on which provider "understands" what number format. i'll make a start here with Ekiga using a Gizmo account: * +(country code) doesn't work * 00(country code) works * spaces in the number are not tolerated If the Gizmo account is set as the default account, one doesn't have to type the "@proxy01.sipphone.com"
I only use Ekiga to call real phones, so this is an important RFE for me. IMHO it shouldn't need to be all that complicated. The automation Łukasz suggests would be great but not a priority. I think the priority is something that works, then it can be improved. What about a collapsible dialog which presents all the numbers evolution has for that person and a radio button to select one. (Can Ekiga probe the PC-to-Phone to see if a number is acceptable without actually calling it?) With a number selected Ekiga can then launch a popup dialog with the number ready to edit which says something like: -------------- Please confirm Ekiga's phone number for this contact. [ +45 (76) 12345678 (extension 345) ] Please check that this number is formatted in a way your PC-to-Phone account supports. Typical problems are: * Missing country and regional codes * Missing '0' or '00' starting the country code * Using plus to start a dialing code, ie. <i>+45</i> * Using brackets around a dialing code ie. <i>(45)</i> * Spaces in the phone number, ie. <i>0045 12345678</i> Please refer to your PC_to-Phone account documentation for specific issues. ---------------- If the number is rejected Ekiga can recreate the popup dialog with a warning at the top something like: ---------------- ! Error. Your PC-to-Phone account has rejected this number. Please confirm Ekiga's phone number for this contact. [ +45 (76) 12345678 (extension 345) ] Please check that this number is formatted in a way your PC-to-Phone account supports. Typical problems are: * Missing country and regional codes * Missing '0' or '00' starting the country code * Using plus to start a dialing code, ie. <i>+45</i> * Using brackets around a dialing code ie. <i>(45)</i> * Spaces in the phone number, ie. <i>0045 12345678</i> Please refer to your PC_to-Phone account documentation for specific issues. ---------------- I hope this proposal can minimise developer effort without causing new problems. And then people can submit patches to improve it.
Hi again. I just had another idea which might be even easier. Current behaviour: * Open Phone Book * Select Person and try to call - fails * Right click with options: * ----------- * Call Contact * Send Message * Copy URL to Clipboard * Write e-mail * ----------- * Properties * ----------- * Delete * ----------- * New Contact * ----------- * None of these can show the potential phone numbers to call if Evolution Contact has no entry in the 'Video Chat' field Possible behaviour: * Open Phone Book * Select Person and try to call - fails * Right click with options: * ----------- * Call Contact * Send Message * Copy URL to Clipboard * Write e-mail * ----------- * Properties -->* Edit Contact - Tooltip: "Edit this Contact with Evolution's Contacts manager" * ----------- * Delete * ----------- * New Contact * ----------- ... of course at the moment there is a bug/RFE which means that Ekiga doesn't see changes to Evolution's Contacts before restart ... but that's a different bug.
Ekiga's current svn (future 3.00) shows several Call/Message actions if your evolution contact has several phone numbers, and should see them change without restart... could you have a look?
I just noticed that this bug has no link to the Launchpad Ubuntu downstream bug. Here it is then: https://bugs.edge.launchpad.net/ekiga/+bug/250858 "Ekiga doesn't show me the (normal) phone numbers I have stored in Evolution" I have pasted comment #11 there.
Tried to install cvn snapshot, see Bug 544853 – ekiga-snapshot 20080724 fails to install. unmet dependencies.
Snapshot is now installed. When I double click on a contact from Evolution Contact who does not have a number, I am asked to 'Please confirm you want that contact removed' ... I assume that's a bug?
If the only action available on that contact is "Remove", what should double-click do?
Snark, we're getting off topic. I have joined http://mail.gnome.org/mailman/subscribe/ekiga-list after I introduce myself please ask me this again.
I should add that none of our discussion or running the ekiga-snapshot have made a difference for the original bug. It is still not possible from Ekiga to call a number recorded in evolution in any field other than 'Video Chat'.
Duncan, please be patient. I'm working on an intermediate solution. Regular expressions would be the best solution, but it won't be possible to implement that before 3.00.
I added some code helping in that direction. Ekiga will now look for all enabled accounts and propose to dial or message using them. Using regular expressions to rewrite the uri is not supported and will not be supported until 3.2. If your initial problem is fixed, please consider closing this bug report and reporting a new one for the regular expressions feature request.
Marking as FIXED. Please open a new bug report for the regular expression thingy as it is a different problem (more a feature request than a bug like the current one).