News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

detect DID

Started by mrjoli021, March 05, 2014, 08:08:03 AM

Previous topic - Next topic

mrjoli021

My provider gives me two DID's.  I would like DID 1 to only ring in port1 and DID 2 to only ring in port2.

I have changed "X_InboundCallRoute" to
(14441234567):ph1,(13331234567):ph2
{(14441234567):ph1},{(13331234567):ph2}
(+14441234567):ph1,(+13331234567):ph2
{(+14441234567):ph1},{(+13331234567):ph2}

and none of the above combinations seem to work.  When I just do
(14441234567):ph1,ph2

it has no affect and both lines still ring on port1 and port2.  What would the correct syntax be and is there something else I am missing?

thanks

azrobert

#1
The only things you can check on an inbound call is the caller's callerid and/or your userid for the provider.

The format you are using is checking for the callerid.

Does your provider have sub-accounts and support call routing?
If yes, you can setup the main account on SP1 and the sub-account on SP2.
Setup routing at your provider to route DID#1 to the main account (SP1) and DID#2 to the sub-account (SP2).
In the OBi route SP1 to PH1 and SP2 to PH2.

I know Callcentric can do this.

mrjoli021

My provider doesnt provide that. All my provider gives me is two DID's and then I manage them.  How can I have one DID ring on port1 and the other on port2?

azrobert

You only can route calls based on callerid, so if people from a/several area(s) of the country only call DID#1 you could route to PH1 based on area code. All others would be routed to PH2.

I live in the Scottsdale area and we have several area codes (480 602 623).
You could setup an inbound route like this:

{(1?(480|602|623)xxxxxxx):ph1},{ph2}

There is no limit on the number of area codes. There is a max length for the rule. I don't remember what that number is, but it's large.

Sorry, this is the best I can do.

giqcass

Tell us the provider and maybe someone here will know a setting that can be made on the providers side.
Long live our new ObiLords!