Graphical Representation of the Call Flow of an OBi In/Outbound Call

[Everton]

Since I brought the Obi110, I have been grappling with the interrelationship between:

a) DigitMap (Phone, sp1, sp2, OBiTALK Service, Auto Attendant, Gateway & Trunk Group, User Defined DigitMap)

b) Inbound Call Route (Voice Services [sp1 and sp2], OBiTALK Service, Line)

c) Outbound Call Route (Phone, Auto Attendant)

d) Primary line selection

Bottom line is the Obi Device is not your basic ATA.  To better understand what role each play with respect to inbound and outbound calls, it would be desirable if OBiSupport (or RonR) could put together some form of call flow diagram.  I would like to see what happens when an outbound call is place from the Phone Port and what occurs when an inbound call is receive on the SP1 or SP2 or via OBiTalk.

For instance, when a caller picks up the phone and dials 1-aaa-xxx-xxxx, what takes place internally in the Obi device?  Does it first check the DigitMap associated with the Phone Port?  What's next?  How does it know to check a Voicegateway X or send the call out through the provider on sp2?

If a graphical representation could be made, which shows all these components and how they interrelate when a call is placed and when a call is received, then I think I will be better able to make changes to the various components to better route inbound/outbound calls.  I need to have a better understanding of the inter-dependencies of these various variables.  Right now, I'm completely lost and I suspect, most users are.

[infin8loop]

Here is a flow chart.

[RonR]

Everton,

Placing outbound calls and receiving inbound calls are two totally separate operations in the OBi.


Outbound Calls

When a number is dialed through the PHONE Port, only the PHONE Port DigitMap is scanned for the best matching rule:

([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp)|(Mpli))

Note, however, that the PHONE Port DigitMap indirectly references several other DigitMaps:

(Msp1) : SP1 Service (Service Providers -> ITSP Profile A -> General -> DigitMap)
(Msp2) : SP2 Service (Service Providers -> ITSP Profile B -> General -> DigitMap)
(Mli) : LINE Port (Physical Interfaces -> LINE Port -> DigitMaP)
(Mpp) : OBiTALK Service (Voice Services -> OBiTALK Service -> DigitMap)
(Mpli) : Primary Line ([Physical Interfaces -> PHONE Port -> PrimaryLine] -> DigitMap)

If no matching rule is found, the call is aborted and a fast busy tone is played.

Default dialing normally finds the matching rule through the DigitMap selected as the Primary Line (Mpli).  For example, if a 10-digit number is dialed and the Primary Line is SP1, the |<1>xxxxxxxxxx| rule of the ITSPA DigitMap would match the 10 digits when the (Mpli) reference is encountered.  This rule also performs a transformation on the dialed number, adding a leading '1' to it.

The PHONE Port OutboundCallRoute is then scanned for the first rule that matches the number resulting from the scan of the PHONE Port DigitMaP:

{([1-9]x?*(Mpli)):pp},{(<#:>|911):li},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},
{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}

Note that the PHONE Port OutboundCallRoute also indirectly references the same DigitMaps as the PHONE Port DigitMap.

Continuing the previous example of a 10-digit number having been dialed and transformed into an 11-digit number with a leading '1', the |1xxxxxxxxxx| rule of the ITSPA DigitMap would match the 11 digits when the (Mpli) reference of the {(Mpli):pli} rule is encountered.  The Primary Line (:pli) would be the trunk used for the call, which is SP1 in this example.


Inbound Calls

Each trunk (SP1, SP2, OBiTALK, and LINE) has an InboundCallroute that is scanned when a call arrives on that particular trunk.  The default rule on each of these trunks is simply 'ph', which unconditionally sends the incoming call to the PHONE Port endpoint.

An InboundCallRoute is scanned for the first rule that (optionally) matches the caller's CallerID and/or the destination number pattern.  The first rule to match determines the trunk or endpoint that receives the call:

{CallerID>(DigitMap):trunk},{endpoint}

In this example, the incoming call would be routed to trunk if the call is from the CallerID and the destination number matches the (DigitMap).  If the first rule fails, the second rule unconditionally routes the call to the endpoint.


I would recommend a careful reading and understanding of pages 111 - 122 of the OBi Device Administration Guide as a starting point.  If I can clarify anything, feel free to ask.