Digit Map and Call Route interpretation for OBiTalk

[larrybob]

These are the default parameters ( I have two devices in my account). Can someone explain what the incoming call route does,and where the "ob" comes from and what that does?
(<ob>xxxxxxxxx|obxxxxxxxxx)
{(290122004|200276897)>(xx.):LI},{(290122004|200276897):aa},{ph}
It looks like incoming calls go to the line??and the AA or to the phone ? where does obxxx xxx xxx come from how does "ob"get attached to a number?
I have a second Account and the default call route is different:
{(290183615)>(xx.):SP1},{(290183615):aa},{ph}
why is the default here for Sp1, how does this affect things..
Thanks Larry

[RonR]

(<ob>xxxxxxxxx|obxxxxxxxxx)

This is the OBiTALK Service DigitMap and is not part of any InboundCallRoute.  When 9-digit OBiTALK numbers are sent to the OBiTALK Service trunk, they are supposed to prefixed with 'ob' (the reason for this is undocumented).  The OBiTALK Service DigitMap prepends 'ob' if it's not already present.  The 'ob' prefix is not used anywhere else.

{(290122004|200276897)>(xx.):LI},{(290122004|200276897):aa},{ph}

This is an OBiTALK Service InboundCallRoute generated by the OBiTALK Web Portal.

The first rule:

{(290122004|200276897)>(xx.):LI}

compares the incoming CallerID to OBiTALK numbers 290122004 and 200276897.  If a match is found and the called number is any string of digits (xx.), the call is bridged to the LINE Port (the PrimaryLine).  This is a poorly written rule in that the number called may not be in a suitable format for the LINE Port.  This rule should have been generated as:

{(290122004|200276897)>(Mli):li}

The second rule:

{(290122004|200276897):aa}

compares the incoming CallerID to OBiTALK numbers 290122004 and 200276897.  If a match is found and there is no called number, the call is bridged to the Auto Attendant.

The third rule:

{ph}

bridges all other callers to the PHONE Port.

{(290183615)>(xx.):SP1},{(290183615):aa},{ph}

This is an OBiTALK Service InboundCallRoute generated by the OBiTALK Web Portal.

The first rule:

{(290183615)>(xx.):SP1}

compares the incoming CallerID to OBiTALK number 290183615.  If a match is found and the called number is any string of digits (xx.), the call is bridged to the SP1 Service (the PrimaryLine).  This is a poorly written rule in that the number called may not be in a suitable format for the SP1 Service.  This rule should have been generated as:

{290183615>(Msp1):sp1}

The second rule:

{(290183615):aa}

compares the incoming CallerID to OBiTALK number 290183615.  If a match is found and there is no called number, the call is bridged to the Auto Attendant.  The parenthesis around the OBiTALK number are unnecessary in this case, so the rule could have been written as:

{290183615:aa}

The third rule:

{ph}

bridges all other callers to the PHONE Port.

[larrybob]

Ron,
I am trying to understand the purpose of the first rule . I am guessing that part of it is for the operation of the soft phone.  Why is also 200276897 ( the obi number of the box in this rule?)

I understand that when a call is received on Sp1, or sp2,( if they have a DiD number ) or line, the obi can pick up an incoming caller ID, if a call is sent to the AA , then after the voice prompt, and outgoing number can be added.

I assume that the way to call an obi device from another obi device is by using **9 or a digitmap that will route the call through **9. Here the caller id received by a  second device will be the OBi number of the calling obi device.

1) Where does the call come from to have both then caller id of the obi box itself, ( here 200276897) and a called  number at the same time.?
      I am guessing that a number called with the softphone ( 290122004) could have both a caller Id, and a called number?  However, an inbond call with a self inbound caller id confuses me.

Quoted from Ron R:
"This is an OBiTALK Service InboundCallRoute generated by the OBiTALK Web Portal.

The first rule:

{(290122004|200276897)>(xx.):LI}

compares the incoming CallerID to OBiTALK numbers 290122004 and 200276897.  If a match is found and the called number is any string of digits (xx.), the call is bridged to the LINE Port (the PrimaryLine). "

[RonR]

When you use the OBiTALK Web Portal to configure an OBi, it generates an OBiTALK Service InboundCallRoute containing all the OBiTALK numbers you placed in the Circle-of-Trust list.  You must have included 200276897 in the Circle-of-Trust list.  Don't expect any optimization or intelligent configuration from the OBiTALK Web Portal.

As you suspected, the OBiTALK Service protocol does have the ability to send a call to a particular OBiTALK number, passing both a CallerID and a called number.  The CallerID and called number can then be processed in the InboundCallRoute as previously described.

[larrybob]

Thanks Ron!

I went back and checked all 5 accounts I set up . Half of them have the  self OBi number of the obi device included in the incoming call route rule to OBiTALK. The other half do not. None of the tursted callers have an OBi Talk Number.

It seems that something I am doing in some of the setups is triggering the OBi number of the device to be included in its incoming call route to OBiTalk.

I am glad that you confirmed that there is no apparent usefulness to this. Thanks to all your help , I believe I am finally starting to understand all of this.

larry

[RonR]

Larry,

IIRC, you started out having the OBiTALK Web Portal configure your OBi's and had populated the Circle-of-Trust list at that point.  Later, you started making changes to the InboundCallRoutes through the OBi Expert area and removed all OBiTALK numbers from the Circle-of-Trust list.  When you maintain a setting though the OBi Expert area, you take full control of that setting starting with whatever was previously there.