[Blink] Support for rules on outgoing calls

Sat Jun 9 10:51:46 CEST 2012

Hi Egidio,

Your comments are reasonable, so is worthwhile arguing with you from my perspective ;-)

On Jun 9, 2012, at 7:48 AM, Egidio Corsini wrote:

> Dear Adrian, 
> 
> to answer your last point from a user perspective, I'd say you are right, in a perfect world. I agree that letting the server sort out general rules is the cleanest idea. Unfortunately the users don't always have access to server's configuration and in these cases an option to quickly sort out a blocking issue without changing the server configuration is very handy.

I would not pass the responsibility for fixing all the addressing that is poorly designed into the network to the client. This can translate into infinite work generated by the mess of dealing with phone numbers. Better handle this into the corporate PBX, which has more knowledge about all these rules that may even change often. You cannot expect enterprise users to correctly manage their own translation rules, this is the job of the IT department.

> I believe I'm in a fairly typical situation for an enterprise:

After hundreds of thousands of downloads and several years in service in many places including large corporations nobody came up with such requests for advanced number management. Imagine what user interface will sit on top. Complexity, ugliness, all the bad stuff that comes with managing phone numbers. Look at Skype and you will understand why Voip applications using SIP has less users.  Because of entrenched thinking that phone numbers form a central place of a real time communication application.

Enterprises always have centralized VoIP server infrastructure where all these rules are provisioned and configured.
> VoIP infrastructure between several country
> VoIP phone
> Internal numbering
> External prefix
> External calls routed locally, International calls routed as local where possible
> Into this environment a typical User

This is subject to interpretation...

> will have a VoIP phone with an address book downloaded from the server.

So that server is the one responsible, that is the source where things need to be normalized. The VoIP server and address directory are usually synced and configured by the same IT department.

> Hence internal calls are sorted through the local address book while for external calls the user will know what number to dial. On a desktop client you would expect a little more.

I won't debate the usefulness of what you ask as it certainly adds value to those who need such features, like you.

20 IFs  and tons of arbitrary regular expressions belong to a server configuration file rather than a client with an intuitive GUI.
> Integration between the server distributed address book (I know this can be a mess and to be honest I haven't seen any client doing it properly)
And for understandable reasons, is close to impossible as you cannot always  guess in a client what the server already knows. Better solve this in the server. 
> Seamless integration with your local address book (where by seamless I definitely do not intend: change your address book in order to comply with SIP rules...)
> As a user I would expect the highest level of integration possible between whatever contact list (server based, address book, LDAP, XML, Outlook, social networks, etc.) and the client used to place SIP calls. This in my humble opinion is core area for any client willing to replace a VoIP phone or willing to enable a mobile office.

As a generic SIP client we aim to strike a good balance between features. VoIP is just one feature of Blink, not the only one. Most users just us it for VoIP but the software is good because we always aimed at a broader feature set and phone numbers.

> Probably this is different if I'm a user of an external SIP server where I have to deal exclusively with external numbers. In this case I would not see the necessity to rewrite number. But I've never been into this situation, so I can't really say what would be the experience.
> 
> Thanks anyway for the interest shown in answering my question. To remain in the perfect world I would still suggest to build a use case scenario for an enterprise user and see whether you can really do everything server side or the need for some rules still exist.

The current feature-set seem to meet most of the requirements that we received from our enterprise customers. In the end is a cost/benefit issue, and development for corner cases with no visible return is a waste of resources.

Last but not least, phone numbers are a poor addressing model from the past and Blink started from a completely different philosophy.

Adrian

> 
> Best regards,
> 
> Egidio
> 
> On Fri, Jun 8, 2012 at 6:55 PM, Adrian Georgescu <ag at ag-projects.com> wrote:
> This is a good idea, applying such routing and translation rules in your PBX or Voip Server.
> 
> Expecting a generic SIP client to sort out the mess of the many phone number formats of external phone directories is not.
> 
> Adrian
> 
> On Jun 8, 2012, at 6:51 PM, A.M. wrote:
> 
> >
> > On Jun 8, 2012, at 12:35 PM, Egidio Corsini wrote:
> >
> >> Thanks for your answer.
> >>
> >> As an example of what I'm saying you myght want to have a look to the Acrobits softphone client for iPhone where you have arbitrarily complex number rewrite rules for a single account. This is very handy if you need to use an account for intranet and external calls.
> >> Having to modify the addressbook for this purpose would be a) extremely time consuming b) would have significant impact (i.e. my addressbook is in sync with my mobile and this change would impact the ability to have standard phone numbers for Italy in the form of +39 xxxxxxxx)
> >>
> >> Is this feature in your roadmap or am I the first one to ask for such an option?
> >
> > This is the sort of routing that is typically handled by a sip proxy. Generally, your organization's sip proxy is responsible for routing, not the individual phones. (It's the same with old POTS phones.)
> >
> > Cheers,
> > M
> >
> >
> >
> > _______________________________________________
> > Blink mailing list
> > Blink at lists.ag-projects.com
> > http://lists.ag-projects.com/mailman/listinfo/blink
> >
> 
> _______________________________________________
> Blink mailing list
> Blink at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo/blink
> 
> _______________________________________________
> Blink mailing list
> Blink at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo/blink

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/blink/attachments/20120609/4770d4c8/attachment.html>