What is SCC Determine Session Type?
This feature classifies incoming INVITE
and MESSAGE
requests to determine if they are invoking SCC services.
An INVITE
request may be classified as:
-
a Reorigination
INVITE
request -
an Access Transfer Request
-
Which will be further classified by the type of Access Transfer
-
-
a standard
INVITE
request
A MESSAGE
request may be classified as:
-
an OpenCloud internal Access Transfer directive
-
not of interest to the SCC AS
Once classified, it rejects those that the implementation is known not to handle, by sending a 403 Forbidden
error response.
If an incoming request appears to be invoking an SCC service but is missing critical information, it will be rejected
with a 400 Bad Request
error response.
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 |
Both Originating and Terminating |
|
Yes |
None |
Stateless |
POJO |
Classifies an incoming Request, sets a session state field |
Related Features
This feature is part of a group of features that implement SCC-AS behaviour. This feature is a prerequisite for SCCSendRequestToAnchor and for DetermineVoltePlanId (on an SCC-AS only).
Network Operator Data
VoLTE Shared Config
Configuration from the JSLEE profile table VoLTESharedConfigProfileTable
is used to define the per node URI
The following values are used:
-
SCCASURI - When running as an SCC AS this value is used for the ASURI in Session State
Conferencing
Conferencing handover detection relies on configuration data that is retrieved from the SCCConfHandlingConfigProfileTable
profile table.
The following value is used:
-
EnableSCCConfHandling - Used to determine whether conferencing handover is enabled
Reorigination
Reorigination detection relies on configuration data that is retrieved from the JSLEE profile table named SCCCommonReOriginationConfigProfileTable
.
The following values are used:
-
UsePrefix - Used to determine if a network prefix is used to detect reorigination
-
NetworkPrefix - The prefix that should be used to detect reorigination
Access Transfer
Access Transfer detection relies on the platform having three values configured:
-
the Access Transfer Update - Session Transfer Identifier (ATU-STI)
-
the Session Transfer Number - Single Radio (STN-SR)
-
the SCC AS’s own URI
The ATU-STI and STN-SR are configured in a profile table RegistrarConfigurationTable
, and the SCC AS URI
is configured in a second profile table VoLTESharedConfigProfileTable
.
Notes on Config Profiles
The profile tables used by this feature are RegistrarConfigurationTable
, VoLTESharedConfigProfileTable
, SCCCommonReOriginationConfigProfileTable
, and SCCConfHandlingConfigProfileTable
.
The Profile Name within the tables is scoped according to the Sentinel Selection Key.
An example profile name is "OpenCloud:::::". This means:
The platform name is "OpenCloud". There is no Network Operator, Session Type, Plan Id, or Subscription ID scoping. The values may also be configured through the Sentinel REM screen:
-
Sentinel ▶ Feature Configuration ▶ SCC Determine Session Type (SIP)
-
Sentinel ▶ Feature Configuration ▶ SCC Camel To IMS Reorigination (SIP)
-
Sentinel ▶ Feature Configuration ▶ VoLTE Shared Config Profile (SIP)
Session Output Variables
Session State Variable Name | Java Type | Valid Values |
---|---|---|
SCCSessionType |
A Java enum with type name |
AccessTransfer, Reorigination, Standard |
AccessTransferType |
A Java enum with type name |
eSRVCC_Anchored, eSRVCC_Not_Anchored, Additional_Session_Transfer, SRVCC, Internal_Directive, Bad_Request_STNSR, Bad_Request_ATUSTI, Bad_Request_SCCURI, None |
ASURI |
String |
A SIP URI |
ConferenceFactoryPSI |
String |
Set if the From header address is a conference factory PSI supported by the platform. |
Statistics
SCCDetermineSessionType statistics are tracked by the sentinel.volte.sip SBB and can be found under the following parameter set:
SLEE-Usage → [sentinel.volte.sip service name] → [sentinel.volte.sip SBB name] → feature.SCCDetermineSessionType
Statistic | Increments when… |
---|---|
Started |
The feature is started. |
FailedToStart |
Sentinel VoLTE encounters an error while attempting to start the feature. |
IssuedWarning |
A non-fatal problem is encountered and the feature and issues a warning. |
FailedDuringExecution |
A fatal problem is encountered and the feature cannot execute correctly. |
TimedOut |
The feature takes too long to complete and Sentinel VoLTE aborts execution. |
SelectedStandardScc |
The feature determines that the incoming |
SelectedReorigination |
The feature determines that the incoming |
SelectedESRVCCAnchored |
The feature determines that the incoming |
SelectedESRVCCNotAnchored |
The feature determines that the incoming |
SelectedSRVCC |
The feature determines that the incoming |
SelectedAdditionalSessionTransfer |
The feature determines that the incoming |
SelectedSpecialConfHandover |
The feature determines that the incoming |
SelectedInternalAccessTransferDirective |
The feature determines that the incoming |
ReceivedBadRequestToSTNSR |
The feature receives a malformed request for rel-8 access transfer. |
ReceivedBadRequestToATUSTI |
The feature receives a malformed request for rel-10 access transfer. |
ReceivedBadRequestToSCCURI |
The feature receives a malformed request for an additional session transfer. |
ReceivedReoriginationRequestWithUnknownID |
The feature receives a reorigination request with an IMRN which is not known as a correlation ID |
Behaviour
The feature begins by checking that it was triggered by an initial SIP INVITE
or MESSAGE
request.
-
If the trigger is not an initial SIP request, the feature will raise an unsupported trigger event error and complete processing.
-
If the trigger is an initial SIP request but is not an
INVITE
orMESSAGE
, then no further action is required and the feature will complete processing. -
If the trigger is an initial
INVITE
orMESSAGE
request, the feature will move on to load its configuration
If any configuration data is missing, then the feature will raise an invalid configuration error and complete processing.
Once configuration is loaded, the feature will analyse the incoming request to determine what type of session the
request is for. It populates the SCCSessionType
and AccessTransferType
session state fields based on what it determines.
For an INVITE
request the feature will check if it is one of:
-
A "Reorigination" request
-
An SCC conferencing special request
-
A "Rel-8 Access Transfer (SRVCC)" request
-
A "Rel-10 Access Transfer (eSRVCC)" request
-
An "Additional Session Transfer" request
If none of the above is true, then the INVITE
will be treated as a "Standard SCC Session".
For a MESSAGE
request the feature will check if it is an "Internal Access Transfer Directive", if it is not then the
request will be treated as a "No Internal Access Transfer Directive" case.
The following sections detail the conditions and feature behaviour for each possible session type.
Reorigination
Reorigination is determined by looking at the Request-URI
of the incoming INVITE
. If it is a tel:
URI that begins
with the configured reorigination prefix number, then the request is considered a reorigination request and the feature
will do the following:
-
set the
SCCSessionType
toReorigination
. -
set the
AccessTransferType
toNone
. -
increment the
SelectedReorigination
statistic.
SCC conferencing special request
A SCC conferening special request is determined if:
-
this is an
SCC
call that isMobileOriginating
orMobileForwarded
-
the
From
header address is a conference factory PSI supported by the platform -
there exists a Replaces header that is not empty
In this case:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toSpecial_Conf_Handover
-
set the session state field
ConferenceFactoryPSI
to the From header address
Rel-8 Access Transfer (SRVCC)
Rel-8 Access Transfer is determined by looking at the Request-URI
of the incoming INVITE
. If it begins
with the configured STN-SR
prefix number, then the request is considered a rel-8 access transfer request. In 3GPP
specifications this is known as a "SIP INVITE request due to STN-SR".
The feature will then do an additional check for the presence of a P-Asserted-Identity
header on the INVITE
request.
If the header is present, then the request is considered to be a rel-8 access transfer request and the feature will
do the following:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toSRVCC
. -
increment the
SelectedSRVCC
statistic.
If the P-Asserted-Identity
header is absent, then the request is malformed and the feature will do the following:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toBad_Request_STNSR
. -
increment the
ReceivedBadRequestToSTNSR
statistic. -
terminate the session by replying to the
INVITE
with a400 Bad Request
response.
Rel-10 Access Transfer (eSRVCC)
Rel-10 Access Transfer is determined by looking at the Request-URI
of the incoming INVITE
. If it matches the configured
value for the ATU-STI
, then the request is considered to be a rel-10 access transfer request. In 3GPP specifications
this is known as a "SIP INVITE request due to ATU-STI for PS to CS SRVCC".
The feature will then do an additional check for the presence of a Target-Dialog
or Replaces
header on the INVITE
request.
If one of those headers is present, then the request is considered to be a rel-10 access transfer request for the case where media is
anchored in the ATCF and the feature will do the following:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toeSRVCC_Anchored
. -
increment the
SelectedESRVCCAnchored
statistic.
If both the Target-Dialog
and Replaces
headers are absent, the feature will move on to check for the presence of a P-Asserted-Identity
header.
If that header is present, then the request is considered to be a rel-10 access transfer request for the case where media is
not anchored in the ATCF, and the feature will do the following:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toeSRVCC_Not_Anchored
. -
increment the
SelectedESRVCCNotAnchored
statistic.
If both the P-Asserted-Identity
is also absent, then the request is malformed and the feature will do the following:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toBad_Request_ATUSTI
. -
increment the
ReceivedBadRequestToATUSTI
statistic. -
terminate the session by replying to the
INVITE
with a400 Bad Request
response.
Additional Session Transfer
Additional session transfer is determined by looking at the Request-URI
of the incoming INVITE
. If it matches the configured
value for the URI of the SCC-AS, then the request is considered to be for an additional session transfer.
The feature will then do an additional check for the presence of a Target-Dialog
header on the INVITE
request.
If the header is present, then the feature will do the following:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toAdditional_Session_Transfer
. -
increment the
SelectedAdditionalSessionTransfer
statistic. -
terminate the session by replying to the
INVITE
with a403 Forbidden
response, as this type of access transfer is not supported by the SCC-AS.
If the Target-Dialog
header is absent, then the request is malformed and the feature will do the following:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toBad_Request_SCCURI
. -
increment the
ReceivedBadRequestToSCCURI
statistic. -
terminate the session by replying to the
INVITE
with a400 Bad Request
response.
Standard SCC Session
If an INVITE
meets none of the above conditions, then the request is considered to be for a standard SCC session and the feature
will do the following:
-
set the
SCCSessionType
toStandard
. -
set the
AccessTransferType
toNone
. -
increment the
SelectedStandardScc
statistic.
Internal Access Transfer Directive
An Internal Access Transfer Directive is a MESSAGE
request sent from a remote SCC AS node that is handling an access
transfer request. Such a request is sent when the remote node determines that the node receiving the request is responsible for handling
a session associated with the access transfer that it is processing. The request instructs the receiving node on what to
do with that associated session.
To be considered an Internal Access Transfer Directive, a MESSAGE
request must meet two conditions:
-
The
Request-URI
must match the URI of the receiving SCC AS. -
The request must include an OC-Access-Transfer-Procedure header.
If those conditions are met, then the feature will do the following:
-
set the
SCCSessionType
toAccessTransfer
. -
set the
AccessTransferType
toInternal_Directive
. -
increment the
SelectedInternalAccessTransferDirective
statistic.