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

SipAccess_SubscriberCheck, SipAccess_PartyResponse, SipAccess_ServiceTimer

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

 
RoutingMode

TADSRoutingMode (Enum)

Determines whether CS and/or PS routing is enabled and the preferred attempt order.

 
SentinelSelectionKey

SentinelSelectionKey

Used to acquire configuration information.

 
TADSCircuitRoutes

Queue<String>

Contains all valid CS domain routes (CSRNs).

 
TADSPacketRoutes

Queue<RouteAndTerminatingDomain>

Contains all valid PS domain routes along with the network type for each route.

 
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.

 
RegistrationRecords

List<RegistrationRecord>

List of registered devices for the served user, determines the maximum number of downstream forks to wait for when routing on the preferred domain.

 
TADSFallbackLegType

LegType (Enum)

The fall back leg type (e.g. None, CS, or PS).

 
TADSPreferredLegType

LegType (Enum)

The preferred leg type.

 
TADSCircuitRoutesPending

boolean

Used to indicate if any CS leg attempts are outstanding.

 
TADSCurrentLegName

String

Current leg name being contacted.

 
SendNextRequest

boolean

Used to indicate if the feature should send the SIP request.

 
TADSequentialInviteSeqNum

Long

Used to check if the SIP response is for the current access leg INVITE.

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.

 
PSTerminatingDomainHeaderValue

String

Value set in the OC-Terminating-Domain header

 
TADSTimerID

TimerID

Current leg max wait timer

 
FetchedMSRN

boolean

Flag to reactivate execution of FetchMSRN feature

Network Operator Data

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

Attributes Type Meaning 
TimerTADS

int

The time in milliseconds that the feature will wait for an acceptable response when routing to the preferred leg. This value is required to be between 500 and 5000 ms.

 
PSToCSFallbackResponseCodes

int[]

The list of SIP error response codes (INVITE) that will trigger CS fallback if received on a PS routing attempt.

 
RouteCSDirectlyThroughICSCF

boolean

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

 
SuppressCSDomainCallDiversion

boolean

When true, requests destined to the CS domain will contain a Diversion header to suppress call diversion in the CS domain side of the call.

 
DiversionLimitCSDomain

int

The configured diversion limit in the CS network to suppress further call diversion.

 
UseDiversionCounterParameter

boolean

When true, the added Diversion header’s counter parameter is used; otherwise, instances of the Diversion header added to the request are used to indicate the diversion count.

 
Send491ToOutstandingUpdate

boolean

When true, and TADS fallback routes are available, outstanding UPDATE transactions will receive a 491 response instead of a 488 response.

T-ADS Routing also draws additional network operator data from SIP service configuration in a 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

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

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.

 
RouteToPreferredPS

Incremented when the feature successfully routes to the first packet route when PS is preferred mode.

 
RouteToPreferredCS

Incremented when the feature successfully routes to the first CSRN when CS is preferred mode.

 
RouteToFallbackPS

Incremented when the feature successfully routes to the first packet route when PS is the fallback mode.

 
RouteToFallbackCS

Incremented when the feature successfully routes to the first CSRN when CS is the fallback mode.

 
RouteToSecondaryPS

Incremented when the feature successfully routes to a subsequent packet route when PS is the preferred or fallback mode.

 
RouteToSecondaryCS

Incremented when the feature successfully routes to a subsequent CSRN when CS is the preferred or fallback mode.

 
ErrorResponseMatched

Incremented when an error response received from a routing attempt triggers a new routing attempt.

 
Error18xMatched

Incremented when the PS call 18x response matches the SDP requirements outlined in 18x Response.

 
Received18xResponse

Incremented when the feature receives a 18x response to the initial INVITE request

 
Received488Response

Incremented when the feature receives a 488 message from the PS call.

 
ReceivedPSToCSFallbackResponseCode

Incremented when the feature receives a error message from the PS call that is contained in PSToCSFallbackResponseCodes.

 
TerminatingDomainHeaderSet

Incremented when the feature adds a terminating domain header to an upstream response

 
TADSTimerFired

Incremented when the Max Wait Timer for a response on a routing attempt is exceeded

 
RouteToPreferredPSAnswered

Incremented when the first packet route is answered and PS is the referred mode.

 
RouteToFallbackPSAnswered

Incremented when the first packet route is answered and PS is the fallback mode.

 
RouteToSecondaryPSAnswered

