Description of problem: All new contacts are tied to ekiga.net, even if none was entered. Version-Release number of selected component (if applicable): ekiga-4.0.0-1.fc17.i686 How reproducible: always Steps to Reproduce: 1. Enter new contact 2. Leave local part (e.g. phone number) with no explicit domain 3. Edit contact and see that an (incorrect, unless you really wanted ekiga.net) explicit domain has been added Actual results: It is impossible to simply dial new contacts using a VOIP account other than ekiga.net. You must backspace over the (incorrect) explicit domain and retype in its entirety the correct domain. Expected results: For contacts entered with older versions, right clicking on a contact brings up options to dial with any registered account. Additional info: Manually editing the XML in contacts to remove the explicit domain doesn't seem to help - it still adds the ekiga.net domain. There must be some way for the program to know when not to work, but I haven't figured it out yet.
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.