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

SipAccess_SubscriberCheck

Yes

No

Stateless

SBB

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.

 
IsLoggedIn

boolean

Set to true when the served user is currently logged in to the IMS.

 
RegistrationRecords

List<RegistrationRecord>

This contains all of the current registration information for the served user.

 
CMSISDN

String

A string set to a non-null value if there is a C-MSISDN provisioned for the user, and if the user is logged in;
if the user is not logged in.

 
Subscriber

String

The subscriber’s identity.

 
SentinelSelectionKey

SentinelSelectionKey

Used to acquire configuration information.

 
CompanionDevices

List<CompanionDevice>

This contains companion information including SharedSip, SharedTel identities and devices.

Session Output Variables

Session state variable name Type Comments 
BlindPSRouting

boolean

Indicates whether blind PS routing is permitted.

 
RoutingMode

TADSRoutingMode (Enum)

The routing strategy to be used by the T-ADS routing features.

 
TADSSipInstanceRoutingPossible

boolean

Indicates whether T-ADS sip.instance routing is possible for the served user.

 
TADSCircuitRoutes

Queue<String>

Contains all valid CS domain routes (CSRNs) that the feature has calculated

 
TADSPacketRoutes

Queue<RouteAndTerminatingDomain>

Contains all valid PS domain routes that the feature has found along with the network type for each route.

 
PSTerminatingDomainHeaderValue

String

The value inserted into OC-Terminating-Domain header e.g. 'PS'.

 
TADSCircuitRoutesPending

boolean

Used by SCC routing features to indicate if there are any further CS routes left in the queue.

 
TADSEndSessionWhenNoValidRouteFound

boolean

Indicates to the SCCTADSDetermineCircuitRoutes feature that no route was found.

 
TADSEndSessionErrorCode

int

SIP response code used by SCCTADSDetermineCircuitRoutes feature when releasing the session.

Network Operator Data

T-ADS Data Lookup has network operator data in a JSLEE profile table named SCCTADSDataLookUpConfigProfileTable and also SCCTADSNetworkTypeConfigProfileTable. The data is scoped by Sentinel selection key.

SCCTADSDataLookUpConfigProfileTable

Attribute Type Meaning 
ForceSipUserEqualsPhone

boolean

If true, when attempting to extract a CS routable number from a SIP URI, the feature will proceed even if the URI does not have the user=phone parameter.

 
VoiceOverPSSupportRequired

boolean

If true, the HSS must be queried for voice over PS support as part of the decision to attempt to route via PS.

 
RequestUserIdentityType

TADSRequestIdentities (Enum)

Specifies which identities will be used for the voice over PS support request to the HSS.

 
EnableSipInstanceRouting

boolean

Determines whether the feature should attempt to use +sip.instance routing to calculate PS routes.

 
EndSessionWhenNoValidRouteFound

boolean

Will cause the feature to refuse an incoming INVITE with the response code from EndSessionErrorCode if no valid routes can be found.

 
EndSessionErrorCode

int

The response code used when ending the session.

 
UsePathForSipInstanceRouting

boolean

If true, Path information from the REGISTER should be used for routing. This applies to devices that don’t have GRUU support.

 
EnableCompanionSipInstanceRouting

boolean

If true, T-ADS will override EnableSipInstanceRouting flag and route to sip.instance addresses rather than public ID’s in calls with companion devices.

SCCTADSNetworkTypeConfigProfileTable

Attributes Type Meaning 
NetworkType

String

Either the RAT value or the Network Access Type value.

 
TerminatingDomain

String

The value used to populate the OC-Terminating-Domain Header when processing a response from a network of this type

 
Description

String

A text field for a description.

The SCCTADSNetworkTypeConfigProfileTable has multiple profiles, each one being either a RAT value or Network Access Type that will be checked to determine if a call can proceed on the PS network.

Each profile includes a TerminatingDomain value that T-ADS Data Lookup uses this value to populate the PSTerminatingDomainHeaderValue session state variable. The T-ADS Routing features use this to send information about the terminating access domain to upstream network nodes as described here.

The system comes with some default profiles pre-configured as follows, Where ${platform.operator.name} will be substituted with the value used on installation.

Profile Name Network Type TerminatingDomain Description 
${platform.operator.name}:::::1004

1004

PS=EUTRAN

RAT value 1004 = E-UTRAN from TS 29.212 section 5.3.31

 
${platform.operator.name}:::::1006

1006

PS=NR

RAT value 1006 = NR from TS 29.212 section 5.3.31

 
${platform.operator.name}:::::3GPP-E-UTRAN

3GPP-E-UTRAN

PS=EUTRAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::3GPP-E-UTRAN-FDD

3GPP-E-UTRAN-FDD

PS=EUTRAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::3GPP-E-UTRAN-TDD

3GPP-E-UTRAN-TDD

PS=EUTRAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::3GPP-NR-FDD

3GPP-NR-FDD

PS=NR

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::3GPP-NR-TDD

