Knowledgebase

Route Retry algorithm

Route Retry feature is applied when more than one matching route is returned by the active routing script. Algorithm works in the following way:

• outgoing call will be made based on the first matching route
• if call fails while there are other matching routes left, new outgoing call attempt is made using next matching route 

Call attempt is considered failed in the following conditions:

• Call is terminated by remote side before reaching "Answered" state. Termination cause will determine if route retry is needed or not (enabled or disabled in 'Profiles -> Edit -> Reason Cause Mapping')
• Timeout occurs before call reaches specified call state (this timeout is ignored when last matching route is attempted)

Route retry timeout can be customized using two parameters:

• 'Menu -> Gateway -> Configuration -> Advanced Parameters -> Route retry timeout' - timeout delay in seconds to reach 'minimum call state' (value of 0 makes timeout never occur)
• 'Menu -> Gateway -> Configuration -> Advanced Parameters -> Route retry mode' - minimum call state to reach before the specified timeout occurs:
  • Call accepted
  • Call progress received
  • Call alerted
  • Call answered

If the timeout delay is expired before call reaches the specified state, call is considered failed and retry occurs. If the call reaches the minimal state, timeout isn't taken under consideration anymore, but explicit termination from remote side with error cause may still trigger retry with next route.

The 4 states above correspond to the following protocol-specific events:

SIP:
 Accepted: 100 Trying
 Progress: 183 with SDP (*)
 Alerted:  180 Ringing
 Answered: 200 OK
ISDN:
 Accepted: CALL PROCEEDING
 Progress: PROG
 Alerted:  ALERTING
 Answered: CONNECT
SS7:
 Accepted: <none>
 Progress: CPG
 Alerted:  ACM
 Answered: CONN/ANM
CAS R2:
 Accepted: SeizureAckCasBit
 Progress: <none>
 Alerted:  GroupB SuccessDigit
 Answered: AnswerCasBit

(*) 183 with SDP is usually interpreted as a "ALERT" (not a PROGRESS) unless explicitly configured on NAP level ("NAP -> Edit -> Advanced Parameters ->183 triggers call progress")

Route Retry termination cause configuration

To control if the route retry algorithm should stop or continue to the next route, each termination cause can be configured in the profile and set to either Continue or Stop.

Configuration is delivered via WebPortal in Profile setup 'Menu -> Profiles -> Edit -> Reason Cause Mapping -> Edit Reason Cause Mapping' and applied per NAP or Route basis.

Route Retry global configuration

Route Retry mode and timeout parameters can be configured globally, per NAP, or per Route. Configuration precedence takes following order:

1. Route configuration
2. NAP configuration
3. Global clonfiguration

The global Route Retry mode and timeout parameters can be found in the SmartMedia WebPortal Gateway application configuration menu:

• Go to the 'Menu -> Gateway -> Configuration' menu.
• Expand the 'Advanced Parameters' section
• Modify accordingly the values of 'Route retry mode' and 'Route retry timeout'
• Press Save

Route Retry per-NAP configuration

Per-NAP Route Retry mode and timeout parameters are configured by adding a custom 'NAP column':

• Go to the 'Menu -> Gateway -> Routes -> NAP Columns' menu.
• Click on Create New Nap Column in the 'Editing Naps' section
  • In the Name text box, enter 'route_retry_mode'
  • In the Type attributes text box, enter '|accept|call_progress|alert|answer'
  • Leave the Default text box blank
• Click Save
• Click again on Create New Nap Column in the 'Editing Naps' section
  • In the Name text box, enter 'route_retry_timeout'
  • In the Type attributes text box, enter 'integer'
  • Leave the Default text box blank
• Click Save

After creating above columns, each time you create or edit a NAP in NAP Columns menu, Route Retry mode and timeout paramters will be available. In case those are left blank for a particular NAP, global configuration will take precedence. Assigning a value in either of these parameters will override the global value for that parameter.

Route Retry per-route configuration

Per-route Route Retry mode and timeout parameters are configured by adding a custom 'Route column':

• Go to the 'Menu -> Gateway -> Routes' menu.
• Click on Create New Route Column in the 'Editing Routes' section
  
  • In the Name text box, enter 'route_retry_mode'
  • In the Type attributes text box, enter '|accept|call_progress|alert|answer'
  • Leave the Default text box blank
• Click Save
• Click again on Create New Route Column in the Editing Routes section
  • In the Name text box, enter 'route_retry_timeout'
  • In the Type attributes text box, enter 'integer'
  • Leave the Default text box blank
• Click Save

After creating above columns, each time you create or edit a Route, Route Retry mode and timeout parameters will be shown under Custom Params. In case those are left blank for a particular Route, global configuration will take precedence. Assigning a value in either of these parameters will override the global value for that parameter.

Customize Route retry parameters from routing script

Any part of the routing script that has access to the route object can read or modify below parameters:

• route[:route_retry_mode]
• route[:route_retry_timeout]

Those fields initially contain values of 'Custom Route Columns' (as explained above), but can be overwritten by the routing script.