T-ADS Parallel Routing executes after the T-ADS data lookup feature if the session field RoutingMode is set to PARALLEL.

The T-ADS Parallel Routing feature parallel-forks the incoming message to both CS and PS legs, and forwards the response from the leg that successfully responds first

Feature Cheat Sheet

B2BUA Instance

SCC

SAS Support

Yes

Originating / Terminating

Terminating only

Point(s) in Session Plan

  • SipAccess_SubscriberCheck

  • SipAccess_PartyRequest

  • SipAccess_PartyResponse

Network Operator Data

Yes

Subscriber Data

No

Stateful or Stateless

Stateless

POJO Feature or SBB Feature

POJO

Other notes

The feature itself is stateless, but an FSM is encoded into session state

Prerequisite Features

Session Input Variables

Session State variable name Type Comments 
CallType

CallType (Enum)

The call-type for the incoming call (e.g. MobileTerminating).

 
SentinelSelectionKey

SentinelSelectionKey

Used to acquire configuration information.

 
TADSCircuitRoutes

Queue<String>

Used to retrieve a CSRN for CS routing.

 
TADSPacketRoutes

Queue<RouteAndTerminatingDomain>

Used to determine if PS routing is possible, and to obtain the routes and terminating domains if +sip.instance routing is enabled.

 
TADSSipInstanceRoutingPossible

boolean

Indicates whether T-ADS +sip.instance routing is possible for the served user.

 
FeatureCapsManager

FeatureCapsManager

Management interface for controlling Feature-Caps header values on outgoing messages.

Session Output Variables

Session State variable name Type Comments 
TerminatingDomain

String

Records the current value being used for the OC-Terminating-Domain Header

 
FeatureCapsManager

FeatureCapsManager

Management interface for controlling Feature-Caps header values on outgoing messages.

 
StripPreconditionsLegNames

<Set>String

The T-ADS Parallel Routing feature adds each parallel legname to the Set which is used by the StripPreconditions feature to remove preconditions (if StripPreconditions EnabledFlag is selected).

Network Operator Data

T-ADS Routing has network operator data in a J-SLEE profile table named SccTADSParallelRoutingConfigProfileTable. The data is scoped by Sentinel selection key.

Attributes Type Meaning 
ParallelTimerMaxWait

int

The time in milliseconds that the feature will wait for a final response from the CS domain before abandoning it. Only applies when simultaneously routing to both PS and CS domains.

 
RouteCSDirectlyThroughICSCF

boolean

When true, T-ADS will route requests to the CS domain directly via the I-CSCF (bypassing the S-CSCF)

 
AttemptCSRoutesAfterPSRoutes

boolean

When true, T-ADS won’t attempt routes to the CS domain until after routing attempts to the PS domain have failed. Not required when using per-device routing.

 
CSFallbackTimer

int

The time in milliseconds that the feature will wait for a provisional response from the PS domain before abandoning it and routing to CS. Only applies when there are CS routes available and AttemptCSRoutesAfterPSRoutes is set to true.

 
KeepPSLegsOnCSFallback

boolean

When true, if true T-ADS will keep remaining PS legs active when the CS fallback timer expires.

 
PerDeviceRoutingMode

Enum

Controls routing behaviour when companion devices are present, see below. Valid values are IMEI, IMPI, and OFF.

 
CallEndingStatuses

int[]

A list of SIP status codes that will cause T-ADS to terminate all remaining legs when received from any leg. Only applies when companion devices are present.

 
DeviceEndingStatuses

int[]

A list of SIP status codes that will cause T-ADS to terminate all remaining legs associated with the device that sent the error. Only applies when companion devices are present.

 
OnlyDelayCSRoutesWhenMultiplePSRoutesAvailable

boolean

Deprecated use per-device routing instead. When true, T-ADS will only delay routing to the CS domain when there are multiple PS routes available.

 
ReleaseAllLegsOnBusy

boolean

Deprecated include 486 in CallEndingStatuses instead. When true, T-ADS will terminate all forked legs when the first 486 (Busy Here) response arrives from any leg. Only applies when companion devices are present.

T-ADS Parallel Routing also draws additional network operator data from SIP service configuration in a J-SLEE profile table named SipSentinelConfigurationTable. The data is scoped by Sentinel selection key.

Attributes Type Meaning 
IcscfUri

String

The sip: URI for the I-CSCF

Statistics

SCCTADSParallelRouting statistics are tracked by the volte.sentinel.sip SBB and can be found under the following parameter set:
SLEE-Usage → volte.sentinel.sip service ID → volte.sentinel.sip SBB ID → feature.SCCTADSParallelRouting

Name Description 
Started

Incremented when the feature is triggered.

 
FailedToStart

Incremented when the feature fails to start.

 
FailedDuringExecution

Incremented when the feature fails while executing.

 
IssuedWarning

Incremented when the feature issues a warning.

 
TimedOut

Incremented when the feature times out during execution.

 
TriggeredOnRequest

Incremented when the feature is triggered on a SIP Request.

 
TriggeredOnResponse

Incremented when the feature is triggered on a SIP Response.

 
TriggeredOnTimer

Incremented when the feature is triggered on the timer firing.

 
CSRNNotFound

Incremented when the CS fork cannot be established because no CSRN can be found.

 
MaxWaitTimerSet

Incremented when the Max Wait Timer is started.

 
MaxWaitTimerCancelled

Incremented when the Max Wait Timer is cancelled.

 
UpstreamForkCreated

Incremented when an upstream forked leg is created to forward a provisional or success response from the CS leg or any secondary PS leg.

 
ReceivedProvisionalResponse

Incremented when a provisional 18x response is received.

 
ReceivedFinalResponse

Incremented when a final response is received for the initial INVITE.

 
RouteToCSAttempted

Incremented when an INVITE is routed down the CS forked leg.

 
RouteToPSAttempted

Incremented when an INVITE is routed down a PS forked leg.

 
RouteToCSFailed

Incremented when the CS leg is torn down without being answered.

 
RouteToPSFailed

Incremented when a PS leg is torn down without being answered.

 
AnsweredOnCS

Incremented when a success response is received on the CS leg.

 
AnsweredOnPS

Incremented when a success response is received on a PS leg.

 
TADSTerminatingDomainsNotSet

Incremented when the feature cannot retrieve the terminating domains for the active routes from session state.

 
NoForkAdded

Incremented when the feature adds the Request-Disposition: no-fork directive to an outgoing INVITE.

 
NoForkRemoved

Incremented when the feature removes the Request-Disposition: no-fork directive from an outgoing INVITE.

Behaviour

The following behaviour is described below:

Initial Forking

This feature will initiate an INVITE towards the PS domain if the session state field IsPSRouting is TRUE. It will also initiate an INVITE towards the CS domain if the session state field CSRN is populated.

If both of these conditions are true, then the two INVITEs form a parallel fork. If +sip.instance routing is enabled, the feature will initiate invites to all registered PS routes, and hence the parallel fork can consist of more than two INVITEs.

The outgoing INVITE for the CS leg is generated from the original incoming INVITE received from the calling party. The Request-URI and To headers are changed to a Tel URI generated from the CSRN. If configured in network operator data, the Route header will be modified to route the request directly to the I-CSCF.

When the PS and CS legs are created the Request-Disposition header is set to no-fork to ensure that the downstream SCSCF doesn’t perform a downstream fork.

If INVITEs are sent to both the PS and CS domains, the feature starts a timer. This timer will be set to expire after a length of time determined by the ParallelTimerMaxWait setting in the feature configuration profile. If this timer expires before a final response is received from any leg, the CS fork will be canceled.

In the event that both the PS and CS legs cannot be created, then the feature instructs Sentinel VoLTE to end the INVITE session by responding to the calling party with a final SIP error response with status code 480 (Temporarily Unavailable).

If only one of the legs is attempted then the TADS Parallel Routing feature did not create a parallel fork. In this case T-ADS acts as a routing B2BUA adding the OC-Terminating-Domain header as per the OC-Terminating-Domain header addition section.

Delayed CS Routing

If AttemptCSRoutesAfterPSRoutes is set to true in the network operator data, then the feature will not attempt to route to the CS domain until after either all routing attempts to the PS domain have failed, or no provisional responses are received from any PS routing attempt within the time period specified in the CSFallbackTimer field. If that time period is exceeded, the feature will terminate all PS legs and route to the CS domain.

This behaviour can be modified with the KeepPSLegsOnCSFallback option which has two effects when enabled:

  1. It will prevent the feature from terminating the PS legs when the CS fallback timer expires.

  2. It will no longer prevent CS fallback from happening if a provisional response is received from a PS leg.

The OnlyDelayedCSRoutingWhenMultiplePSRoutesAvailable option can be used to make delayed CS routing conditional on there being multiple PS routes available. When enabled, if there is only a single PS route available the feature will attempt to route to the CS simultaneously with the PS routing attempt.

Delayed CS Routing is most useful in cases where there are multiple PS routes and/or multiple CS routes that can be attempted simultaneously, but PS routing is preferred over CS routing. When only a single route to PS and a single route to CS is expected to be available, it is preferable to use sequential T-ADS routing instead of parallel routing with this setting.

Per-Device Routing

Per-device routing can be used when the called party is using a companion device. It allows T-ADS to handle CS fallback to each device independently.