Incremented when a subsequent packet route answered and PS is the preferred or fallback mode.

 
RouteToPreferredCSAnswered

Incremented when the first CSRN is answered and CS is the referred mode.

 
RouteToFallbackCSAnswered

Incremented when the first CSRN is answered and CS is the fallback mode.

 
RouteToSecondaryCSAnswered

Incremented when a subsequent CSRN is answered and CS is the referred or fallback mode.

 
RouteToPreferredPSFailed

Incremented when the first packet route returns a failed SIP response e.g. >299 and PS is the referred mode.

 
RouteToPreferredCSFailed

Incremented when the first CSRN returns a failed SIP response e.g. >299 and CS is the referred mode.

 
RouteToFallbackPSFailed

Incremented when the first packet route returns a failed SIP response e.g. >299 and PS is the fallback mode.

 
RouteToFallbackCSFailed

Incremented when the first CSRN returns a failed SIP response e.g. >299 and CS is the fallback mode.

 
RouteToSubsequentPSFailed

Incremented when a subsequent packet route returns a failed SIP response e.g. >299 and PS is the preferred or fallback mode.

 
RouteToSubsequentCSFailed

Incremented when a subsequent CSRN returns a failed SIP response e.g. >299 and CS is the preferred or fallback mode.

 
SelectedPreferredPS

Incremented when the first packet route is selected and PS is the preferred mode.

 
SelectedPreferredCS

Incremented when the first CSRN is selected and CS is the preferred mode.

 
SelectedFallbackPS

Incremented when the first packet route is selected and PS is the fallback mode.

 
SelectedFallbackCS

Incremented when the first CSRN is selected and CS is the fallback mode.

 
SelectedSecondaryPS

Incremented when a subsequent packet route is selected and PS is the preferred or fallback mode.

 
SelectedSecondaryCS

Incremented when a subsequent CSRN is selected and CS is the preferred or fallback mode.

 
AttemptSuppressCSDomainCallDiversion

Incremented when a diversion header is added to an outgoing request to the CS domain to suppress CS network call diversion.

Behaviour

The following behaviour is described below:

Sequential routing strategies

The default routing strategy in VoLTE is to try to route to PS domain first and fallback to CS domain. This behaviour can be changed by the value of the parameter oc-tads-routing in the Route Header Parameters.

Based on the value of the RoutingMode session state field (calculated from the content of oc-tads-routing parameter), one of the following sequential routing modes is selected:

PS Domain only

RoutingMode = PS-ONLY

The feature tries to route towards the PS domain with no fall back to the CS domain. 100-TRYING responses and QoS negotiation are not shown in the flow. psdomain

CS Domain only

RoutingMode = CS-ONLY

The feature tries to route towards the CS domain with no fall back to PS domain. 100-TRYING responses and QoS negotiation are not shown in the flow. csdomain

PS network first with fallback to CS network

RoutingMode = PS-CS

The feature tries the PS domain first and drops to CS if the PS conditions don’t match. This allows the setting of Package Switch network as a preferred domain but also allows the usage of a Circuit Switch network if the user is available. This is the default mode. 100-TRYING responses and QoS negotiation are not shown in the flow. pscsdomain

CS network first with fallback to PS network

RoutingMode = CS-PS

The feature tries the CS domain first and drops to PS if the CS conditions don’t match. This allows the setting of Circuit Switch network as a preferred domain but also allows the usage of a Package Switch network if the user is logged in. 100-TRYING responses and QoS negotiation are not shown in the flow. cspsdomain

Selected Domain is CS

If T-ADS chooses to deliver on the CS domain, the T-ADS Routing feature will iterate through the CSRNs queued in the TADSCircuitRoutes session state field.

Going one at a time, for each CSRN the feature will:

  • Create an INVITE to the called party using the CSRN as the Request-URI and also as the To header.

  • If RouteCSDirectlyThroughICSCF is enabled in feature configuration, the Route header will be modified to direct the request to the configured IcscfUri.

  • Add a Request-Disposition header indicating no-fork.

  • Send the INVITE and await a response.

  • Handle responses according to behaviour outlined below.

The feature will iterate to the next CSRN if the call fails but meets the conditions for fallback. If all possible CSRNs are exhausted and the routing strategy is CS-PS, the feature will fall-back to PS routing.

Note that the response handling for 488 and 18x Responses is the same when the PS domain is selected and the same fallback rules are applied.

CS Domain Call Diversion Suppression

