Route retry - Revision history

Luc Morissette: Removed requirement for enabling routing scripts - they are always enabled now.

2019-08-21T15:46:38Z

Removed requirement for enabling routing scripts - they are always enabled now.

← Older revision		Revision as of 11:46, 21 August 2019
Line 1:		Line 1:
	~~== Requirements ==~~
	~~'''WARNING:''' The route retry feature requires to use Routing scripts.~~

	~~[[Scriptable_Routing_Engine\|Click here]] to learn how to enable routing scripts.~~

	== Route retry algorithm ==		== Route retry algorithm ==

Rblanchet: Add route_retry_relay_progress option

2015-08-21T20:10:27Z

Add route_retry_relay_progress option

← Older revision		Revision as of 16:10, 21 August 2015
Line 17:		Line 17:
	*Timeout occurs before call reaches specified call state (this timeout is ignored when last matching route is attempted)		*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:		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)		*Timeout delay in seconds to reach 'minimum call state' (value of 0 makes timeout never occur)
Line 25:		Line 25:
	**Call alerted		**Call alerted
	**Call answered		**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.		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.
Line 66:		Line 67:
	*Click on the Edit link of the configuration you wish modify.		*Click on the Edit link of the configuration you wish modify.
	*Expand the Advanced section		*Expand the Advanced section
	*Change values of 'Route retry mode' and 'Route retry ~~timeout~~'		*Change values of 'Route retry mode', 'Route retry timeout' and 'Route retry relay progress messages'


Line 84:		Line 85:
	**In the Name text box, enter 'route_retry_timeout'		**In the Name text box, enter 'route_retry_timeout'
	**In the Type attributes text box, enter 'integer'		**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		**Leave the Default text box blank
	*Click Save		*Click Save
Line 106:		Line 112:
	**In the Type attributes text box, enter 'integer'		**In the Type attributes text box, enter 'integer'
	**Leave the Default text box blank		**Leave the Default text box blank
	*Click Save		*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.		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.
Line 117:		Line 128:
	*route[:route_retry_mode]		*route[:route_retry_mode]
	*route[:route_retry_timeout]		*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.		These fields initially contain value read from the added 'Custom Route Columns' (as explained above), but can be overwritten by the routing script.

Luc Morissette: /* Useful links */

2014-01-31T14:27:26Z

Useful links

← Older revision		Revision as of 10:27, 31 January 2014
Line 121:		Line 121:

	== Useful links ==		== Useful links ==
	[[Tmedia_Routing\|Tmedia Routing]]		*[[Tmedia_Routing\|Tmedia Routing]]

Luc Morissette: Added link to Tmedia routing

2014-01-31T14:25:15Z

Added link to Tmedia routing

← Older revision		Revision as of 10:25, 31 January 2014
Line 119:		Line 119:

	These fields initially contain value read from the added 'Custom Route Columns' (as explained above), but can be overwritten by the routing script.		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\|Tmedia Routing]]

Lucas Trottier: /* Route retry termination cause configuration */

2014-01-22T06:04:09Z

Route retry termination cause configuration

← Older revision		Revision as of 02:04, 22 January 2014
Line 53:		Line 53:

	== Route retry termination cause configuration ==		== 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~~, as show on the~~ [[Termination_cause_codes\|~~termination cause~~]] ~~page.~~		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.

			[[Termination_cause_codes\|Click here]] to see the profile "Reason Cause Mapping" table

	== Route retry global configuration ==		== Route retry global configuration ==

Lucas Trottier: Add link to termination cause page

2014-01-22T06:02:14Z

Add link to termination cause page

← Older revision		Revision as of 02:02, 22 January 2014
Line 51:		Line 51:

	''(*) 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"''		''(*) 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, as show on the [[Termination_cause_codes\|termination cause]] page.

	== Route retry global configuration ==		== Route retry global configuration ==

Lucas Trottier: Add link to termination cause page

2014-01-22T05:46:47Z

Add link to termination cause page

← Older revision		Revision as of 01:46, 22 January 2014
Line 10:		Line 10:

	*An outgoing call will be made based on the first matching route		*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)		*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_codes\|termination cause]])

	A call attempt is considered failed in the following conditions:		A call attempt is considered failed in the following conditions:

Abrassard: Added warning that routing script is required for route retry

2012-10-29T19:33:22Z

Added warning that routing script is required for route retry

← Older revision		Revision as of 15:33, 29 October 2012
Line 1:		Line 1:
			== Requirements ==
			'''WARNING:''' The route retry feature requires to use Routing scripts.

			[[Scriptable_Routing_Engine\|Click here]] to learn how to enable routing scripts.

	== Route retry algorithm ==		== Route retry algorithm ==

Abrassard at 15:51, 1 June 2012

2012-06-01T15:51:44Z

← Older revision		Revision as of 11:51, 1 June 2012
Line 5:		Line 5:

	*An outgoing call will be made based on the first matching route		*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		*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:		A call attempt is considered failed in the following conditions:

	*Call is terminated ~~with an error cause~~ before it's answered		*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)		*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:		Route retry timeout can be customized using two parameters:

	*Timeout delay in seconds ~~before retry with next route~~ (value of 0 makes timeout never occur)		*Timeout delay in seconds to reach 'minimum call state' (value of 0 makes timeout never occur)
	*Minimum call state to reach before the specified timeout occurs:		*'Minimum call state' (also called "Route Retry Mode") to reach before the specified timeout occurs:
	**Call accepted		**Call accepted
	**Call progress received		**Call progress received
Line 21:		Line 21:
	**Call answered		**Call answered

	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.		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:		The 4 states above correspond to the following protocol-specific events:

Lucas Trottier: Uniformize CAS R2 naming

2011-12-13T15:48:31Z

Uniformize CAS R2 naming

← Older revision		Revision as of 11:48, 13 December 2011
Line 39:		Line 39:
	Alerted: ACM		Alerted: ACM
	Answered: CONN/ANM		Answered: CONN/ANM
	~~CASR2~~:		CAS R2:
	Accepted: SeizureAckCasBit		Accepted: SeizureAckCasBit
	Progress: <none>		Progress: <none>