Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
@Eugen, pls don't top post, You're ruining threads on this list ;) Alec Leamas schrieb: 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 +... 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. No. Only in "chaos" environments of unprofessional VoIP setups. 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. Yes it does, multiple SIP-accounts is a _optional_ feature competing products like x-lite do _not_ support at all and it is practically not needed in office and private real life because we got PBXes like Asterisk easily installable on all router platforms like AVM Fritzboxes and professional linux gateways etc which are invented for handling multi-accounts. 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. I must object. You guys are trespassing out of best HMI and manual data handling ergonomic and software/data security practices wich will lead to millions $ of economic damage cause users will try to feed computer interfaces machine unreadable data if we software engineers support such habit, look at this: After 2011 all EU bank accounts will have this notations: - Paper format IBAN: IBAN BE61 3101 2698 5517 - Electronic format IBAN: BE61310126985517 Why the need for 2 formats? For easy and error-proof human data transfer between unconnected computer system or by copy&paste e.g., inventing _Your way_ You will support _wrong habit_ working with computers and could try to c&p the paper form someone used illegally in mail or on website in a GUI form input field which may _cut_ characters at the end without notice _after_ You click "OK", there're many of such GUIs and webforms still around, so the bank transfer will fail without notice and You'll pay punishment fees for violating SEPA-criteria, and here You want to violate the SIP-Standard by breaking up SIP-URIs, this is inacceptable. 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? VoIP-Freedom with SIP is always "complicated", especially to the ones long been unfree with Skype + MSN. Cheers! --a y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
Eugen Dedu wrote: Hi, Hi :-) Thanks, Alec, for this. Let's try to check it in while it is "fresh", otherwise it will be forgotten and the chances to be integrated are small. Also, let's wait with the check in a few days (until Tuesday?) for other people comments. (I welcome the "make easy the user work" subject; there is room here for other sub-domains too, we will speak later about that.) I'll be actually be offline for a week, so its no hurry. And for the same reason I will try to comment issues which I feel I have actual now, and not later. I'll try to attach a new version of the files to the bug before I leave. Alec Leamas wrote: 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. This makes the basic process to call a PSTN number hard, user has to manually convert e. g., '070-543 22 11' to sip:+46705432...@sip.diamondcard.com. I have written a piece of code which converts numbers to sip: urls. It's partly a question of handling missing country codes, partly to remove formatting characters as in '070- 543 11 22'. This code of course requires some configuration to define user's own countrycode etc. (all in total four values). It generates default config values usable for most users, and seems to work. It has the potential to let users just enter e. g., 070-543 22 11 in Ekiga to place a call instead of a complete URL. My problem is if/how to integrate this into Ekiga. More precise, I need help to integrate it. The Ekiga code is big, and although I think I'm able to produce a set of patches, I will at least need help with where in the code I should begin, and certainly other things as well. I really can't be on my own in this, it's to much for a newbie... So: first question: Would this overall be a Good Thing, something that makes Ekiga more usable, and thus worth some effort? I agree. Second question. I have done a simple plan: http://mumin.dnsalias.net/ekiga-callto-ui/patches.html. Is this reasonable? I agree. Third question. There is some UI impact, described in http://mumin.dnsalias.net/ekiga-callto-ui/index.html. Does this seems OK? For the moment, let's just do nothing (the current error is shown). Later, we can add a menu entry, or a tab in preferences etc. Last question: Depending on the outcome of the other questions, how should I proceed with the first patch, to integrate a set of new source files related to PSTN management into Ekiga? There are three files involved (Pstn* and .csv); I would propose to use PTRACE from ptlib; as for assert, isn't possible to use classical assert? I can use PTRACE with some loss of information in error messages. Same for classical assert, to a much higher degree. Note "my" Trace/Assert uses the PTRACE backend when it's available, so there is really no conflict. But it's some extra code, yes. I have actually refactored the code, so wait a little with checking in. One of the thing I was thinking about is if there should be a separate directory for this, or which existing should be used. There is currently four source files besides the Trace/Assert stuff., + the csv file. The csv file is an issue. The app must be able to locate it, it's just a hardcoded path now. No idea how handle it. The first thing is to add a hook when the user clicks on green button. Later, we will add a hook for adding in dbus, roster etc., as you wrote. I see in the bug report there are several things involved, such as PresenceCode; so is it there to add this hook? The change to ekiga current code should be very small, only 2 lines (call your pstn file and replace the URL bar value). To be honest: I have absolutely no idea where to make the changes. But I think that in this case it's the code executed when user user pushes the "Call" context menu option for a contact. Yes, most of these patches should be really small. The problem is to find out where to do it... In fact, all your work can be resumed like this: when the user pushes the green button (or dbus, roster etc.), the number in the URL bar is transformed, that's all, isn't it? No, not really. The problem is when you expand a number supposed to be evaluated in another country e. g., when using a number on a US website. The user must then have a chance to review and edit the number before it's used. (it's the second example in my UI sketch and "story" 2.) So there *is* a need for a three-step approach: first convert, review/edit and call. The situation is the same whether called from the browser or when a number is pasted into Ekiga. The "just push button" is a shortćut possible on numbers that are unambiguous: starting with +, or from the address book. Some background material: usecases defined in a few "stories:" ht
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
Hi, Thanks, Alec, for this. Let's try to check it in while it is "fresh", otherwise it will be forgotten and the chances to be integrated are small. Also, let's wait with the check in a few days (until Tuesday?) for other people comments. (I welcome the "make easy the user work" subject; there is room here for other sub-domains too, we will speak later about that.) Alec Leamas wrote: 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. This makes the basic process to call a PSTN number hard, user has to manually convert e. g., '070-543 22 11' to sip:+46705432...@sip.diamondcard.com. I have written a piece of code which converts numbers to sip: urls. It's partly a question of handling missing country codes, partly to remove formatting characters as in '070- 543 11 22'. This code of course requires some configuration to define user's own countrycode etc. (all in total four values). It generates default config values usable for most users, and seems to work. It has the potential to let users just enter e. g., 070-543 22 11 in Ekiga to place a call instead of a complete URL. My problem is if/how to integrate this into Ekiga. More precise, I need help to integrate it. The Ekiga code is big, and although I think I'm able to produce a set of patches, I will at least need help with where in the code I should begin, and certainly other things as well. I really can't be on my own in this, it's to much for a newbie... So: first question: Would this overall be a Good Thing, something that makes Ekiga more usable, and thus worth some effort? I agree. Second question. I have done a simple plan: http://mumin.dnsalias.net/ekiga-callto-ui/patches.html. Is this reasonable? I agree. Third question. There is some UI impact, described in http://mumin.dnsalias.net/ekiga-callto-ui/index.html. Does this seems OK? For the moment, let's just do nothing (the current error is shown). Later, we can add a menu entry, or a tab in preferences etc. Last question: Depending on the outcome of the other questions, how should I proceed with the first patch, to integrate a set of new source files related to PSTN management into Ekiga? There are three files involved (Pstn* and .csv); I would propose to use PTRACE from ptlib; as for assert, isn't possible to use classical asert? The first thing is to add a hook when the user clicks on green button. Later, we will add a hook for adding in dbus, roster etc., as you wrote. I see in the bug report there are several things involved, such as PresenceCode; so is it there to add this hook? The change to ekiga current code should be very small, only 2 lines (call your pstn file and replace the URL bar value). In fact, all your work can be resumed like this: when the user pushes the green button (or dbus, roster etc.), the number in the URL bar is transformed, that's all, isn't it? Some background material: usecases defined in a few "stories:" http://mumin.dnsalias.net/ekiga-callto-ui/stories.html I agree. Additionally, I have some comments: 1. Note that ekiga already adds the suffix (it shows it in the combobox, but it adds it too) 2. What happens when you have two accounts? Which one does it choose? (We can think about this later, let's do it step by step, as you propose.) 3. How does this integrate with ekiga-callto program/package, i.e. who does the url changing, ekiga-callto or ekiga itself? 4. I do not know curl well, why is it needed? What should you retrieve? Does regex create problems on windows or macos? Do you think it is useful to add a wiki page and add there the steps we will to implement, to avoid errors later? Or do you prefer to push your current patches, in one step or step by step? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
Simos wrote: On Sun, Mar 29, 2009 at 1:36 PM, Alec Leamas 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 +... 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:+46705434...@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
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
On Sun, Mar 29, 2009 at 1:36 PM, Alec Leamas 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 >> +... 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:+46705434...@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
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
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 +... 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? Cheers! --a [cut] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
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 +... 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. This makes the basic process to call a PSTN number hard, user has to manually convert e. g., '070-543 22 11' to sip:+46705432...@sip.diamondcard.com. The further spreading of electronic notepads and mobiles will lead to such old paper form notation habits vanish soon since the softwares do not support it either, "-" and " " may still even crash many webforms. So: first question: Would this overall be a Good Thing, something that makes Ekiga more usable, and thus worth some effort? No. At all love to ergonomics, users should adapt their habits to new techs a little and it is not our job to "fix" some Providers uncool switches. y tom ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)
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. This makes the basic process to call a PSTN number hard, user has to manually convert e. g., '070-543 22 11' to sip:+46705432...@sip.diamondcard.com. I have written a piece of code which converts numbers to sip: urls. It's partly a question of handling missing country codes, partly to remove formatting characters as in '070- 543 11 22'. This code of course requires some configuration to define user's own countrycode etc. (all in total four values). It generates default config values usable for most users, and seems to work. It has the potential to let users just enter e. g., 070-543 22 11 in Ekiga to place a call instead of a complete URL. My problem is if/how to integrate this into Ekiga. More precise, I need help to integrate it. The Ekiga code is big, and although I think I'm able to produce a set of patches, I will at least need help with where in the code I should begin, and certainly other things as well. I really can't be on my own in this, it's to much for a newbie... So: first question: Would this overall be a Good Thing, something that makes Ekiga more usable, and thus worth some effort? Second question. I have done a simple plan: http://mumin.dnsalias.net/ekiga-callto-ui/patches.html. Is this reasonable? Third question. There is some UI impact, described in http://mumin.dnsalias.net/ekiga-callto-ui/index.html. Does this seems OK? Last question: Depending on the outcome of the other questions, how should I proceed with the first patch, to integrate a set of new source files related to PSTN management into Ekiga? Some background material: usecases defined in a few "stories:" http://mumin.dnsalias.net/ekiga-callto-ui/stories.html ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
