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 729084 - Use tel: URI instead of callto: for phone numbers
Use tel: URI instead of callto: for phone numbers
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Contacts
3.14.x (obsolete)
Other All
: Normal enhancement
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-04-28 06:50 UTC by daniel
Modified: 2017-06-27 08:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test program (1.54 KB, text/plain)
2014-04-30 12:39 UTC, Milan Crha
Details

Description daniel 2014-04-28 06:50:56 UTC
I make the sipdialer application (part of reSIProcate) and some other open source SIP and VoIP software.

I'd like to improve integration between Gnome and such dialers.

Specifically:


a) the user clicks some phone number or SIP address on the screen (e.g.
in the address book)

b) their preferred deskphone or softphone starts calling the number or
address

I need to explore two aspects of this problem with the Gnome community:

- how to make SIP addresses and phone numbers clickable in the contact list?

- how to route the event "user clicked a phone number" to the correct handler and eventually to the correct softphone or deskphone (the user may have more than one phone available, so it needs to be flexible, like choosing from multiple audio devices)

Perhaps DBus could play a role in passing the event down from the UI to one or more possible handlers.
Comment 1 Milan Crha 2014-04-28 16:09:11 UTC
Thanks for a bug report. From the evolution's point of view it might be as easy as make the phone numbers click-able in the preview panel with some URI prefix, like "sip://" and provide the phone number as written in the contact. I suggest to use URIs, because it's easy to define handlers (application's .desktop file can have such definition, like evolution.desktop contains:
  > MimeType=text/calendar;text/x-vcard;text/directory;application/mbox;
  > message/rfc822;x-scheme-handler/mailto;
) and the application will take the phone number and let user choose what phone device he/she wants to use.

I cannot speak desktop wide, neither specific to the phone application, but this approach seams to me as the easiest available for both the invoker (evolution) and receiver (your phone application). How smart the phone application will be depends completely on you. I can imagine something like country code recognition and remembering (on option) which phone was used for which country code (or when there is no country code at all).

I can provide a patch to evolution which will create the sip:// URLs for phone numbers. Let it be of the form:
   sip://open/?phone=+420123456789
which allows adding extra parameters in the future. If you can think of any better URL scheme, just let me know.
Comment 2 daniel 2014-04-28 16:23:54 UTC

Just a few specifics:

- when it is a number, we should use a tel: URI instead of sip: - while I use SIP a lot, it is not the universal solution.  A SIP phone or some other device may be willing to handle the tel: URI in different ways.  An example is tel:+442071357000

- if people want to enter SIP addresses for a contact, they should be encouraged to enter them as sip:user@example.org in some field

- a mail address may also be a SIP address.  It would be nice to detect this case (by checking for SIP NAPTR records in DNS for the domain in the address) and ensure that when somebody clicks such an address, they can choose between mail and phone.  Same goes for XMPP NAPTR records.

