One of the key troubleshooting tools of OneCloud is the call traces. The call traces are comprised of SIP responses and switch logic. Reviewing the switch logic helps to understand how OneCloud processed a call, allowing for diagnosis of why something went wrong with call processing. The switch logic information comes from OneCloud responder-related information. The switch logic contains what can sometimes be an overwhelming amount of data.

What is important is to focus on the aspects that can be controlled – answering rules, dial translations, dial permissions, and call routing. This article describes how to interpret the switch logic as it relates to these four aspects.

Definitions

• Answering Rules – These are call feature rules that are added at the user level
• Dial Translations – These are dial matching rules that match a destination digit sequence, select a responder application to follow and then translates the source and/or destination digit sequence.
• Dial Permissions – These are a set of rules that allow or deny calling to specific destinations.
• Call Routing – These are rules that will send a call using the configured connection(s) based on the source and/or destination of the call.

Accessing Switch Logic

When reviewing a call trace click on the half-looped arrow to display the switch logic information in a frame on the right; as shown below. If you do not see it then scroll down to the bottom of the chart and right-click Frame Mode to open up the viewing frame.

Answering Rules

Answering Rules information will start with the name of the answering rule type (Simultaneous Ring, Forward Always, etc), so they can be more difficult to find in the trace because the types of Answering Rules that have been configured will vary. A sample answering rule from a call trace is below: Simultaneous Ring (from=<sip:14258675309@192.81.237.20>,to=<1000@acmedomain>, datetime=’2018-10-15 21:43:46′, dow=’1′, Time Frame=’n/a’) for <1000@acmedomain> with Own Devices <1000@acmedomain> to <1000 1000a 1000m 1000w 1000wp>

Note: When reviewing the switch logic scroll over past the double colons – you need to see what’s on the right of the double colons, not what’s on the left.

Dial Translations

Dial translations are a key area for call handling, however, given their power and complexity, this is often a source of errors and/or confusion. It is important to remember that dial translations have three components that must be considered:

1. Matching – which rule was matched on and whether it is the intended rule or not

2. Application – which responder application; that is, function/feature will be used to process the call

3. Translation – how is the call translated

A sample dial translation is shown below:

ApplyDialPlan(0,1024) Last Plan <acmedomain>(from=<sip:6100x@acmedomain>, to=<sip:*208675309@acmedomain>, date=’2019-09-05′,dow=’4′,tod=’14:23′) match <sip:[*]20???????@*> select rule(Test) apps<sip:start@to-connection> translate (<sip:*208675309@acmedomain>) to (sip:14258675309@acmedomain) and (“Tommy” <sip:6100x@acmedomain>;tag=BBB) to ( “Columbia” <sip:5554441212@acmedomain>)

The responder application is called by the translation (To Connection).

NOTE: when the App contains nested brackets like apps<<Cloud PBX Features>> this means chain to the Cloud PBX Features table.

By understanding dial translations you may discover issues like a call not matching a translation, matching on a different one than expected, or translations making unexpected changes.

Dial Permissions

Dial Permissions will decide if the user has the right to complete the call. Permissions only look at the destination number given the user’s permissions settings. An example of chained dial permission is shown below.

CheckDialPolicy(0)<International Light> against (sip:14258675309@acmedomain) match <*>(Chain To US and Canada) – chain to <US and Canada>

CheckDialPolicy(1)<US and Canada> against (sip:14258675309@acmedomain) match <*>(Permit All) – (permit)

Second Dial Permission Rule:

Call Routing

Call routing contains two major aspects:

1. Picking a matching routing rule; and

2. Utilizing the connection(s) under that rule to connect to carriers, devices, etc.

Because connections can be either static, registered locally, registered remotely, or pushed (mobile apps) you will see slightly different details depending on each scenario.

LoadRoute (btn=4255551212) – from=<sip:4255551212@acmedomain> to=<sip:14258675309@acmedomain> ToUri=<sip:14258675309@acmedomain> at <core1.netsapiens.com> select <US Domestic Call> (*)(sip:1??????????@*) with 2 fixed connections. LookupRoute to (sip:14258675309@acmedomain) from <sip:4255551212@acmedomain> select (1) Chain(1,2) Route(US Domestic Call) Connection(1):<[*]@sas.netsapiens.com> To <sip:14258675309@sas.netsapiens.com>

LookupRegisteredUA(sip:14258675309@sas.netsapiens.com) – found no match

LookupGateway(sip:14258675309@sas.netsapiens.com) – found <sip:*@sas.netsapiens.com>(demo termination switch) at FQDN <sas.netsapiens.com> translate From-URI from (“Billy” <sip:14255551212@acmedomain>) by ([*]@core1.netsapiens.com) to (“Billy” <sip:14255551212@core1.netsapiens.com>) Connection Lookup: