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 SAS Support Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

SCC

Yes

Terminating only

SIP Access Session Pre-Credit Check

Yes

No

Stateless

POJO

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 on the CS fork before abandoning it.

 
RouteCSDirectlyThroughICSCF

boolean

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

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.

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.

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.

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 3.0.0