Understanding Routing


When the system needs to route a call it has to find a set of Connections which can accept it.  Finding a set of connections to accept the call takes place in three stages:

  1. The system starts the process by determining the specific Routing Group that the call should be routed to; this is achieved by finding an 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 the destination number. The Route with longest matching prefix is selected from each of those Destination Sets and paired with the Connection that has been associated with that Destination Set in the Routing Group. For example when the destination number is 1234567890, and 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 the Routing Policy settings for the particular Routing Group. 

Available policies are:

  • Least Cost - Routes are ordered based on cost to the particular destination. Those with the lowest cost will be first
  • Prefix Length - Routes are ordered based on prefix length. Those that have the longest prefix will be first
  • Route Preference – Routes are ordered based on the Preference parameter. Routes with a higher Preference will be first
  • Routing Entries Order - Routes are ordered based on the Routing Entries order in the each Routing Group. Routes coming from Destination Sets with lower Order number will be first


NOTE: unlike with Rates, where only one best matching Rate can be selected, the system will select several Routes for the same destination number, point 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, the Softswitch will try to send the call to the 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.  Provider A can terminate prefixes 1234 and 1345, while Provider B can terminate prefixes 1345 and 1456.  Prices for termination to prefix 1345 provided by B are lower than prices offered by A, but the quality of termination is higher with provider B. In this case your configuration might look like this::



Then, if the Routing Group policy is set to Least Cost the switch will send call to number 1-345-567-8901 to Connection “1” first and only if that fails then to 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 – this parameter if set, instructs the Softswitch not to send any calls with a matching prefix to the Connections associated with the Destination Set
  • Huntstop – this parameter if set, instructs the Softswitch to stop hunting routes when the Connection associated with the Route has been reached in the process of searching.  A failure code will be returned to the caller if the attempt to send the call into the Connection fails
  • 1xx timeout and 2xx timeout - two timeout parameters, allow limiting the amount of time the Softswitch waits for the call to be answered before sending the call over to the next available Connection.  The first timeout, called 1xx timeout, limits the amount of time the switch waits for any session progress response from the Connection (typically 180 Ringing or 183 Session Progress), it allows for detection of non-functional or unreachable Connections.  The second timeout, 2xx timeout, limits the amount of time the switch will wait 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 and/or Follow Me Entry.  By default, the 2xx timeout is set to 300 seconds, meaning that Sippy will wait for a "200 OK" message on the INVITE up to the Final 2xx Timeout.  The timeout is only applied to the last routing entry in the routing group and/or the last Follow Me Entry.  The Final 2xx timeout parameter was added from Sippy 4.5 on the Routing Group preferences:
Note: all three timers are fired just after sending the INVITE to the vendor.  For example, with 2xx timeout = 10 seconds, if the Vendor/Connection is not able to connect the call (send a "200 OK" message to Sippy) within 10 seconds, the system will drop that Vendor/Connection from the call flow, and either try another Vendor, or drop the call.  This occurs even if the Vendor replied with first 1xx message at the 9th second of the call.