Bug 890579
Summary: | ekiga-4.0.0 can no longer enter contacts with no explicit domain | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stuart D Gathman <stuart> |
Component: | ekiga | Assignee: | Peter Robinson <pbrobinson> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | eugen.dedu, pbrobinson |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-03-03 22:33:20 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Stuart D Gathman
2012-12-27 23:29:46 UTC
I just tried calling an older contact. While it doesn't add the spurious domain when just displaying it, as soon as I click call, it adds the ekiga.net domain (and the call then fails). I have to edit the contact, and add the proper domain (and edit the contacts again when that domain changes). Actually, its easier to just retype the phone number. The contacts are now essentially useless (at least when trying to use a provider other than ekiga.net). Eugen: have you seen issues like this before? This was somehow voluntarly. Each time you create a contact, you have to provide the host part too. "All new contacts are tied to ekiga.net, even if none was entered" is wrong. Not all contacts are tied to ekiga.net, but only those without host part. "It is impossible to simply dial new contacts using a VOIP account other than ekiga.net" is wrong also. "Manually editing the XML in contacts to remove the explicit domain doesn't seem to help" - this is because gconf caches data; you have to use gconf-editor for ex. So this bug is in fact "for contacts without host part, show options for all registered accounts", which is not beautiful: what should happen when you double click on the contact? Finally, note that all e-mail addresses have host part, so why do not do the same for sip addresses? Ok, so the change was intentional, and not a "bug". > Finally, note that all e-mail addresses have host part, so why do not do the same for sip addresses? That is fine for pure SIP addresses. However, in the special case of phone numbers, the phone number can be used with any of many VOIP providers, including ekiga dialout (diamondcard.us). Like a long distance company, your VOIP provider can change often, and you can have more than one. For instance, I currently use nextiva for US calls, and ekiga dialout for all other countries. There may be other future global addressing schemes that could be used with multiple providers. For instance, at some point Skype will have to give in and at least allow gateways to SIP. Then the Skype address would be useful without a specific domain so as to chose between gateway providers. > What should happen when you double click? I never do that, but if I did, I would expect it to use the VOIP account designated as "default". Just the same as you do for configuring audio input and output: you can choose a specific device, or the current pulseaudio default. > Not all contacts are tied to ekiga.net, but only those without host part. Agreed. I meant that it is now impossible to enter a new contact without a host part. (As explicitly stated in the bug description.) You are right. This is fixed with http://git.gnome.org/browse/ekiga/commit/?id=54332ee273f567c. I added info about that at http://wiki.ekiga.org/index.php/Manual#Add_a_contact_to_your_contact_list_.28roster.29 too. I have also added this info as tooltip: http://git.gnome.org/browse/ekiga/commit/?id=70d17ab77f6. Better English for "if you do not precise the host part" would be "if you do not specify the host part". Although the former is actually wrong, it was still understandable. :-) Ok, I changed it. ptlib-2.10.10-1.fc17,opal-3.10.10-1.fc17,ekiga-4.0.1-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/ptlib-2.10.10-1.fc17,opal-3.10.10-1.fc17,ekiga-4.0.1-1.fc17 ptlib-2.10.10-1.fc18,opal-3.10.10-1.fc18,ekiga-4.0.1-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/ptlib-2.10.10-1.fc18,opal-3.10.10-1.fc18,ekiga-4.0.1-1.fc18 Package ptlib-2.10.10-1.fc17, opal-3.10.10-1.fc17, ekiga-4.0.1-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ptlib-2.10.10-1.fc17 opal-3.10.10-1.fc17 ekiga-4.0.1-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2890/ptlib-2.10.10-1.fc17,opal-3.10.10-1.fc17,ekiga-4.0.1-1.fc17 then log in and leave karma (feedback). ptlib-2.10.10-1.fc18, opal-3.10.10-1.fc18, ekiga-4.0.1-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. ptlib-2.10.10-1.fc17, opal-3.10.10-1.fc17, ekiga-4.0.1-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |