Route retry

Route retry algorithm

The route retry feature applies when more than one matching route is returned by the active routing script. The route retry algorithm works the following way:

• An outgoing call will be made based on the first matching route
• If that outgoing call fails while there are other matching routes left, another outgoing call attempt is made using next matching route (enabled or disabled per termination cause)

A call attempt is considered failed in the following conditions:

• Call is terminated by remote side before it's answered. Termination cause will determine if route retry is needed or not.
• 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 three parameters:

• Timeout delay in seconds to reach 'minimum call state' (value of 0 makes timeout never occur)
• 'Minimum call state' (also called "Route Retry Mode") to reach before the specified timeout occurs:
  • Call accepted
  • Call progress received
  • Call alerted
  • Call answered
• Relay progress messages option. Forward alert and progress messages from the current route.

If the timeout delay is passed before the call reaches the specified state, call is considered failed and retry occurs. If the call reaches that state, timeout no longer apply, 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 a quirk is enabled. The quirk is located in the configuration tabs "NAP -> Advanced" and is called "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.

Click here to see the profile "Reason Cause Mapping" table

Route retry global configuration

These route retry timeout parameters can be configured globally, per NAP, or per Route. Per-route value has precedence on per-NAP value, which has precedence on global value.

The global route retry timeout parameters are found in the Gateway application configuration page in the Toolpack Web Portal:

• Go to the Gateway->Configuration menu.
• Click on the Edit link of the configuration you wish modify.
• Expand the Advanced section
• Change values of 'Route retry mode', 'Route retry timeout' and 'Route retry relay progress messages'

Route retry per-NAP configuration

The per-NAP route retry timeout parameters are configured by adding a custom 'NAP column':

• Go to the Gateway->Configuration menu.
• Click on the Edit link of the configuration you wish modify.
• 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
• Click again on Create New Nap Column in the Editing Naps section
  • In the Name text box, enter 'route_retry_relay_progress'
  • In the Type attributes text box, enter 'boolean'
  • Leave the Default text box blank
• Click Save

Now that these columns have been created, each time you create or edit a NAP, route retry mode and timeout will be shown under Custom Params. Leaving empty value for a NAP will make global value to be used. Assigning a value in either of these parameters will override the global value for that parameter.

Route retry per-route configuration

The per-route route retry timeout parameters are configured by adding a custom 'Route column':

• Go to the Gateway->Configuration menu.
• Click on the Edit link of the configuration you wish modify.
• 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
• Click again on Create New Route Column in the Editing Routes section
  • In the Name text box, enter 'route_retry_relay_progress'
  • In the Type attributes text box, enter 'boolean'
  • Leave the Default text box blank
• Click Save

Now that these columns have been created, each time you create or edit a route, route retry mode and timeout will be shown under Custom Params. Leaving empty value for a route will make NAP value used (or global value if NAP value is also empty). Assigning a value in either of these parameters will override the NAP or global value for that parameter.

Customize route retry parameters from routing script

Any part of the routing script that has access to the route can modify these parameters by reading and writing from/to:

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

These fields initially contain value read from the added 'Custom Route Columns' (as explained above), but can be overwritten by the routing script.

Useful links

• Tmedia Routing