3GPP-NR-TDD

PS=NR

P-Access-Network-Info value from TS 24.229 section 7.2A.4

Additionally if WLAN is chosen as part of the installation for allowed access types, the following entries will also be present in the profile table.

Profile Name Network Type TerminatingDomain Description 
${platform.operator.name}:::::0

0

PS=WLAN

RAT value 0 = WLAN from TS 29.212 section 5.3.31

 
${platform.operator.name}:::::3GPP-WLAN

3GPP-WLAN

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11

IEEE-802.11

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11A

IEEE-802.11A

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11B

IEEE-802.11B

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11G

IEEE-802.11G

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11N

IEEE-802.11N

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

Statistics

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

Name Type Description 
Started

Counter

Incremented when the feature is triggered.

 
FailedToStart

Counter

Incremented when the feature fails to start.

 
FailedDuringExecution

Counter

Incremented when the feature fails while executing.

 
IssuedWarning

Counter

Incremented when the feature issues a warning.

 
TimedOut

Counter

Incremented when the feature times out during execution.

 
QueriedShCache

Counter

Incremented when the Sh Cache Microservice RA is queried.

 
ShCacheDataReceived

Counter

Incremented when the Sh Cache Microservice RA returns data from the query.

 
FoundValidCSRoute

Counter

Incremented when the feature finds a valid route to the CS domain.

 
FoundValidPSRoute

Counter

Incremented when the feature finds a valid route to the PS domain.

 
BlindPSRoutingRequested

Counter

Incremented when the feature has set the BlindPSRouting Session State field.

 
NoForkDispositionOverrodeRoutingMode

Counter

Incremented when the feature does not fork due to disposition header.

 
CompanionDeviceOverrodeRoutingMode

Counter

Incremented when the feature selects parallel routing mode because the subscriber has a companion device.

 
TriggeredEndSession

Counter

Incremented when the feature rejects an INVITE request due to there being no valid routes to forward it on.

 
ResponseLatency

Sampled

Records elapsed time between requesting data from the Sh Cache Microservice RA and getting a response (in milliseconds).

 
CompanionDeviceSipInstanceRoutingEnabled

Counter

Incremented when enabling companion device sip instance routing override.

Behaviour

Determining Routing Strategy

On receiving an INVITE request, the feature will analyse several headers in the request to determine how terminating domain selection should proceed. The main value checked is the oc-tads-routing parameter on the top-most Route header URI; in addition the feature also looks for the oc-blindpsrouting parameter on the same header, and certain values in the Request-Disposition header. The feature also checks the x-msw-companion-device header to determine if the subscriber has a companion device.

OC-TADS-Routing Parameter

oc-tads-routing is a custom parameter for the Route header. It determines the routing strategy used by T-ADS for domain selection. The following table shows the possible values of the parameter and resulting behavior:

Parameter Value Behaviour

ps-cs

SCCTADSRouting feature will be invoked to attempt connection over PS first, sequentially forking to CS if that fails.

cs-ps

SCCTADSRouting feature will be invoked to attempt connection over CS first, sequentially forking to PS if that fails.

ps-only

SCCTADSRouting feature will be invoked to attempt connection over PS only.

cs-only

SCCTADSRouting feature will be invoked to attempt connection over CS only.

parallel

SCCTADSParallelRouting feature will be invoked to attempt connection over CS and PS simultaneously.

OC-Blindpsrouting Parameter

oc-blindpsrouting is another custom parameter for the route header. If this parameter is present on the top-most Route header URI, T-ADS will allow blind PS routing (i.e. no attempt will be made to verify that termination in the PS domain is supported/allowed).

Request-Disposition header

The Request-Disposition header is specified by RFC-3841. The header contains a comma separated list of values. There are many possible values that can be contained within this header, but TADS Data Lookup is only interested in two:

Value Behaviour

no-fork

This will cause T-ADS to override the oc-tads-routing parameter to prevent any forking by the T-ADS routing features. ps-cs and parallel will be overridden to ps-only, cs-ps will be overridden to cs-only.

redirect

If this value is present in the header, the no-fork value will be ignored (if present).

X-Msw-Companion-Device

The X-Msw-Companion-Device header may be set by the upstream terminating MMTel-AS, if the SubscriberDataLookupFromHSS feature found companion device information in the subscriber’s service data.

The value of this header is the companion device’s radio access type — currently only the value "PS" is supported, other values are ignored. If this header is present with the value "PS", then TADS Data Lookup sets the routing mode to parallel, overriding the oc-routing-mode header. This can however be overridden if the Request-Disposition header is present. In which case the rules described in Request-Disposition header above are followed.

Determining CS Routes

CS routes are determined by the SCCTADSDetermineCircuitRoutes feature.

Determining if +sip.instance Routing should be used for PS Routes

The T-ADS Data Lookup feature has several ways of determining if +sip.instance routing should be used.