It does this by correlating each available PS and CS route to one of the called party’s devices.

  • PS routes are correlated to companion devices by either the IMS Private Identity (IMPI) or the International Mobile Equipment Identity (IMEI).

  • CS routes are correlated to companion devices by MSISDN.

  • All routes that cannot be correlated to a companion device are considered as "primary device" routes.

When per-device routing is enabled, for each device:

  1. The feature will first attempt to route to the device over PS.

  2. It will then attempt to route to the device over CS if there is a CS route available and:

    1. there are no PS routes available for the device, or

    2. all PS routes for the device respond with SIP error statuses, or

    3. no PS routes for the device respond with a 18x or 2xx status within the time period specified in the CSFallbackTimer field.

Use of per-device routing is controlled with the PerDeviceRoutingMode field on the SCCTADSParallelRoutingConfigProfileTable.

  • When set to IMPI or IMEI, companion device PS routes will be correlated against the respective identity.

  • When set to AUTO, the feature will use which ever of the IMPI or IMEI is available, with the IMEI being preferred.

  • When set to OFF per-device routing will not be used.

Note that regardless of whether IMPI, IMEI or AUTO is used, the feature will always use the MSISDN of the companion device to correlate CS routes.

The IMEI associated with a given PS route is determined from +sip.instance parameter of the Contact header the route was derived from. This is only done when the +sip.instance contains a valid IMEI in the format urn:gsma:imei:XXXXXXXX-XXXXXX-X. The IMPI for a route is determined from the third party registration data associated with that route.

These values are correlated against IMEI and IMPI associated with a companion device, determined from the information provisioned in the called party’s Metaswitch-TAS-Services document in the HSS. Note that when comparing the IMEI for a route to companion device data only the first 14 digits are considered, so the 15th check digit may be left as 0 in the provisioned data.

CS routes are inherently associated with their companion device by the MSISDN of the device, as that MSISDN (as provisioned in the Metaswitch-TAS-Services document) is used to determine the CS route in the first place.

Note that regardless of configuration, per-device routing will never be used in calls where there is no companion device present. Also, when per-device routing is active for a call, delayed CS routing is automatically enabled regardless of the setting in the AttemptCSRoutesAfterPSRoutes config field.

See also Example of call using per-device routing.

On Receiving a Provisional Response

Provisional responses are always forwarded upstream.

In addition, the feature will add an OC-Terminating-Domain header to the forwarded response.

On Receiving a Final Error Response

When a final error response is received on one of the forked legs the exact behavior of the feature depends on the state of the other forked legs.

If some other forked leg is still active, then the leg the final error was received on will be released. In this case the feature will prevent the error response from being forwarded to the calling party.

If all other forked legs have been aborted or were never created, then the error response will be forwarded upstream, effectively ending the call.

If the error is forwarded upstream, the OC-Terminating-Domain header will be added to the response.

Configurable Error Handling with Companion Devices

When the called party is using a companion device the behavior of the feature when a final error response is received can be modified using the CallEndingStatuses and DeviceEndingStatuses config fields:

  • If the status code of the final error response is present in the CallEndingStatuses list, then all remaining legs will be terminated, and the call will be terminated.

  • If the status code of the final error response is present in the DeviceEndingStatuses list, then all remaining legs associated with the same device as the leg that sent the final error response will be terminated. If there are no other devices remaining, the call will be terminated.

On Receiving a Final Success Response

In the case of a parallel fork, the first 2xx success response processed by this feature will be forwarded and the call will be established over that Dialog. The remaining forked legs are terminated as per SIP procedures.

The OC-Terminating-Domain header will be included on the response.

In the event that multiple legs answer at the same time, they are processed in an order. The first response to be processed by the feature "wins".

On Receiving a CANCEL Request

If the calling party sends a CANCEL for the original INVITE, the TADS Parallel Routing feature will immediately terminate all remaining legs according to standard SIP protocol.

OC-Terminating-Domain Header addition

The OC-Terminating-Domain header is added to responses heading upstream (usually for charging purposes). The feature adds this header to all responses for the original INVITE that are forwarded upstream.

For more details see OC-Terminating-Domain Header

Illustrative scenarios

To better illustrate the feature, consider the following scenarios.

Scenario 1

In this scenario the feature creates a parallel fork to the PS and CS domains, and arms an internal timer. Prior to timer expiry, an error response is received from the PS domain. The feature discards the PS leg. Session establishment continues on the CS domain.

tadspr example1

Scenario 2

In this scenario the feature creates a parallel fork to the PS and CS domains, and arms an internal timer. In this case both domains send provisional responses. The PS domain answers first, and as a consequence the CS domain is terminated.

tadspr example2

Previous page Next page
Sentinel VoLTE Version 4.1