[Blink] Support for rules on outgoing calls

Egidio Corsini egidio.corsini at gmail.com
Sat Jun 9 07:48:29 CEST 2012

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 believe I'm in a fairly typical situation for an enterprise:

   - 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 will have a VoIP phone with an address
book downloaded from the server. 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.

   - 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)
   - 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.

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.

Best regards,


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/blink/attachments/20120609/6ed1de4e/attachment.html>

More information about the Blink mailing list