OBiTALK Community

General Support => Day-to-Day Use => Topic started by: MichiganTelephone on February 09, 2011, 06:11:30 AM

Title: What's wrong with this pattern?
Post by: MichiganTelephone on February 09, 2011, 06:11:30 AM
Hi, am having a bit of a hard time understanding the OBi dial patterns - I thought I had figured this out but apparently not (which is embarrassing because I used it in an article).  What I'm trying to do is use SP2 as a link to an Asterisk box.  If a call arrives FROM Asterisk, I want it to be routed one of two ways:

If the call is to an 11 digit number (Asterisk will make sure it's formatted as 11 digits), I want it sent to SP1.  This works fine as long as I just put sp1 in the X_InboundCallRoute of SP2.

If the call is to an OBi number (ob+9 digits) I want it sent to PP.  This works fine as long as I just put pp in the X_InboundCallRoute of SP2.

The problem is that I want to use X_InboundCallRoute to detect which way the call should be routed and send it appropriately.  Without getting into the separate issue of the need to prepend "ob" to OBiTALK calls (which apparently is something that X_InboundCallRoute can't detect, unless I'm just doing it wrong), I had THOUGHT that the following would work:

{1xxxxxxxxxx:sp1},{pp}

I could have sworn that this worked a couple of days ago but it doesn't today, and from my call history I can see that what's happening is that when a call arrives in the 1xxxxxxxxxx format, it's still getting sent to "P2P1" (whereas, if I change the pattern to JUST sp1, it gets sent to "GoogleVoice1"). I also tried {(1xxxxxxxxxx):sp1},{pp} but that didn't work either.  As I say, I can see the call in the call history and the rightmost field of the Peer Number line shows that the correct 11 digit number is being received, but for some odd reason it's not matching on the 1xxxxxxxxxx pattern, and I do not understand why.

What I'd IDEALLY like to do is this:
If the call matches 1xxxxxxxxxx, send it to SP1
If the call matches obxxxxxxxxx, send it to PP
If the call matches xxxxxxxxx (9 digits) prepend "ob" and send it to PP.

But right now I'd be happy if you could help me understand what's wrong with my original pattern and what I need to change to make it work as intended.
Title: Re: What's wrong with this pattern?
Post by: MichiganTelephone on February 09, 2011, 06:55:55 AM
Okay, after looking at the documentation yet one more time it finally hit me that this is looking at the incoming Caller ID number, not the outgoing number — that explains a lot but still makes me wonder if it's possible to route based on the called number rather than the Caller ID number.
Title: Re: What's wrong with this pattern?
Post by: QBZappy on February 09, 2011, 07:22:58 AM
I tried this on my unit it works.

Set this up in the Setup Wizard->Outbound Settingshelp->ITSP DigitMap
{(<1xxxxxxxxxx:>(Msp1)):sp1},{(<2xxxxxxxx:>(Mpp)):pp} <- note the 2 (I think all Obi units start with a 2. It might be better to hard code with this "2" digit). Place this in front of the current outbound dial plan if you plan to keep the other call process rules (don't forget the "," comma to separate the rules. Obi handles call process from left to right.

Your comment:
"If the call matches obxxxxxxxxx, send it to PP"

I'm not sure what this means. What does "ob" mean in front of xxxxxxxxx in the dial out?

Hope this works.
Title: Re: What's wrong with this pattern?
Post by: obiliving on February 09, 2011, 08:13:56 AM
Michigantelephone,

Your very first example shows 1 common error: missing the enclosing ( ).
In order for OBi to apply digit map rules on patterns like 1xxxxxxxxx, it has to be
enclosed in parenthesis. You have corrected that in your 2nd example; but that's not what you intended.

OBi can route inbound calls based on caller number and/or called number.
A caller>called pair is referred to as a peering. The general format of a peering is:

    some-caller > some-callee

where some-caller and some-callee can be a digit map (enclosed in parenthesis) or
plain number. In fact, to the left side of the colon (:) in each inbound call route rule, you
can put more than 1 peering; just separate them by a comma. This is called a peering-list.
OBi will OR the peering's when checking the inbound call route rule.

Back to what you wanted to do. You don't care about who's calling (from OBi's point of view); you only want to check if a 11-digit number is called and let it go to sp1. Here is 1-way I can think of:

   {>(1xxx xxx xxxx):sp1}, {>(<ob> xxx xxx xxx):pp}

Note how the second rule pre-pend the 9-digit number before sending it to pp (OBiTALK) trunk.
Please give it a try and let us know how it goes.



Title: Re: What's wrong with this pattern?
Post by: MichiganTelephone on February 09, 2011, 08:30:34 AM
OTZappy, thanks, but at this point I'm beyond using the Setup Wizard (it would likely wipe out other needed settings).  You would be wrong to assume that all OBi numbers start with a 2, my OBi100 starts with a 3 (I suspect it would be safe to assume that none start with a 1, though).  Actually, once I figured out that it was matching on incoming Caller ID, that actually made things easier for what I was trying to do, though it also meant I had to do a fairly significant rewrite of my article.   :-[

As for the "ob", if you look in the call history after you place an OBiTALK network call (in the normal manner) you will see that the outgoing number is prefaced with "ob".  Apparently the OBi automatically adds this somewhere if you call from the phone port, but if you try to bridge a call coming in from another service provider it doesn't do that, so you have to send the call with the "ob" already prepended to the number.  Perhaps this could be considered a bug, I don't know, but I do know that it would not work until I sent it with the ob prepend.

I will also offer an opinion here:  The OBi Device Administration Guide is very good and in most places very clear.  The exception is the part where it deals with inbound and outbound call route configuration.  I must have read the section on Inbound Call Route Configuration at least four or five times (seems like more than that) and it really doesn't make that much sense to me, as evidenced by the fact that it wasn't until the last reading that I realized it was matching on the incoming caller ID and not the number called.  I get the feeling those sections were written by programmers, which (if true) is okay if your intended audience is other programmers.  If, however, you want to communicate this information in a way that users of this device can understand it, it would help to set out the basic principles in plain English.  I mean, can anyone without a programming background understand this?

QuoteThe general format is:
InboundCallRoute := rule OR {rule},{rule},....  
Note that the curly braces may be omitted if there is only one rule in the route. The OR operator is NOT part of the
parameter syntax; it is used here to separate alternative values only.

A rule has the following format:
rule := peering-list : terminal-list
where
peering-list := peering,peering,...  (comma separated list of 0 or more peering object)
terminal-list := terminal,terminal,....  (comma separated list of 0 or more terminal object)
peering := caller-list > callee-list  
caller-list := caller|caller|caller|...  (vertical bar separated list of 0 or more caller object)
callee-list := callee|callee|callee| ...  (vertical bar separated list of 0 or more callee object)
caller := number OR embedded-digit-map OR ? OR @  (?=anonymous, @=any number but anonymous)
callee := number OR embedded-digit-map OR @  
terminal := PHx OR AAx OR LIx(arg) OR SPx(arg) OR PPx(arg)  (arg object is optional)
arg := cid > target    
x := 1 OR 2 OR 3...    (where applicable; can be omitted if it is equal to 1)
cid := spoofed-caller-number OR $1
target := number-to-call OR $2
embedded-digit-map := (Mlabel) OR digit-map

???  ???  ???

I DO NOT understand most of that.  I might someday, but I don't now.  There has to be some way to make that clearer.  At least I would hope there is.
Title: Re: What's wrong with this pattern?
Post by: MichiganTelephone on February 09, 2011, 08:45:33 AM
obiliving, thank you, that looks like what I was originally trying to do.  I'll give it a try in a little bit and let you know.
Title: Re: What's wrong with this pattern?
Post by: MichiganTelephone on February 09, 2011, 09:13:31 AM
Quote from: obiliving on February 09, 2011, 08:13:56 AM
Back to what you wanted to do. You don't care about who's calling (from OBi's point of view); you only want to check if a 11-digit number is called and let it go to sp1. Here is 1-way I can think of:

   {>(1xxx xxx xxxx):sp1}, {>(<ob> xxx xxx xxx):pp}

Note how the second rule pre-pend the 9-digit number before sending it to pp (OBiTALK) trunk.
Please give it a try and let us know how it goes.

That appears to be working exactly as I wanted it to.  ;D  I assume the spaces are optional, correct?  Anyway, thank you very much for clarifying this.  This unit has some very advanced routing capabilities but understanding how to actually use them can be a bit of a challenge (well, at least for me, but then again I'm not always the brightest bulb on the tree!)
Title: Re: What's wrong with this pattern?
Post by: obiliving on February 09, 2011, 10:07:26 AM
Space is legal and optional in digit maps and call routing rules; added just to
make it more readable.

One last comment...
In the general peering syntax: some-caller > some-callee,
the '>' is optional if 'some-callee' is empty (i.e., any called number) for InboundCallRoute.
In other words, without '>', the argument (if not empty) is treated as the caller-number.
In most cases you only specify the "some-caller" party without the '>'.

OutboundCallRoute for PHONE Port and AA, on the other hand, has very similar syntax but
you only specify the 'some-callee' part without the '>'.

Title: Re: What's wrong with this pattern?
Post by: MichiganTelephone on February 09, 2011, 10:54:28 AM
Thank you again, obiliving.  That helps my understanding of this quite a bit.  I've added a link to this thread from my article (http://michigantelephone.wordpress.com/2011/02/06/how-to-use-the-obihai-obi100-or-obi110-voip-device-as-a-gateway-between-asteriskfreepbx-and-google-voice-andor-the-obitalk-network/) (revised again  ::)) so that anyone else who wants to know how this works will be able to find it.