Using Speed Dial Number as Ad Hoc Gateway

<< < (2/2)

RonR:
Quote from: QBZappy on October 01, 2011, 03:37:43 pm

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

Quote from: QBZappy on October 01, 2011, 03:37:43 pm

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.

Navigation

[0] Message Index

[*] Previous page