This feature implements SCC-AS procedures for access transfer of an originating call in the alerting or pre-alerting phases using PS to CS SRVCC .
This page refers to SIP INVITE due to STN-SR or SIP INVITE due to ATU-STI as a "Handover INVITE".
Feature cheat sheet
| B2BUA Instance | SAS Support | Originating / Terminating | Points in Session Plan | Network Operator Data | Subscriber Data | Stateful or Stateless | POJO Feature or SBB Feature | Feature FSM |
|---|---|---|---|---|---|---|---|---|
SCC |
Yes |
Originating |
|
No |
No |
Stateless |
POJO |
Yes |
Statistics
SCCOriginatingPreAnswerSessionTransfer statistics are tracked by the sentinel.volte.sip SBB
and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → sentinel.volte.sip SBB → feature → SCCOriginatingPreAnswerSessionTransfer
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=3.0.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=3.0.0].feature.SCCOriginatingPreAnswerSessionTransfer"
| Parameter | Type | Description |
|---|---|---|
Started |
Counter |
Incremented each time the feature runs |
FailedToStart |
Counter |
Incremented when a fatal error occurs before feature execution |
IssuedWarning |
Counter |
Incremented when a non-fatal error occurs during feature execution |
FailedDuringExecution |
Counter |
Incremented when a fatal error occurs during feature execution |
TimedOut |
Counter |
Incremented when feature execution does not complete within a reasonable time frame |
AccessTransferSuccessful |
Counter |
Incremented when the ACK to the 2xx-INVITE due to ATU-STI or STN-SR is received by the feature |
AccessTransferAborted |
Counter |
Incremented when access transfer procedures are aborted before the transfer is complete |
SentRemoteUpdateUsingUpdate |
Counter |
Incremented when a remote update occurs using the UPDATE method (prior to 2xx-INVITE on the remote leg) |
SentRemoteUpdateUsingPrack |
Counter |
Incremented when a remote update should occur prior to session establishment, but the remote UE does not support the UPDATE method |
SentRemoteUpdateUsingInvite |
Counter |
Incremented when a remote update occurs using the INVITE (reINVITE) method. Post 2xx-INVITE on the remote leg. |
MaskedInviteEvent |
Counter |
Incremented when the feature masks delivery of further INVITE events on the new access leg. |
UnmaskedInviteEvent |
Counter |
Incremented when the feature unmasks delivery of further INVITE events on the new access leg. |
Behaviour
This feature implements SCC-AS procedures for access transfer of an originating call in the alerting or pre-alerting phases using PS to CS SRVCC. It includes support for media anchored in the ATGW and media non-anchored, forks of the remote leg, and various race conditions between processing the Handover INVITE and the remote leg answering the call.
The behaviour is best described by reading section 12.3.4.3 in 3GPP TS 24.237. The feature implements the full text. Several call flows showing different success cases are shown in the Example call flows section of this page.
Removal of superfluous sessions is implemented through the SCCCoordinateSignallingAnchors and SCCRemoveSuperfluousSession features.
The following sections define additional behaviour to cover specification gaps.
UEs with an Allow header that does not include UPDATE
TS 24.237 specification doesn’t explicitly describe procedures at the SCC-AS for the case where a UE has specified an Allows header without including an UPDATE as the value. This feature implements behaviour as though it has received a 405-UPDATE when it receives the handover INVITE if:
-
the speech media component of the session to transfer is not equal to that in the Handover INVITE, and
-
the session to transfer has an Allows header without including UPDATE
That is, it creates a new early dialog towards the MSC using a 183 response. The 183 response includes signalling elements described in subclause 6A.4.3A. It includes an SDP answer:
-
with c-line set to the unspecified address (0.0.0.0) if IPv4 or to a domain name within the ".invalid" DNS top-level domain in case of IPv6 as described in IETF RFC 6157; and
-
including media of media types received in SDP offer of the SIP INVITE request due to STN-SR, which are also offered in the SIP INVITE request from the served user; and
It then waits for the 2xx-INVITE from the remote leg and does not forward that on to the MSC. It initiates a re-INVITE to provide the new SDP offer to the remote UE, waits for the 2xx response and forwards it to the MSC.
Error responses other than 405-UPDATE
The specification does not describe behaviour for error responses other than 405-UPDATE. If a necessary SIP procedure fails due to an error response, the feature terminates:
-
the old access leg
-
the new access leg
-
the remote leg
Receipt of non reliable provisional responses from the remote UE
The specification does not cover the remote UE sending non-reliable provisional responses. The feature deals with this case by:
-
making all provisional responses that it sends to the MSC be reliable,
-
when it receives a PRACK from the MSC, it waits for 2xx-INVITE from the remote leg (and does not forward it onwards to the MSC. It then sends a re-INVITE with SDP from the Handover INVITE. When it receives a 2xx to the re-INVITE it forwards that onwards to the MSC.
Call flows for session transfer of an outgoing call in the alerting phases
Session Transfer for an outgoing call in the alerting phase
Please refer to 3GPP TS 24.237 appendix A.17.3. It is a single "successful case" for a originating alerting access transfer where media is not anchored in the ATGW.
Session Transfer for an outgoing call in the alerting phase with forks
Please refer to 3GPP TS 24.237 appendix A.17.6. It is a single "successful case" for a originating alerting access transfer where media is not anchored in the ATGW. Additionally the SC UE has received several forked responses prior to access transfer.
