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 652679 - Clean phone numbers coming from bookmark (such as LDAP)
Clean phone numbers coming from bookmark (such as LDAP)
Status: RESOLVED WONTFIX
Product: ekiga
Classification: Applications
Component: Addressbook stack
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2011-06-15 20:22 UTC by CDuv
Modified: 2020-06-06 16:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description CDuv 2011-06-15 20:22:34 UTC
Hello,

In my LDAP, phone numbers are in the international form, prefixed with country code, eg.:
+33 (0)1 23 45 67 89
+1 (514) 123-4567

When double-clicking on an entry from an address book LDAP, the found phone number is pasted as is in the dial text input and both the country code and parenthesis seems to prevent Ekiga from calling.

Depending on the SIP account I'm using, the "+33" (for example) part should be removed.

It could be done with a regex (or any other more user-friendly way) placed into the LDAP address book configuration that will strip matching characters.
Comment 1 Eugen Dedu 2011-06-15 20:38:04 UTC
Is removing
- leading +
- spaces
- everything inside ()
sufficient?
Comment 2 CDuv 2011-06-15 22:24:48 UTC
I would also hyphen (-) to the list for north american form.
Comment 3 Kilian Krause 2011-06-16 07:56:29 UTC
Eugen,

please keep in mind that not everything in () is optional. Usually the () themselves can be deleted like whitespace and hypens. But not the numbers in between.

Any notation like +1 (514) 123-... would then get screwed up because +1123... plain is not valid any more whereas +1514123... is.

That's why other software (e.g. Outlook) stores anything in between () as the region and either prefixes the local regional prefix (in Germany 0) if same country or country prefix (e.g. +33 for calls to France from Germany) and then puts the regional digits before the actual telephone line's number.

I can't find the official convention document right now but I'm sure there is some *official* standard for this which Ekiga should follow.
Comment 4 CDuv 2011-06-16 23:13:09 UTC
By looking at the RFC 3966, it looks like both the E.123 and the E.164 ITU-T recommendation would be followable standards.
RFC 3966 also treat to case of the separators: some are accepted, because they aid readability ("A URI often needs to be remembered by people, and it is easier for people to remember a URI when it consists of meaningful components", RFC 2396) but spaces are forbidden.

Don't know if I'm really helping there, but hoping it is.
Comment 5 CDuv 2011-06-16 23:14:53 UTC
Typo in comment 4:
"RFC 3966 also treat to case of the separators:"
should be:
"RFC 3966 also deals with the separators issue:"
Comment 6 André Klapper 2020-06-06 16:29:59 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.