- there is also the question of normalizing and cleaning numbers.  Google's libphonenumber is quite good for that.  It would be nice to have something like this within Evolution and just send clean numbers with the tel: URI.  Many people also store numbers in E.164 format in their mobile devices now and will probably welcome such help with cleaning numbers they have already stored.
Comment 3 Milan Crha 2014-04-29 07:41:46 UTC
(In reply to comment #2)
> - when it is a number, we should use a tel: URI instead of sip: - while I use
> SIP a lot, it is not the universal solution.  A SIP phone or some other device
> may be willing to handle the tel: URI in different ways.  An example is
> tel:+442071357000

Right. tel:// works for me too. I wasn't sure, thus suggested sip://.

> - a mail address may also be a SIP address.  It would be nice to detect this
> case (by checking for SIP NAPTR records in DNS for the domain in the address)
> and ensure that when somebody clicks such an address, they can choose between
> mail and phone.  Same goes for XMPP NAPTR records.

I would not do any DNS lookups, they tend to stale in time and be slow. Rather let user pick whether what he/she enters is a sip:// or tel:// URI. Evolution supports many different phone number types, adding there a SIP type is fairly easy (there is bug #685323 for it). Such kind can be made clickable with sip://, other telephone entries with tel://.
 
> - there is also the question of normalizing and cleaning numbers.  Google's
> libphonenumber is quite good for that.  It would be nice to have something like
> this within Evolution and just send clean numbers with the tel: URI.  Many
> people also store numbers in E.164 format in their mobile devices now and will
> probably welcome such help with cleaning numbers they have already stored.

Right, evolution-data-server can be compiled with it, but the dependency is optional. Intentionally. I believe it would be better, rather than each application which wants to send sip:// or tel:// URIs be dependent of libphonenumber, it's the receiving application which should do the normalization, if needed. Of course, evolution may store normalized numbers, but that's also user's choice to not use phone number with country code.

By the way, the reason why I suggested: sip://open/?phone=+420123456789 is that the "host part" of the URI may not contain spaces, thus if user stores his number as "+420 123 456 789", then either the invoking application may strip whitespaces from the number, or the constructed URI should be of the suggested form. As there can be multiple formats, like +90(555)132132, then it's safer to use the 'phone' argument of the URI. (I know, it points to the usage of libphonenumber, but still, better only one application depends on it, rather than all of them.)
Comment 4 Milan Crha 2014-04-29 07:43:47 UTC
I just found bug #352470, which suggests callto:// URI. I'm marking this as a duplicate of it, and let's continue the discussion there.

Just a note: let's use callto:// for phones and sip:// fir sip-typed phone (may eventually use X-SPI, as suggested in the other bug report.

*** This bug has been marked as a duplicate of bug 352470 ***
Comment 5 daniel 2014-04-29 08:20:53 UTC
I'm not sure that this is really a duplicate

352470 is specifically about including extra fields/columns for storing designated VoIP addresses (e.g. a SIP field or an XMPP field)

This issue, 729084, is more about making the fields clickable and it is applicable to both the normal phone fields and the other types of field.
Comment 6 daniel 2014-04-29 08:58:27 UTC
Please note the sip: and tel: URI schemes do not include "//".  There is a well known syntax for these URI schemes and Evolution should not do its own thing.

If a field contains a number and no '@' symbol, Evolution should be sending it to the registered handler for the "tel:" scheme.

https://tools.ietf.org/html/rfc3966

The handler may well be some utility that converts "tel:" to "sip:" according to some local policy (e.g. reformatting the number for the preferred SIP provider).  However, such a handler may also do something completely different, like stripping the punctuation from the number and sending it to the local Asterisk server as a URL parameter.

On the issue of spaces:

https://tools.ietf.org/html/rfc3966#section-5.1.1 says that spaces are banned in the "tel:" URI.  If Evolution is contructing a "tel:" URI, it should either remove the spaces or replace them with one of the other supported symbols (e.g. the hyphen).  Maybe this should be configurable in the settings, with a default action being removing the spaces.

The use of "sip:" and "xmpp:" schemes should only occur for addresses where the user has added those prefixes in the field or where the field is explicitly named "SIP address" or something like that.  If such a prefix is in the field, Evolution should leave it as-is and not try to add the "tel:" prefix.

If Evolution does need to use some other URI scheme internally while resolving such addresses, then a different prefix should be used, e.g. "gnome-call:"
Comment 7 Milan Crha 2014-04-29 13:12:02 UTC
Right, my bad with the proposal of URI scheme. I made the changes in the bug #685323 properly, luckily. I didn't address the issue with spaces, though, but it would be better if you could give it a try. by the way, as suggested in the related bug reports, I do not use tel:, but callto:.
Comment 8 daniel 2014-04-29 13:18:51 UTC
Can you tell me why you prefer "callto:"?

RFC 3966 discourages "callto:" for various reasons.  The standard is to use "tel:" and I feel that is the way to go here.  Other devices (e.g. Android) also use "tel:" in certain situations.

An additional idea would be to provide a way for people to define the rules for transforming phone numbers into URIs and URLs.  By default, this would just have some regular expression that converts a phone number into a tel: URI.  However, users could easily modify the regular expression to specify "sip:$1@asterisk-gateway.mycompany.com" or whatever they want.

What is the best way for somebody who is not actively involved in GNOME development to try your changes?  Are there nightly RPM builds for Fedora 20?
Comment 9 Milan Crha 2014-04-29 14:07:27 UTC
(In reply to comment #8)
> Can you tell me why you prefer "callto:"?

The only reason was that the old bug mentioned it with references to (outdated) GConf settings. If it's not right, then I can change it.

> An additional idea would be to provide a way for people to define the rules for
> transforming phone numbers into URIs and URLs.  By default, this would just
> have some regular expression that converts a phone number into a tel: URI. 
> However, users could easily modify the regular expression to specify
> "sip:$1@asterisk-gateway.mycompany.com" or whatever they want.

I'm afraid that regular users do not understand regexes, they just want to use the software.

> What is the best way for somebody who is not actively involved in GNOME
> development to try your changes?  Are there nightly RPM builds for Fedora 20?

Ah, right, not so easy to build the packages, that's true. There are no nightly builds for fedora, I'm not aware of any at least. Let's forget of it, then.
Comment 10 daniel 2014-04-29 15:33:39 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Can you tell me why you prefer "callto:"?
> 
> The only reason was that the old bug mentioned it with references to (outdated)
> GConf settings. If it's not right, then I can change it.
> 


I would definitely recommend following the advice from the RFC and using "tel:" and also removing spaces from numbers.

Here are some examples:

Field:  Home Phone
Value:  01 234 5678
Action: Display an error: "I can only dial numbers with a leading '+' symbol"

Field:  Work phone:
Value:  +44 20 7135 7000
Action:  Invoke the URI tel:+442071357000
Note: spaces removed

It is worth having a close look at section 5.1.5 in the RFC.  The simplest way to comply with this section is to just avoid dialing any number that does not start with a "+".  In future, Evolution could be extended to help people translate their numbers but for now it should just display a helpful error.

> > An additional idea would be to provide a way for people to define the rules for
> > transforming phone numbers into URIs and URLs.  By default, this would just
> > have some regular expression that converts a phone number into a tel: URI. 
> > However, users could easily modify the regular expression to specify
> > "sip:$1@asterisk-gateway.mycompany.com" or whatever they want.
> 
> I'm afraid that regular users do not understand regexes, they just want to use
> the software.

I was thinking that this could have a sane default.  It could also be in some hidden setting just for the administrator.  I agree that most users would never want to change it though.
 
> > What is the best way for somebody who is not actively involved in GNOME
> > development to try your changes?  Are there nightly RPM builds for Fedora 20?
> 
> Ah, right, not so easy to build the packages, that's true. There are no nightly
> builds for fedora, I'm not aware of any at least. Let's forget of it, then.

In that case, could you suggest the quickest way for me to run the code from git somewhere?  Which OS and how should I build it?  I can set up a VM for testing it.
Comment 11 Milan Crha 2014-04-30 12:14:10 UTC
OK, I'm reopening this to use tel: instead of callto:  and to remove spaces from the phone numbers when constructing the URL. The actual error reporting and so on should be done by the receiver of the URI (again, to have it done centrally, instead in each application which would like to add the tel: functionality into itself).
Comment 12 Milan Crha 2014-04-30 12:39:56 UTC
Created attachment 275488 [details]
test program

(In reply to comment #10)
> In that case, could you suggest the quickest way for me to run the code from
> git somewhere?  Which OS and how should I build it?  I can set up a VM for
> testing it.

It'll be easier to use the functions out of evolution, thus I made this test.c, which you can compile (see the first line of the file, it requires only gtk3-devel), then you can run it with a URI as it might be passed to you by evolution. It also shows whether the scheme handler had been found and and an information about it, if any. You can run it with any URL. The examples are:

   ./test "tel:+23 123 123 123"
   ./test "tel:123456789"
   ./test "http://www.gnome.org"
   ./test "sip:user@example.com"

By the way, I would not deny the phone numbers without country code, those are numbers "in my current country". It's usually harder to find out which country it is, much harder than with a phone, but it still might be doable, like by an explicit setting in the URI-receiving application.
Comment 13 daniel 2014-04-30 12:55:03 UTC
(In reply to comment #12)
> Created an attachment (id=275488) [details]
> test program
> 
> (In reply to comment #10)
> > In that case, could you suggest the quickest way for me to run the code from
> > git somewhere?  Which OS and how should I build it?  I can set up a VM for
> > testing it.
> 
> It'll be easier to use the functions out of evolution, thus I made this test.c,
> which you can compile (see the first line of the file, it requires only
> gtk3-devel), then you can run it with a URI as it might be passed to you by
> evolution. It also shows whether the scheme handler had been found and and an
> information about it, if any. You can run it with any URL. The examples are:
> 
>    ./test "tel:+23 123 123 123"

Evolution should never construct a URI with spaces in it - the RFC says that is discouraged

>    ./test "tel:123456789"
>    ./test "http://www.gnome.org"
>    ./test "sip:user@example.com"
> 
> By the way, I would not deny the phone numbers without country code, those are
> numbers "in my current country". It's usually harder to find out which country
> it is, much harder than with a phone, but it still might be doable, like by an
> explicit setting in the URI-receiving application.

The RFC says:

 "Local numbers MUST have a 'phone-context' parameter that identifies
 the scope of their validity"

A "Local number" is any number that does not start with '+'

So there are two choices:

a) Evolution should simply display an error if the number does not have '+'

b) Evolution should construct a tel: URI with a phone-context parameter, e.g. if the contact phone number is 020 7135 7000 and the user profile is "UK", it may construct the URI like this:

   tel:2071357000;phone-context=+44

However, for case (b) there is a catch - Evolution must remove the 0 (it is not really part of the number, it is a prefix for national dialling in the UK).  Tracking all these prefixes is a pain and so it is easy to just do (a) for now and let people manually adapt their numbers before clicking them again.
Comment 14 Milan Crha 2014-04-30 14:12:46 UTC
I see. So the final change [1] cotains:
- learn	the code of "tel" URI, being handler similar to	"sip", "callto", "h323"
- generate tel:	URIs for phone numbers,	but only if the	leading	character of the
  phone	number is a plus ("+") sign
- always remove	spaces in href part in the e_text_to_html() when
  E_TEXT_TO_HTML_URL_IS_WHOLE_TEXT flag	is set

Created commit e0e498c in evo master (3.13.2+) [1]

[1] https://git.gnome.org/browse/evolution/commit/?id=e0e498c
Comment 15 daniel 2017-06-27 08:11:26 UTC
Thanks for your efforts with this bug.  I've seen it working as expected in Evolution on Debian stretch, v3.22.6-1

For handling numbers not already in E.164 format, I've created a separate feature request bug report #784238.