Documentation is applicable for the new Test Dialplan feature that is available starting from 5.0 version of Sippy
Test Dialplan is a feature that allows switch operator to check the configuration of the system and see how the incoming call is expected to be routed within the system, with all charges applied.
Note, this tool allows to check only the routing for the current moment, it can not be used to check the results of the calls from the past, as the changes might have already be done to the configuration.Starting from 5.0 version of Sippy, the Dialplan logic has been completely reworked - it now works based on xmlapiand mimics the call authentication and processing logic of Switch.
Supported call authentication scenarios:
- Authentication rule of Account
- call to DID assigned to Account [Registered Account Incoming Routing]
- call to DID assigned to Account [Trunk Incoming Routing]
- call to DID assigned to Account [Disabled Onnet, Routing Group case]
- call to DID assigned to IVR application
- Digest Authentication of account [Authenticated Call mode]
- Outgoing call from IVR application [Authenticated Call mode]
DID Authentication rules are respected and processed properly.
Switch operator is able to enter the incoming CLD, Remote Address (optionally with port), incoming CLI and protocol (default SIP should be fine in 99% of cases) and see how the call would be authenticated within Sippy, which account/DID would be authorized for that call, what would be the surcharges, etc.Test diaplan Result parameters description:
- Routing Group - Routing Group used in this particular scenario. Clickable link leads to the routing group settings.
- Tariff - Tariff used in this particular scenario. Clickable link leads to the tariff settings.
- Prefix - tariff's rate prefix used in this particular scenario. Clickable link leads to the rate's settings.
- Price - corresponding prices from tariff's rate prefix used in this particular scenario.
Routing Entries would be ordered based on the Routing Policy from the Routing Group that was used in this particular scenario.
The order in most cases would be the same as the order for the new calls sent within that scenario, the exception is Weighted Distribution Routing Policy, where the calls would be distributed randomly based on the weight.
Line with #0 has the CLI/CLD with translation rules applied from authentication rule (if used) and account:
Incoming CLI/CLD translation rules for account account_name applied
CLI/CLD for the lines with number >0 have the translated CLI/CLD based on connection's translation rule. Those CLDs are final ones, and are only sent to vendor, they are not used for call processing.
In Media Relay column the used RTPproxy would be displayed, default values - null, or Built-In RTPproxy, in case of the SMG configured, it would be displayed there as well.
Timeouts section keeps the current values of system timeouts:
100 timeout is taken from Reply Timeout, sec from connection
1xx timeout is taken from 1xx Timeout, sec from Destination Set's route prefix
2xx timeout is taken from 2xx Timeout, sec from Destination Set's route prefix, unless the routing entry is the last in the list, then the Final 2xx timeout, sec from Routing Group is showed.
For the onnet/trunk cases the onnet timeouts from Routing Group are to be displayed instead.
In Current Channels/Max column the number of used capacity slots are displayed, in case the Capacity and Enforce Capacity are set on corresponding Connection. The information is displayed in real time, allowing switch operator to see how many calls are hitting each connection at the moment of dialplan lookup.
Est. Cost is estimated cost for the call, based on Average call duration (ACD) configured in the Tariff selected for this call, based on the authentication/authorization. This means the surcharges from Destination Set and Destination Set's route are calculated for the ACD and showed for switch operator as Est. Cost.