SCCTADSParallelRouting

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.

Provisional responses are always forwarded upstream.

In addition, the feature will add an OC-Terminating-Domain header to the forwarded 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.

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".

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.

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

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.

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.