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

[Alec Leamas <leamas alec gmail com>]

Simos wrote:
> 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
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Hm... I actually share many of your opinions, perhaps all. The problem 
is just to find the limits of this work, its already nine patches. Of 
course, things would be different if I were not alone implementing this.

My current understanding is that this is especially true for the UI, 
where I have tried to find a solution with as small changes as possible. 
Is it feasible to address an UI overhaul once a first attempt is out?  
My own experience is that you get really good ideas when you have a 
first attempt running.

The need to hide the (a)sip.xxx part is already identified and discussed 
( by at least Julien). And to be honest, it was a part of this work in 
my first sketches.  But although it *is* important, I'd prefer not do 
this within this RFE. It's really a separate issue.

Bottom line: I think what you say is interesting and is also in the 
right direction (I don't really understand all details, though). 
Question is just how to delimit the current work, leaving ways open to 
accomplish things in the direction you envision.

--a