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

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 to routes to a preferred leg when PS is preferred.

 
RouteToPreferredCS

Incremented when the feature successfully to routes to a preferred leg when CS is preferred.

 
RouteToFallbackPS

Incremented when the feature successfully to routes to a fallback leg when PS is preferred.

 
RouteToFallbackCS

Incremented when the feature successfully to routes to a fallback leg when CS is preferred.

 
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 a preferred PS leg is answered

 
RouteToFallbackPSAnswered

Incremented when a fallback PS leg is answered

 
RouteToPreferredCSAnswered

Incremented when a preferred CS leg is answered

 
RouteToFallbackCSAnswered

Incremented when a fallback CS leg is answered

 
RouteToPreferredPSFailed

Incremented when a preferred PS leg returns a failed SIP response e.g. >299

 
RouteToPreferredCSFailed

Incremented when a preferred CS leg returns a failed SIP response e.g. >299

 
RouteToFallbackPSFailed

Incremented when a fallback PS leg returns a failed SIP response e.g. >299

 
RouteToFallbackCSFailed

Incremented when a fallback CS leg returns a failed SIP response e.g. >299

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.

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.

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 3.1.0