SIP Account Settings Suggestion

[GoogleCodeExporter]

For each SIP account allow:
Protocol and Port number to be set, for conflicting SIP accounts.
Multiple Regex to specify ranges, eliminating need for user to choose SIP 
account every call.
Account ordering, so first SIP account with matching Regex makes the call.
Regex rewrite to format numbers for each SIP account if necessary.

Thanks.

Original issue reported on code.google.com by kro...@gmail.com on 28 May 2010 at 1:54

[GoogleCodeExporter]

For the protocol / port number should be already managed by current wizards (at 
least
the expert one), maybe more wizard should be added in the future (I though 
about an
Advanced one between Basic and Expert). (Note : sipS is maybe not really well
implemented yet - i didn't tested it yet)

Multiples regexp by account for outgoing calls are planned (and some wizards 
will
pre-fill it to tie the registrar free destinations). 
I'll try to design an user friendly interface that sum up the configuration for
outgoing call. 
Regexp will be only available in an advanced mode (most of users it will be 
filled by
their account wizard or if needed with some "starts with or exact" filters).

This filters / regexp will then allow to announce that the sip account (or the 
gsm)
"CAN/CAN'T/MUST" handle an outgoing call.
Then for a given outgoing call, 
If only CAN accounts are found, the popup will ask the user to choose
If a MUST is find the must will handle the call.
And if the user CAN'T it will be excluded from the popup if any.

(In the MUST case, there is a problem with the fact that when the outgoing call 
is
asked, the account is not necessary registered yet, but it can be solved with a 
good
user interface).

What is important to me is to keep the standard interface really easy to use 
for the
main stream users. But I also want to provide a way for expert users or users 
that
want special features, to access Advanced interfaces (with a less stylized UI) 
that
allow to tweak things.

For your last point, I don't really understand. Is there sip providers that 
need a
specific format for called numbers? If so, that's not really a problem to 
implement
(I just wonder what are the reason that can lead sip providers to ask a specific
formatting - unless it is prefixes or things like that but if there is prefixes 
there
is internal number and I should not rewrite numbers)...

By the way, many thanks for all your suggestions !

Original comment by r3gis...@gmail.com on 28 May 2010 at 9:42

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

My last point is more of convenience, so I can default my city code when I 
don't prefix one.  ^([^0].{6})$,09\1

Original comment by kro...@gmail.com on 29 May 2010 at 8:22

[GoogleCodeExporter]

I have another related suggestion.

Add an advanced options menu to Basic and dump Expert.  That way, a user 
doesn't have to discard a basic 
setup, if Basic isn't enough and it gives more control if needed at a later 
date.

As for Wizards, put a pull down menu into Basic, that changes the Basic and 
advanced settings to suit.  That 
way users can see the settings, for interest or to learn, can make changes to 
suit their own needs, or use a 
wizard as a base for another sip website that doesn't have its own wizard.  
Drop separate lock in Wizards.

This way, the user doesn't get locked into a setup, can switch on demand, can 
play with advanced options, and 
learn more about a particular sip site.

Original comment by kro...@gmail.com on 29 May 2010 at 8:42

[GoogleCodeExporter]

Ok for your two lasts comments, I'll implement these points too.
(The wizard dynamic change was already planned, I have to solve some design 
issues to
ensure account is not in a bad state but should be easy to do)
Besides, many other sip providers will be added soon, I'll try to make a 
priority per
language or something like that.

Original comment by r3gis...@gmail.com on 29 May 2010 at 9:50

[GoogleCodeExporter]

Issue 58 has been merged into this issue.

Original comment by r3gis...@gmail.com on 22 Jun 2010 at 7:10

[GoogleCodeExporter]

Issue 99 has been merged into this issue.

Original comment by r3gis...@gmail.com on 20 Jul 2010 at 10:15

[GoogleCodeExporter]

Issue 109 has been merged into this issue.

Original comment by r3gis...@gmail.com on 26 Jul 2010 at 12:39

[GoogleCodeExporter]

It would be also nice to add CallThrough and classical or web based CallBack.

Original comment by mathias4...@gmail.com on 26 Jul 2010 at 8:36

[GoogleCodeExporter]

Issue 104 has been merged into this issue.

Original comment by r3gis...@gmail.com on 8 Aug 2010 at 9:23

[GoogleCodeExporter]

Issue 47 has been merged into this issue.

Original comment by r3gis...@gmail.com on 8 Aug 2010 at 9:32

[GoogleCodeExporter]

r189 now fix rewriting rules issue.

Original comment by r3gis...@gmail.com on 9 Aug 2010 at 12:35

• Changed state: Started

[GoogleCodeExporter]

Last things remaining for this issue is to fix issue 282.
Mark this issue as fixed for other points.

Original comment by r3gis...@gmail.com on 13 Oct 2010 at 7:08

• Changed state: Fixed