Using Speed Dial Number as Ad Hoc Gateway

[QBZappy]

Lifted from Admin Guide:

If an external gateway does not require authentication, its access number can be stored in one of the 99 speed dial slots to allow ad hoc direct dialled gateway calls. To do this, the user dials the gateway's speed dial, followed by a *, followed by the target number. That is <gateway-speeddial> * <target-number>. For example, the gateway access number pp(ob200333456) is stored at speed dial 8, and the user can dial 8*14085551234 to call 14085551234 using the given gateway.

Note: At the present time, only gateways that are accessed with an OBi number can be used this way.

This seems to be by far the easiest way to make an outgoing call using another OBi located far away. Dead simple.

[RonR]

That's the OBi-to-OBi single-stage dialing mechanism that was added when 1.2 was first released.  You must have an OBiTALK Service InboundCallRoute rule in place in the receiving OBi to accept the call from the sending OBi (or OBiON App) and route the target number to a particular trunk or the call will simply go to the receiving OBi's PHONE Port.  For example:

Voice Services -> OBiTALK Service -> InboundCallRoute : {200123456>(xx.):sp1},{ph}

That's the very limited single-stage dialing rule configured by the OBiTALK Web Portal that's only capable of dialing though the receiving OBi's PrimaryLine (SP1 in the example above).

[QBZappy]

RonR,

In the OBiTALK portal, if you have both an OBi unit and an OBiAPP registered, the OBiAPP will allow you to pick a "OBi Voice Gateway" from a pick list. If you click on the OBi unit icon, similar ability does not exist. This would imply (or gives the impression) that the OBiTALK Service InboundCallRoute rule config is not necessary to setup for the OBiAPP. Calling a far away OBi unit using an OBi or an OBiAPP should require something similar to what you suggested for both the OBi unit and the OBiAPP. Is this not so?

Voice Services -> OBiTALK Service -> InboundCallRoute : {200123456>(xx.):sp1},{ph}

[RonR]

It's easy to prove.  Set the receiving OBi:

Voice Services -> OBiTALK Service -> InboundCallRoute : ph (Default)

and you'll see your call goes straight to the PHONE Port.

(Speed Dial) * (Destination Number) simply goes to the OBiTALK Service trunk by virtue of this PHONE Port DigitMap / OutboundCallRoute pair:

([1-9]x?*(Mpli) / {([1-9]x?*(Mpli)):pp}

The OBiTALK Service trunk is sensitive to the ? * ? pattern and (1) extracts and removes the digits preceding the * to address a Speed Dial, (2) removes the *, and (3) sends the number after the * to the OBi whose OBiTALK number is contained in the Speed Dial.

It's up to the receiving OBi's OBiTALK Service InboundCallRoute to do something with the incoming call and the number (if any) that was passed to it.

The 'OBi Voice Gateway' in the OBiTALK Web Portal is used to select an OBI to be set as the Voice Gateway value in an OBiON App.  It's probably also used to decide which OBi is to have it's OBiTALK Service InboundCallRoute configured as previously discussed.

Keep in mind that all the OBiTALK Web Portal does is configure (on a very limited basis) settings and rules in an OBi.  It doesn't get involved in the actual processing or handling of calls.

[QBZappy]

The 'OBi Voice Gateway' in the OBiTALK Web Portal is used to select an OBI to be set as the Voice Gateway value in an OBiON App.  It's probably also used to decide which OBi is to have it's OBiTALK Service InboundCallRoute configured as previously discussed.

Keep in mind that all the OBiTALK Web Portal does is configure (on a very limited basis) settings and rules in an OBi.  It doesn't get involved in the actual processing or handling of calls.

How can the OBiAPP reach far away OBi unit if it is not preconfigured in the OBiTALK Service InboundCallRoute rule? Is the OBi portal involved in the configuration of the far away OBi when you select the OBiAPP gateway using the portal?

[RonR]

How can the OBiAPP reach far away OBi unit if it is not preconfigured in the OBiTALK Service InboundCallRoute rule?

Any OBiAPP can reach any OBiTALK destination by dialing **9 + OBiTALK_Number, using the OBiTALK Voice server to get connected.  Anything dialed from an OBiAPP without **9 is directed to the OBiTALK number stored in the OBiAPP's Voice Gateway with the dialed number passed as data, also using the OBiTALK Voice server to get connected.  The only way to set the OBiAPP's Voice Gateway is from the OBiTALK Web Portal (a terrible limitation!).

Any OBiTALK Service call arriving at an OBi is processed by the OBiTALK Service InboundCalRoute and routed accordingly.  The default is to simply send all calls to the PHONE Port.  Appropriate rules can route the call to any trunk or terminal based on origin (CallerID) and/or called number (embedded DigitMap).

Is the OBi portal involved in the configuration of the far away OBi when you select the OBiAPP gateway using the portal?

I've never investigated whether selecting an OBi as the Voice Gateway on the OBiTALK Web Portal selects that particular OBi for OBiTALK Service InboundCallRoute configuration or if it simply configures all OBi's on that account the same.  Either way, I believe the target OBi ends up with the set of rules that limits single-stage dialing to the PrimaryLine only and does no validation of the called number:

Voice Services -> OBiTALK Service -> InboundCallRoute : {200123456>(xx.):sp1},{200123456:aa},{ph}

The rule in bold sends trusted callers to the Auto Attendant if no single-stage dialing number-to-call was passed.