Note The +sip.instance Contact header parameter is a Uniform Resource Name (URN) that uniquely identifies this specific UA instance.

If RoutingMode is not cs-only and EnableSipInstanceRouting or EnableCompanionSipInstanceRouting is true then +sip.instance routing is enabled. Otherwise +sip.instance routing is disabled.

Regardless of how a route is determined, the feature will perform additional analysis to discover if the route is actually usable for PS routing. If the subscriber is not logged in to the IMS according to the IsLoggedIn session state field, the T-ADS Data Lookup feature will not select any PS routes under any circumstances.

Determining Possible Route When +sip.instance Routing is Disabled

When +sip.instance routing is not in use, the feature will attempt to use the current subscriber identity from Sentinel session state. This identity is determined by the SIP Subscriber Determination Feature. The subscriber identity will be checked using the procedures outlined below, and if it is found to be a valid PS route it will be added to the TADSPacketRoutes queue in session state.

Determining Possible Routes When +sip.instance Routing is Enabled and UsePathForSipInstanceRouting is Disabled

When using +sip.instance routing, the feature will search for PS routes in the served user’s registration data. The Contact headers associated with each active registration for the served user will be checked for a pub-gruu parameter. In the case when multiple contact headers are present in a registration record, the parameter 'oc-ue-contact' is used to determine the actual device. This parameter is added during the registration process.

The value of each pub-gruu parameter that is found will be checked using the procedures outlined below, and if it is found to be a valid PS route it will be added to the TADSPacketRoutes queue in session state. If no valid +sip.instance routes are found, the feature will attempt to find a PS route with the procedure used when +sip.instance routing is disabled.

Determining Possible Routes When +sip.instance Routing is Enabled and UsePathForSipInstanceRouting is Enabled

As per above when using +sip.instance routing, the feature will search for PS routes in the served user’s registration data. However if a pub-gruu is not present then Path information (if usePathForSipInstanceRouting is true) will be used to add extra routes to the the outgoing INVITE. This applies to devices that don’t have GRUU support.

Determining Validity of a PS Route

Regardless of which of the above methods were used to find the possible PS route(s), each route will be checked to ensure it is valid to attempt to route to it over the PS domain.

There are three approaches the feature can use to validate the route:

  1. Checking the registration data associated with the route

  2. Querying the HSS for T-ADS information

  3. No additional validation beyond checking the subscriber is logged into the IMS

Which method is used is based on the VoiceOverPSSupportRequired feature configuration option, and the oc-blindpsrouting Route header parameter:

VoiceOverPSSupportRequired oc-blindpsrouting Route Parameter Validation method

False

Absent

Registration Data

False

Present

No Additional Validation

True

Absent

HSS Query

True

Present

No Additional Validation

Once a route is found to be valid, it will be added to the TADSPacketRoutes queue in session state.

Validation by Registration Data

When validating a route by registration data, the feature will retrieve the registration record associated with the route:

  • For routes determined with +sip.instance routing, this will be the registration that contained the pub-gruu or Path that is being validated.

  • For routes determined without +sip.instance routing, every active registration will be checked (only one needs to pass validation).

The feature will check the P-Access-Network-Info header information in the registration data to decide if PS can be supported. If the access-type values in any of the P-Access-Network-Info headers can be found in the SCCTADSNetworkTypeConfigProfileTable then the feature will consider the route valid.

Validation by HSS Query

If the feature needs to validate routes using the HSS it will form a query to the Sh Cache Microservice RA. This query uses Data Reference 26 T-ADS Information. The access key is determined by the value of the RequestUserIdentityType feature configuration value:

RequestUserIdentityType Access Key Public ID Access Key Private ID

IMPU

SessionState → Subscriber

None

MSISDN

SessionState → CMSISDN

None

IMPU_IMPI

SessionState → Subscriber

Registration → PrivateID

MSISDN_IMPI

SessionState → CMSISDN

Registration → PrivateID

Which registration is used to get the private ID will depend on how the PS routes were determined:

  • For routes determined with +sip.instance routing, this will be the registration that contained the pub-gruu that is being validated.

  • For routes determined without +sip.instance routing, every active registration will be checked (only one needs to pass validation).

This means when an IMPI is required in the query, multiple queries may be needed.

The response to each query will be analysed:

  • If the HSS response indicates that voice over PS is not supported, then the associated route(s) will be considered invalid.

  • If the HSS response indicates that voice over PS is supported and the RAT type in the same response is present in the SCCTADSNetworkTypeConfigProfileTable, then the associated route(s) will be considered valid.

If No Valid Routes Are Found

If the feature is unable to determine any valid PS or CS routes for the given routing strategy, then its behaviour will be determined by the EndSessionWhenNoValidRouteFound configuration parameter. If the parameter is set to true (the default), the feature will generate a response with the error code from EndSessionErrorCode to the incoming INVITE request, terminating the call. If the parameter is set to false, then T-ADS will allow the incoming INVITE to be forwarded as-is.

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