GNOME Bugzilla – Bug 589119
ENUM lookup doesn't work if registered to any SIP servers
Last modified: 2020-06-06 16:31:33 UTC
I am trying to make calls to an ENUM target as described in http://wiki.ekiga.org/index.php/Enum#Calling_from_Ekiga_softphone. Unfortunately, this only works as long as I am not registered to any SIP servers. As soon as I am, trying to enter sip:49xxxxxxx is impossible as the @mysipserver.tld region is automatically appended to the URL. Also using sip: for an ENUM lookup does not exactly make sense, because a SIP address is one out of many potential results from an ENUM lookup. Others include tel:, possibly also iax2: or h323: Wouldn't it make more sense to allow a URL like enum:49xxxxx? Bonus question: If the result of the ENUM lookup is a SIP address, how does Ekiga decide which of the registered SIP servers (if >1) it will be using to make the call? Other information:
This is related to bug #585855. Maybe the best solution is forcing the user to enter enum:49xx? For bonus: I think it is the first account in Acounts window which is used. I would write a text on the wiki for that, but: - I am not sure - there is another case when this first account is used, I do not remember when
> Maybe the best solution is forcing the user to enter enum:49xx? Well, either enum: or just "nothing"? I tried, just entering 49xxx (or whatever country code you feel at home in) works as well, but has the same problem, i.e. "nothing" is interpreted as if it was "sip:". The really nice solution (if you want to make Ekiga properly support public ENUM according to its original idea) would be IMO: 1. Introduce enum: to explicitely force an ENUM lookup. 2. Treat "nothing" as enum:, not as sip:. 3. Introduce a new setting "Home Country" so that if someone dials a number as he or she would dial locally (i.e. 030xxx for Berlin) the leading zero gets stripped and the home country prefixed for the ENUM lookup. 4. Introduce a default account to use for calls using each protocol (i.e. a default SIP account for outgoing calls) 5. Define what should happen if no ENUM record is found or if a tel: record is returned. Offer the user to make the call through a SIP provider which has a PSTN gateway which (in that case) would possibly be a charged call?
For 2, some persons (especially very novice users :o)) prefer to automatically add @ekiga.net, as was it seems the case for ekiga v2. So what should we choose? (Note that we should not drop the cases sip:x.y.z.t and x.y.z.t, with IP addresses) For 4, I do not know when a default account gets used (additionally to when enum returns a sip address). For 5, I do not know what to say. Otherwise, I agree with you.
Re 2.: How about making this an option in the settings, where the user can choose how to qualify "nothing"? Like: Auto-Complete: ( ) enum:xxxx ( ) sip:xxx@ekiga.net ( ) custom template Re 4.: I don't understand your question. Re 5.: I don't know what you mean. Is this a question? In general, I think the problem is that you need to make Ekiga behave and work well for a number of different users that have different goals in live. While some people may view Ekiga as "the client" for the Ekiga.net free SIP service other people view Ekiga as a universal client for any SIP or H.323 service while other people view Ekiga just as "a VoIP phone" as they view Mozilla as "their browser". So introducing some more options to allow users to choose how the app should behave depending on how they try to use it may make sense.
For 4 and 5, for me, there were not questions, it's just that I do not have an idea about them, while on the others I agree. Thanks for information. I think we need to think now for the best solution.
I think 4 and 5 are somewhat related. Just to make sure we're talking about the same: Some VoIP users think in SIP URLs while others think in phone numbers. If I subscribe to a SIP provider mysip.tld which has a PSTN gateway, to dial a PSTN number, I usually have to use 9876543210@mysip.tld to dial. So let's say a user entered a phone number and the ENUM lookup did not return anything (number not registered) or a tel: URL. In that case we could dial phonenumber@sipprovider.tld. Just if I am connected to multiple SIP providers, either one of them should be the default *or* I should have some plan, i.e. for numbers starting in 49 use myprovider.de, for numbers starting in 359 use myprovider.bg, etc. to make use of the cheapest route. The problem is similar if I enter a SIP URL, by the way. Right now, it's entirely intransparent to me where the SIP INVITE goes to and if a proxy will be used or not and if yes, which one.
Julien, (Damien), how could we make enum work again for the next release?
Hello. I am trying Ekiga 3.3.2 on Ubuntu 12.04. I have one single sip account to register to my local Asterisk, which has pstn connections. Asterisk's ip is 192.168.1.200 When I make a call to sip:phone_number@192.168.1.200 it runs ok. If I call to sip:phone_number, call finishes inmediately. Network analyzer shows an ENUM lookup Standard query NAPTR 1.7.e164.org Standard query response Standard query NAPTR 1.7.e164.org Standard query response Standard query NAPTR 1.7.e164.arpa Standard query response, No such name Standard query NAPTR 1.7.e164.arpa Standard query response, No such name At this point call finishes. When ENUM fails, I expected Ekiga would use default account sip server, but this does not happen. Now I go to call history and there it is the phone_number registered, obviously whithout @192.168.1.200. If I double click on it, now call runs ok. May be all of this an gui problem or an ENUM problem? I'm not expert whith ENUM and I don't know if an ENUM fail should return a sip server address. Neither I know why typing the phone number has different behaiviour than double clicking on call history
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.