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 | Originating / Terminating | Point(s) in Session Plan | Network Operator Data | Subscriber Data | Stateful or Stateless | POJO Feature or SBB Feature | Other notes |
|---|---|---|---|---|---|---|---|
SCC |
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 |
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. |
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. |
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 |
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 for forward a provisional or success response from the CS 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 the PS forked leg. |
RouteToCSFailed |
Incremented when the CS leg is torn down without being answered. |
RouteToPSFailed |
Incremented when the 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 the PS leg. |
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.
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 both INVITEs are sent, 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 either 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.
|
T-ADS parallel routing is not compatible with +sip.instance routing. If +sip.instance routing is enabled, a sequential T-ADS routing strategy must be used. |
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 leg.
If the 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 the other forked leg has been aborted or was 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 leg is terminated as per SIP procedures.
The OC-Terminating-Domain header will be included on the response.
In the event that both the CS and PS 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.