For outgoing requests from T-ADS, call diversion for the CS network can be suppressed using a modified Diversion header added to the request. This prevents call diversion by an MSC in the CS domain clashing with call diversion functionality in the MMTelCDIV feature.

If SuppressCSDomainCallDiversion is enabled in feature configuration, the Diversion header is added to any request sent to the CS domain. The sum count of diversions detailed in the diversion header is set by DiversionLimitCSDomain. This value specifies a diversion count that matches or exceeds the redirection limit in the CS domain, hence the MSC suppresses call diversion in the CS domain.

In the case where there is no support for the diversion-count parameter at the gateway between the CS domain MSC and the IMS, the number of diversion instances in a diversion header communicates this diversion count value to the MSC. This mode is used when UseDiversionCounterParameter is disabled.

Selected Domain is PS

If T-ADS chooses to deliver on the PS domain, the T-ADS Routing feature will iterate through the URIs queued in the TADSPacketRoutes session state field. If any Path information is set in TADSCurrentLegPaths session state then these are added as routes to the outgoing INVITE.

Going one at a time, for each URI the feature will:

  • Create an INVITE to the called party using the URI as the Request-URI and also as the To header.

  • If TADSSipInstanceRoutingPossible is true in session state, add a Request-Disposition header indicating no-fork.

  • Add any routes in TADSCurrentLegPaths to the INVITE.

  • Send the INVITE and await a response.

  • Handle responses according to behaviour outlined below.

The feature will iterate to the next URI if the call fails but meets the conditions for fall-back. If all possible URIs are exhausted and the routing strategy is PS-CS, the feature will fall-back to CS routing.

Response handling

The responses are handled the same way for PS and CS domains, except where noted.

Max Wait Timer

Upon forwarding the INVITE request towards the preferred access network, the T-ADS routing feature arms a timer with the value from TimerTADS configuration. If this timer expires before a response to the INVITE request is received, the INVITE will be cancelled and the feature will fall-back to the next available route. The timer will be cancelled if a response is received before it expires, though it may be replaced with a new timer under the conditions outlined in the 18x Response section.

488 Response

After forwarding the INVITE, if the T-ADS Routing feature receives a 488 ("Not Acceptable Here") response from the UE that:

  • does not include any SDP body; OR

  • includes an SDP body:

    • without a media description (m=) indicating audio;

    • with a media description (m=) only indicating audio with the <proto> subfield set to PSTN and with a connection data line (c=) with <nettype> set to PSTN

The feature will not forward the response, and it will fall-back to the next available route.

A 488 response that does not meet the above conditions will be forwarded to the calling party.

UPDATE 481 Response

If the T-ADS Routing feature receives an UPDATE 481 response on a T-ADS leg, it will suppress the upstream response. This allows fallback to be triggered on a subsequent INVITE error. As per RFC 3311 UPDATE 481 responses are considered dialog terminating. An UPDATE 481 can indicate an INVITE final response (3xx and above) and UPDATE success crossover case.

Suppressing UPDATE 481 responses avoids the upstream UE terminating the call when T-ADS fallback options are available.

PS Routing Error Response Handling

When attempting to route to PS, the feature will additionally consider SIP response error codes that are contained in the configured PSToCSFallbackResponseCodes. These error responses are handled in the same way as a 488 Response.

18x Response

If the T-ADS Routing feature receives a 18x response it will evaluate it to determine if it is acceptable. If the 18x response contains an SDP answer with a media description (m=) set to audio and port portion set to 0, then it is not acceptable. In all other cases the 18x will be considered acceptable.

If the 18x is acceptable the call will proceed on the leg it was received on and T-ADS will complete execution.

If the 18x is not acceptable the feature will arm a timer using the TimerTADS feature configuration value as the duration. The feature will then wait until:

  • a acceptable 18x response arrives, in which case the timer will be cancelled and the call will proceed, OR

  • a non-18x response arrives, which will be handled as described in its respective response handling section, OR

  • the timer expires, OR

  • the number of forked responses is equal to the number of simultaneously registered devices for the served user.

If either of the last two conditions are met, the T-ADS Routing feature will send a CANCEL for the outbound INVITE, and fall-back to the next available route.

Others

All other responses are forwarded upstream.

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

Graceful Handling of Originating Access

The feature will finish execution without modifying any state if invoked in an originating call attempt.

Previous page Next page
Sentinel VoLTE Version 4.0.0