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>
We will explain this information:
| Content | Explanation |
|---|---|
| Simultaneous Ring | This is the type of answering rule being processed |
| from= | The Address of Record (AOR) of the caller |
| to=<1000@acmedomain> | The callee user |
| datetime='2018-10-15 21:43:46', dow='1' | The date, time, and day of the week of this call |
| Time Frame='n/a' | There was a matching time frame, in this case n/a will be the Default time frame. In other cases a * will also be the Default time frame or the actual name of the time frame will be displayed |
| for <1000@acmedomain> | The user which owns the call/time frame |
| with Own Devices <1000@acmedomain> | These are the settings for the simultaneous ring destination; in this case it rings devices owned by user 1000@domain (Own Devices) |
| to <1000 1000a 1000m 1000w 1000wp> | This is the list of all devices owned by user 1000@acmedomain |
By understanding the answering rules used you may understand what happened in a specific time of day incident (for example, I expected holiday mode to occur); or at least be informed what happens later in the call processing.
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
| Content | Explanation |
|---|---|
| ApplyDialPlan(0,1024) Last Plan | This means the call is being processed in the acmedomain table. Note the 0 to the right of the ApplyDialPlan means this is the first table (zero index) which is processing the call. If this call chains to another table the next one will be ApplyDialPlan(1,... |
| (from | The Address of Record (AOR) of the caller |
| to= | The Address of Record (AOR) of the callee |
| date='2019-09-05',dow='4',tod='14:23' | The date, day of the week, and time of this call (UTC) |
match | The matched destination translation information and the description/name of the dial rule (Test) |
|
| apps | The application called by the translation (To Connection). Note when the App contains nested brackets like this < |
| translate | This is the beginning of the translation section |
| ( | The destination (to) translation before and after |
| and ("Tommy" | The source (from) translation before and after |
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)
First Dial Permission Rule:
| Content | Explanation |
|---|---|
| CheckDialPolicy(0) | This means the permissions policy is International Light. The 0 next to CheckDialPolicy means this is the first table processing the permissions. |
| against (sip:14258675309@acmedomain) | The destination AOR being assessed for permissions |
| match <*>(Chain To US and Canada) | * is the matching rule which is labelled "Chain to US and Canada" |
| chain to | The action of the rule - chain to US and Canada table |
Second Dial Permission Rule:
| Content | Explanation |
|---|---|
| CheckDialPolicy(1) | This means the permissions policy is US and Canada. The 1 next to CheckDialPolicy means this is the second table processing the permissions. |
| against (sip:14258675309@acmedomain) | The destination AOR being assessed for permissions |
| match <*>(Permit All Others) | * is the matching rule which is labelled "Permit All Others" |
| (permit) | The action of the rule - permit the call |
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:
