Understanding Routing

Understanding Routing

When the system needs to route a call it should find set of Connections which can accept it. It does it in three stages:

  1. The system starts process by determining specific Routing Group that the call should be routed to. It does that by finding entity (i.e. Account or Customer) directly associated with the Root Customer which is responsible for the call and retrieving its Routing Group setting.
  2. At the second stage the system finds all Destination Sets in that Routing Group that have at least one Route matching destination number. Route with longest matching prefix is selected from each of those Destination Sets and paired with Connection that has been associated with that Destination Set in the Routing Group. For example when destination number is 1234567890, while there are two Destination Sets having Routes with prefixes 1, 12 and 123, 1234 respectively, the system will select Routes with prefixes 12 and 1234.
  3. The resulting Route / Connection list is ordered based on Routing Policy settings for the particular Routing Group. Available policies are:
  • Least Cost - Routes are ordered based on cost to the particular destination. Ones with lowest cost will be first;
  • Prefix Length - Routes are ordered based on prefix length. Ones that have longest prefix will be first.
  • Route Preference – Routes are ordered based on Preference parameter. Routes with higher Preference will be first.
  • Routing Entries Order - Routes are ordered based on Routing Entries order in particular Routing Group. Routes coming from Destination Sets with lower Order number will be first.

NOTE: unlike with Rates, where only one best matching Rate has to be selected, the system will select several Routes for the same destination number, but pointing to the different Connections and try them one-by-one until the call is either connected or all possible Connections have been tried.

After the list of possible Routes has been built Switch will try to send call to Connections associated with each of those Routes one by one until the call is either successfully connected or there are no more Connections to try.

Consider the following example: you have two terminating providers, A and B. A can terminate prefixes 1234 and 1345, while B prefixes 1345 and 1456, and prices for termination to prefix 1345 provided by B are lower than prices offered by A, but the quality of termination is higher at B. In this case your configuration might look like following:

Then, if the Routing Group policy is set to Least Cost the switch will send call to number 1-345-567-8901 to the Connection “1” first and only if that fails then to the Connection “2”, however, if the Routing Group policy is set to Route Preference, the switch will try Connection “2” first and only then Connection “1”.

There are several other parameters that affect routing associated with each Route:

  • Forbidden – the parameter if set instructs the Switch to not sent any calls with matching prefix to the Connections associated with this Destination Set.
  • Huntstop – the parameter if set instructs the Switch to stop hunting routes when Connection associated with such Route has been reached in the process. The failure code will be returned to the caller if attempt to send the call into such Connection fails.
  • 1xx timeout and 2xx timeout - two timeout parameters, allow limiting amount of time the Switch waits for the call to be answered before sending the call over to the next available Connection. First timeout, called 1xx timeout, limits amount of time the switch waits for any session progress response from the Connection (typically 180 Ringing or 183 Session Progress), it allows for a detection of non-functional or unreachable Connections. The second timeout, 2xx timeout, limits amount of time the switch will be waiting for the call to be answered before trying to send it to the next available Connection. The timeouts work concurrently, so that whichever happens first “wins”.
  • Final 2xx Timeout, sec - this parameter allows setting the 2xx timeout for the last routing entry in the Routing Entries/Follow Me Entry, by default it's set to 300 seconds, meaning that Sippy will be waiting for 200OK message on the INVITE up to this Final 2xx Timeout. The timeout is applied to the last routing entry in the routing group/last Follow Me Entry only. Since 4.5 version of Sippy on Routing Group preferences the new item has been added:
Note: all three timers are fired just after sending the INVITE to the vendor. E.g. with 2xx timeout = 10 seconds, case the vendor/connection is not able to connect the call (send 200OK message to us) within 10 seconds, we're dropping that vendor/connection from the call flow, and either try another vendor, or drop the call. This is applied even if the vendor replied with first 1xx message at 9th second of the call.