Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)



On Sun, Mar 29, 2009 at 1:36 PM, Alec Leamas <leamas alec gmail com> wrote:
> thomas schorpp wrote:
>>
>> Alec Leamas schrieb:
>>>
>>> Trying to explain this once again, hopefully better. Questions in the
>>> end...
>>>
>>> The problem I try  to solve is that users typically stores telephone
>>> numbers, often formatted and without countrycode, whereas Ekiga today
>>> requires a complete URL to place even an ordinary PSTN call.
>>
>> No it doesn't. This is SIP-providers' switches business. A good
>> VoIP/PSTN-provider with a fine designed switch does not require
>> +<countrycode>... for local country #s.
>> With sipgate.de e.g. You dial WYSIWYG on Ekiga's dialpad, care about
>> @sipgate.de only, press green and off you go.
>
> But you still have to handle the @sip.xxx suffix to connect to the right
> provider, which is a Bad Thing. And besides the expansion, there is also
> what happens when you paste a formatted number into Ekiga.  And you run into
> trouble when making DBus/CLI calls to connect to a specific number since
> Ekiga of today does not have the notion of a default PSTN provider.
>
> A more basic question is if Ekiga should support current users, and the
> providers they have. Or be used to put pressure on providers to implement
> certain features... I'm not sure that Ekiga currently is in the situation
> where it can put a pressure big enough to be useful. And users don't really
> want to wait for what the further spreading of electronic notepads and
> mobiles will lead to... Do you?
>
> Note that this is *not* about supporting providers that break the standards.
> It's about supporting a reasonably wide set of providers, and the way they
> implement standards.
>
> Skype is out there, people are actually comparing  Ekiga w Skype. In Skype,
> you just enter the number, and it just works. Why should Ekiga be more
> complicated?

I think the direction of your work is what Ekiga needs to make it
easier for people to use.

The workflow for dialing numbers that I envision new users of Ekiga
would go through is

A. Calling an existing entry in the Addressbook
The addressbook is visible to the users so that when they need to call
a contact for the second time,
they would be more likely to go through the addressbook. The effort
would be for Ekiga to try
to get any new numbers in the Addressbook, similar to the way that the
Betamax client does
(allows to call a number directly, and if the call succeeds, it
prompts to save it as an addressbook entry).

B. Dialing a new number
When a new number is typed and the Call button is pressed, I would
prefer to have a dialog (single window wizard) pop up
which would include
     1. The number would be parsed according to your code and the
country code, SIP provider, etc would be autocompleted to the extent
possible.
     2. There would be an option to save the entry to the addressbook
     3. There would be a big Call button labeled 'Call Now' for users
that want to actually call directly, temporarily postponing the
addition to the addressbook.

What I think is important is to try to make less visible (in
sip:+46705434415 sip diamondcard com) the two parts about 'sip:' but
most importantly the '@sip.diamondcard.com'). It would be ideal if in
the UI, the 'sip:' part is considered a single entity (not four
characters), and the same with the '@sip.diamondcard.com'.
As a user, I have the telephone number X and I want to call with the S
SIP provider. The 'sip:' is implied from S, and the
'@sip.diamondcard.com' part is part of the information that Ekiga
knows about this known SIP telephony provider.

This all boils down to Ekiga learning about SIP providers and having
an ability to register the details of those providers (i.e. be part of
a configuration file that ekiga.net maintains). Of course, users would
still be able to make custom entries.
There is a relevant bug report for this at
http://bugzilla.gnome.org/show_bug.cgi?id=547215

Simos


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]