On this page

What it does

Terminating Access Domain Selection (T-ADS) is a component of the terminating SCC AS that determines whether a call should be delivered over the circuit-switched (CS) or the packet-switched (PS) network. It adjusts the SIP signaling as required to deliver the call over the CS or PS network.

Routing mode

T-ADS supports several different modes which determine how it will prioritize its attempts to connect to the CS and/or PS networks. The mode to use for any given call is not determined by T-ADS configuration, but instead by a parameter on the Route header of the incoming SIP INVITE request. The parameter’s name is oc-tads-routing. It can have the following values:

Table 1. T-ADS routing modes
Parameter value Behavior 
ps-cs

T-ADS first attempts to connect the call over the PS network, and falls back to the CS network if that fails.

 
cs-ps

T-ADS first attempts to connect the call over the CS network, and falls back to the PS network if that fails.

 
ps-only

T-ADS only attempts to connect the call over the PS network.

 
cs-only

T-ADS only attempts to connect the call over the CS network.

 
parallel

T-ADS forks the call and attempts to connect the call over the CS and PS networks simultaneously; the first fork to be successfully answered is selected.

If the parameter is absent, the ps-cs behavior is used.

All modes other than parallel are collectively known as "sequential" modes.

Note Route header parameters can be set in the subscriber’s initial filter criteria (iFC) on the HSS.

Request disposition

In one particular case, the Request-Disposition header (defined in RFC 3841) can alter the behavior selected by the oc-tads-routing parameter. If the Request-Disposition header contains the value no-fork and does not also contain the value redirect, then:

  • ps-cs and parallel use the ps-only behavior

  • cs-ps uses the cs-only behavior.

CS routing

When T-ADS attempts to route the call over the CS network, it will generate a CS Domain Routing Number (CSRN). This number is used in the Request-URI of the outbound INVITE request. There are a few options for how T-ADS should generate the CSRN.

The basic number can be taken from any of the following numbers:

  • Correlation Mobile Station International Subscriber Directory Number (C-MSISDN), which is retrieved from the HSS

  • Mobile Station Roaming Number (MSRN), which is retrieved from the HLR (for GSM networks only)

  • Temporary Local Directory Number (TLDN), which is retrieved from the HLR (for CDMA networks only).

An optional prefix can be specified that will be added to that number to create the final CSRN.

Routing via the I-CSCF

When routing to the CS network, it may be desirable to send the outbound INVITE request directly to the I-CSCF, bypassing the S-CSCF and thus any further IMS services that it might try to invoke. This can be configured with the cs-routing-via-icscf field.

PS routing

T-ADS supports three different modes for determining where to route requests to the PS network. It may route to:

  • the subscriber’s IMS public identity

  • the SIP instance(s) that are recorded in pub-gruu information in the subscriber’s registration data

  • the SIP instance(s) that are recorded in pub-gruu and Path information in the subscriber’s registration data.

Both modes that use SIP instances can result in multiple different attempts to connect the call over the PS network (one attempt for each acceptable SIP instance).

Route validation and voice over PS support

Unless there is an oc-blindpsrouting parameter present on the Route header of the initial INVITE request for a call, T-ADS will do additional validation on each PS route before deciding to use it.

The method for doing this validation depends on the setting for voice-over-ps-support.

If voice over PS support is required, the route will be validated by explicitly asking the HSS if voice over PS is supported for that route. If voice over PS support is not required, the route will be validated by checking access network information in the subscriber’s registration data.

When querying the HSS for voice over PS support, there are several different options for which subscriber identity to query the information for. The option to use varies depending on the network. The options are listed here.

Table 2. Subscriber identities for HSS queries
Setting Description 
IMPU

The IMS public identity

 
MSISDN

The C-MSISDN

 
IMPU_IMPI

A combination of the IMS public and private identities

 
MSISDN_IMPI

A combination of the C-MSISDN and the IMS private identity

Voice over Wi-Fi

By default, T-ADS will select PS routes that go through the PS cellular network. The system also supports PS routes that go through the internet and Wi-Fi. You can configure this with the wlan-allowed field.

Deciding on a route

This section describes the approach T-ADS uses to decide whether a particular routing attempt has been successful. The routing mode determines the order in which routes are attempted (or whether they should all be attempted at the same time in the case of parallel mode). It is important to note that even if a particular route receives a SIP error response, T-ADS may still determine it was a successful routing attempt and forward the response to the caller, thus ending the call.

In sequential routing modes

Usually, a route is selected and T-ADS completes once a non-100 SIP response is received from a connection attempt on that route (which is true even if the response is an error response that will cause the call to be terminated). A route is usually only rejected if no response is received within the maximum wait time period specified in the tads-timer-max-wait-milliseconds setting. However, there are exceptions to this:

  • If a provisional SIP response is received that has an SDP body with a disabled audio stream and the subscriber is known to have multiple devices on the current route, the response will be ignored and the maximum wait time will be reset.

  • If a SIP error response with a 488 status code is received, the route is rejected.*

  • If attempting a PS route and a SIP error response is received with a status code matching a code in ps-fallback-response-codes, the route is rejected.*

* If all PS routes have been exhausted and the error response has an SDP body with no PSTN audio streams, the call will be terminated instead.

When a route is rejected, T-ADS aborts the connection attempt and attempts to connect the call on the next available route. If all available routes have been rejected, the call is terminated.

In parallel routing mode

The first route to receive a SIP success response is selected. If all routes respond with a SIP error response or the maximum wait time period specified in the parallel-timer-max-wait-milliseconds setting is exceeded, the call is terminated.

As a special case when the companion device service is in use, if a 486 Busy SIP response is received from any route it is possible to end the call immediately. You can configure this with the release-all-legs-on-busy setting.

Interactions with other services

Communications Diversion (CDIV)

If an attempt to connect the call over the CS network fails, it is possible that communication forwarding could be triggered twice; the first time downstream of the SCC AS in the CS core network, the second time in the IMS core upstream in the MMTel AS.

T-ADS can be configured to suppress communication forwarding services in the CS network. It does this by imposing a limit on the number of times the call may be forwarded, then indicating that the limit has been reached. SIP Diversion headers are used to send this information to the CS network, with limit parameters used to set the limit. One of the following methods is used to indicate that the limit has been reached:

  • including a pair of Diversion headers that each have a counter parameter which, between the two, sums to the diversion limit, or

  • including a number of Diversion headers that matches the limit.

For configuration instructions, see Suppress call forwarding services in the CS network.

For details of how to suppress forwarding in the MMTel AS, see Communications Diversion (CDIV).

Companion device

The companion device service may force T-ADS to ignore the requested routing mode and use parallel instead. Restrictions imposed by the Request-Disposition header will still apply in this case.

The companion device service may also provide its own set of CSRNs for T-ADS to use when attempting to connect the call over the CS network.

Configuration

The example for sentinel-volte-gsm-config.yaml and example for sentinel-volte-cdma-config.yaml show example configuration relevant to T-ADS in the sentinel-volte/tads section.

What you need

  • ❏ The source for generating the CSRN for CS delivery; one of: C-MSISDN, MSRN, or TLDN.

  • ❏ The source for generating potential PS routes; one of: IMS_PUBLIC_IDENTITY, SIP_INSTANCE, or PATH_FROM_SIP_INSTANCE.

  • ❏ If checking for Voice Over PS support before routing over PS to a subscriber, the identity to use when querying the HSS; one of: IMPU, MSISDN, IMPU_IMPI, or MSISDN_IMPI

  • ❏ Whether or not calls outbound to the CS network should bypass the S-CSCF and go directly to the I-CSCF.

  • ❏ Whether or not calls are allowed to be delivered over a Wi-Fi network.

  • ❏ What error code to send to the caller if the call is terminated due to no routes being found.

If using the parallel routing mode:

  • ❏ The maximum time to wait for a call to be answered.

  • ❏ Whether or not to abort the call if any routing attempt receives a 486 Busy response.

If using any sequential routing modes:

  • ❏ The maximum time to wait for a response during a particular routing attempt.

  • ❏ Any SIP error codes that you would like to trigger an attempt on the next available route, instead of ending the call.

Setting up CS routing behavior

I want to…​

Generate the CSRN from the C-MSISDN when routing to the CS network
Warning Ensure that HSS integration has been configured.

In the tads section, set address-source-for-scc-tads to CMSISDN:

            address-source-for-scc-tads: CMSISDN

Related section: CS routing

Generate the CSRN from the MSRN when routing to the CS network
Warning Ensure that HLR integration has been configured.
Note Be aware that the MSRN is only available on GSM networks.

In the tads section, set address-source-for-scc-tads to MSRN:

            address-source-for-scc-tads: MSRN

Related section: CS routing

Generate the CSRN from the TLDN when routing to the CS network
Warning Ensure that HLR integration has been configured.

Be aware that the TLDN is only available on CDMA networks.

In the tads section, set address-source-for-scc-tads to TLDN:

            address-source-for-scc-tads: TLDN

Related section: CS routing

Include a number prefix (steering digits) on the generated CSRN

In this example 00 is used as the prefix.

In the tads section, set csrn-prefix to "00":

            csrn-prefix: "00"

Related section: CS routing

Have no prefix (steering digits) on the generated CSRN

In the tads section, set csrn-prefix to "":

            csrn-prefix: ""

Related section: CS routing

Prevent T-CSI information from being requested from the HLR
Note This is only relevant on GSM networks when using the MSRN to generate the CSRN.

In the tads section, in sri-requests-to-hlr, set set-suppress-tcsi-flag to true:

            sri-requests-to-hlr:
                set-suppress-tcsi-flag: true
Prevent announcement information from being requested from the HLR

This is only relevant on GSM networks when using the MSRN to generate the CSRN.

In the tads section, in sri-requests-to-hlr, set set-suppress-announcement-flag to true:

            sri-requests-to-hlr:
                set-suppress-announcement-flag: true
Route calls to the CS network directly through the I-CSCF
Warning Ensure that I-CSCF integration has been configured.

In the tads section, set cs-routing-via-icscf to true:

            cs-routing-via-icscf: true

Related section: Routing via the I-CSCF

Route calls to the CS network through the S-CSCF

In the tads section, set cs-routing-via-icscf to false:

            cs-routing-via-icscf: false

Related section: Routing via the I-CSCF

Suppress call forwarding services in the CS network

In the tads section, ensure that the suppress-cs-domain-call-diversion section is present and not commented out.

            suppress-cs-domain-call-diversion:
                use-diversion-counter-parameter: true
                cs-domain-diversion-limit: 1

  • Set use-diversion-counter-parameter to:

    • true to indicate that the limit has been reached using the counter parameter on the SIP Diversion header, or

    • false to indicate that the limit has been reached using the number of Diversion headers present.

  • Set cs-domain-diversion-limit to the maximum number of times you want to indicate that call forwarding was allowed (note that no matter what this setting is, T-ADS will still indicate that the limit has been reached).

Related section: Interaction with call forwarding

Allow call forwarding services in the CS network

In the tads section, remove or comment out the entire suppress-cs-domain-call-diversion section.

 #           suppress-cs-domain-call-diversion:
 #               use-diversion-counter-parameter: true
 #               cs-domain-diversion-limit: 1

Related section: Interaction with call forwarding

Setting up PS routing behaviour

I want to…​

Route the PS attempt to the subscriber’s IMS public identity

In the tads section, set tads-identity-for-terminating-device:

            tads-identity-for-terminating-device: IMS_PUBLIC_IDENTITY

Related section: PS routing

Route PS attempts to the SIP instance of the terminating device(s)

In the tads section, set tads-identity-for-terminating-device:

            tads-identity-for-terminating-device: SIP_INSTANCE

Related section: PS routing

Route PS attempts to the SIP instance path of the terminating device(s)

In the tads section, set tads-identity-for-terminating-device:

            tads-identity-for-terminating-device: PATH_FROM_SIP_INSTANCE

Related section: PS routing

Check that a subscriber has support for Voice Over PS before attempting to route over the PS network
Warning Ensure that HSS integration has been configured.

In the tads section, ensure that the voice-over-ps-support section is present and not commented out.

            voice-over-ps-support:
                request-user-identity-type: IMPU

Set which subscriber identity to use when querying the HSS for the voice over PS support information. See request-user-identity-type for the list of options.

Related section: Route validation and voice over PS support

Skip the check that the subscriber has voice over PS support before attempting to route the call over the PS network

In the tads section, remove or comment out the entire voice-over-ps-support section.

#            voice-over-ps-support:
#                request-user-identity-type: IMPU

Related section: Route validation and voice over PS support

Allow calls to be connected over Wi-Fi networks

In the tads section, set wlan-allowed:

            wlan-allowed: true

Related section: Voice over Wi-Fi

Setting up route selection behavior

I want to…​

Change the SIP response code used to end the call if no valid route to the called party can be found

In this example the call will be ended with a 410 Gone response.

In the tads section, set end-session-error-code:

            end-session-error-code: 410
End all companion device connection attempts if any one of them returns a 486 Busy response

In the tads, on-parallel-routing section, set release-all-legs-on-busy:

                release-all-legs-on-busy: true

Related section: Deciding on a route in parallel routing mode

Change the maximum time to wait to get a final response from any parallel connection attempt

This example sets the maximum wait time to 15 seconds.

In the tads , on-parallel-routing section, set parallel-timer-max-wait-milliseconds to the desired value in milliseconds:

                parallel-timer-max-wait-milliseconds: 15000

Related section: Deciding on a route in parallel routing mode

Try the next available route if a PS attempt results in a particular SIP response status code or codes
Note A 488 response will always cause the next available route to be attempted, and does not need to be included in this field.

This example lists 408, 480, and 481 as the codes that should trigger the next routing attempt.

In the tads, on-sequential-routing section, set ps-fallback-response-codes with the list of desired response codes:

                ps-fallback-response-codes: [ 408, 480, 481 ]

Related section: Deciding on a route in sequential routing modes

Change the maximum time to wait for a response before trying the next route
Note This setting is only relevant when using a sequential routing mode and is subject to the provisional response condition described in Deciding on a route in sequential routing modes.

In the tads, on-sequential-routing section, set tads-timer-max-wait-milliseconds to the value in milliseconds:

                tads-timer-max-wait-milliseconds: 5000
Previous page Next page
Rhino VoLTE TAS Version 4.1