This feature implements the procedures for SCC-AS transferring of a single active session. It executes inside a signalling anchor instance .
It is executed once the SCC-AS has determined that there is an active session, and has provided the INVITE to the signalling anchor. It is responsible for processing incoming access transfer handover INVITE requests i.e. INVITE due to STN-SR or INVITE due to ATU-STI. It performs a remote update if necessary, and closes the old Access Leg (source access leg).
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 |
SIP Mid-Session Party Request/Response |
None |
None |
Stateless |
POJO |
Session input and output variables
Session input variables
| Variable | Type | Description |
|---|---|---|
CallType |
String |
Used to determine if access transfer is being performed for the called party or the calling party. |
CurrentRemoteLegName |
String |
Used to find the remote leg. |
CurrentLocalLegName |
String |
Used to find the old access leg. |
Session output variables
| Variable | Type | Description |
|---|---|---|
NewAccessLegName |
String |
The name of the new access leg. |
OldAccessLegName |
String |
The name of the old access leg. |
CurrentCalledLegName |
String |
The name of the current called leg, updated when access transfer is performed for the called party. |
CurrentCallingLegName |
String |
The name of the current calling leg, updated when access transfer is performed for the calling party. |
CurrentLocalLegName |
String |
The name of the current local leg, updated when access transfer occurs. |
Statistics
SCCProcessHandoverInsideAnchor 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 → SCCProcessHandoverInsideAnchor
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.0.0].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.0.0].feature.SCCProcessHandoverInsideAnchor"
| Name | Type | Description |
|---|---|---|
Started |
Counter |
Incremented each time the feature runs. |
FailedToStart |
Counter |
Incremented when Sentinel VoLTE encounters an error while attempting to start the feature. |
IssuedWarning |
Counter |
Incremented when the feature encounters a non-fatal error while executing. |
FailedDuringExecution |
Counter |
Incremented when the feature encounters a fatal error while executing. |
TimedOut |
Counter |
Incremented when the feature does not finish executing within a reasonable time frame. |
RemoteUpdateRequired |
Counter |
Incremented when the feature determines that a remote update is required. |
RemoteUpdateNotRequired |
Counter |
Incremented when the feature determines that a remote update is not required. |
SentRemoteUpdate |
Counter |
Incremented when the feature sends a remote update to the remote party. |
RemoteUpdateSuccess |
Counter |
Incremented when the feature receives a success response for the remote update request. |
RemoteUpdateError |
Counter |
Incremented when the feature receives a failure response for the remote update request. |
RemoteUpdate491Retry |
Counter |
Incremented when the feature receives a 491 response with an |
CallAnsweredWith200 |
Counter |
Incremented when the feature sends a success response for the handover INVITE on the new access leg. |
ReleasedOldAccessLeg |
Counter |
Incremented when the feature releases the old access leg. |
LinkedNewAccessLegToRemoteLeg |
Counter |
Incremented when the feature links the new access leg to the remote leg. |
AccessTransferAttempted |
Counter |
Incremented when the feature attempts an access transfer. |
TerminatedSession |
Counter |
Incremented when the feature terminates the session due to an error during access transfer. |
AccessTransferComplete |
Counter |
Incremented when the access transfer process is complete, after the ACK is received by the feature on the new access leg. |
TimerStarted |
Counter |
Incremented when the retry timer is started by the feature. |
TimerFired |
Counter |
Incremented when the retry timer fires and triggers the feature. |
TimerCancelled |
Counter |
Incremented when the retry timer is cancelled by the feature. |
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. |
FailedToImportNewAccessLeg |
Counter |
Incremented when the feature fails to import the new access leg into the session. |
FailedToDetermineIfRemoteUpdateRequired |
Counter |
Incremented when the feature cannot determine whether a remote update is required. |
LegManagementError |
Counter |
Incremented when the feature fails to link/unlink new and old access legs to/from the remote leg. |
FailedToCreateAnswerForHandoverInvite |
Counter |
Incremented when the feature fails to create a response to a handover INVITE request when a remote update is not required. |
FailedToForwardAnswerForHandoverInvite |
Counter |
Incremented when the feature fails to forward a response to a handover INVITE request after a remote update is completed. |
FailedToSendRemoteUpdate |
Counter |
Incremented when the feature needs to send a remote update request, but cannot do so because of an internal error. |
RemoteUpdateRefused |
Counter |
Incremented when the remote party rejects a remote update request. |
RemotePartyDisconnected |
Counter |
Incremented when the remote party ends the call while a remote update is in progress. |
MediaInterruption0to50ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 0 to 50ms after being sent. |
MediaInterruption51to100ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 51 to 100ms after being sent. |
MediaInterruption101to150ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 101 to 150ms after being sent. |
MediaInterruption151to200ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 151 to 200ms after being sent. |
MediaInterruption201to250ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 201 to 250ms after being sent. |
MediaInterruption251to300ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 251 to 300ms after being sent. |
MediaInterruption301to350ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 301 to 350ms after being sent. |
MediaInterruption351to400ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 351 to 400ms after being sent. |
MediaInterruption401to450ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 401 to 450ms after being sent. |
MediaInterruption451to500ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted 451 to 500ms after being sent. |
MediaInterruptionMoreThan500ms |
Counter |
Incremented when a re-INVITE to the remote party is accepted more than 500ms after being sent. |
Behaviour
An INVITE due to ATU-STI, or an INVITE due to STN-SR that arrive at the SCC-AS are referred to as a "Handover INVITE" in this page. This feature implements the transfer of a single active session as per section 12.3.5 of 3GPP TS 24.237. It includes support for anchored and non-anchored media at the ATGW. The removal of superfluous sessions is implemented by the SCCCoordinateSignallingAnchors and SCCRemoveSuperfluousSession features.
Remote and Access Legs
An Originating SCC signalling anchor has two legs, prior to access transfer. One from the A party (the Access Leg), and one towards the B party (the Remote Leg). I.e. the INVITE received by the SCC-AS from the S-CSCF is on the Access Leg. The INVITE sent towards the S-CSCF is on the Remote Leg.
A Terminating SCC signalling anchor has two legs, prior to access transfer. One from the A party (the Remote Leg), and one towards the B party (the Access Leg). I.e. the INVITE received by the SCC-AS from the S-CSCF is on the Remote Leg. The INVITE sent towards the S-CSCF is on the Access Leg.
The SCC-AS acts as a routing B2BUA between the Access and Remote legs.
In 3GPP TS 24.237, the phrases source access leg and target access leg are used. This document refers to the old access leg and new access leg respectively.
Detecting Handover INVITE
The feature is initially triggered on any mid-session INVITE request. In order to determine if the request is a handover INVITE, the feature looks for the OC-Access-Transfer-Procedure header, set by the SCCSendRequestToAnchor feature.
If this header is not present, the feature ignores the request and finishes without interfering with the call flow.
If the header is present, the feature will begin Initial Handover Procedures, and then continue according to the selected access transfer type.
Initial Handover Procedures
Upon detecting a handover INVITE, the feature begins the access transfer process. It starts by importing the SIP leg that the handover INVITE was received on into the current call session as the "new access" leg. The feature then examines the SDP in the handover request to see if it is in line with the currently negotiated SDP for the session. If the SDP is different, then the feature will undertake Access Transfer Procedures for Non-Anchored Media to renegotiate the SDP with the remote party; if the SDP matches the currently negotiated SDP then Access Transfer Procedures for Anchored Media will be undertaken. Regardless of whether SDP needs to be renegotiated, the feature will unlink the old access SIP leg from the leg towards the remote party.
Access Transfer Procedures for Non-Anchored Media
If the SDP needs to be renegotiated with the remote party, the feature will generate a Re-INVITE request for the remote
party based on the original handover request (with the OC-Access-Transfer-Procedure header removed). The feature will send
this Re-INVITE and then end processing until triggered by a response (or a new request). The feature’s next action will
depend on what triggers it:
| Trigger | Behaviour |
|---|---|
Error response from remote leg |
Access transfer will be aborted, the old access leg will be re-linked to the remote leg, and the error response will be forwarded on the new access leg. |
BYE request from remote leg |
All legs will be terminated. A 200 OK to the BYE will be sent on the remote leg. A 480 Temporarily Unavailable in response to the access transfer INVITE will be sent on the new access leg. A BYE request will be sent on the old access leg. |
New INVITE request from the old access leg |
Reject the INVITE with a 491 response, continue waiting for Re-INVITE response |
BYE request from old access leg |
Reply with 200 OK, continue waiting for Re-INVITE response |
Success response from remote leg |
Forward the response on the new access leg and link the new access leg to the remote leg, await ACK |
After receiving a 200 OK response from the remote leg, the feature will await the ACK for the 200 from the new access leg. Upon receiving the ACK, the feature will terminate the old access leg (sending a BYE).
The signalling anchor (Sentinel instance) hosting the SCC features is now acting as a B2BUA between the new access leg (from the ATCF) and the remote leg (through the S-CSCF).
The feature is then complete.
Access Transfer Procedures for Anchored Media
In the event that no change in the SDP needs to be negotiated with the remote party, the feature will immediately answer the handover INVITE with a 200 OK response, and await the ACK from the new access leg. Upon receiving the ACK from the new access leg, the feature will link that leg to the remote leg. The ACK will not be forwarded.
If a BYE is received from the old access leg while waiting for the ACK, the BYE will be accepted with a 200 OK, terminating the old access leg. If no BYE is received then the feature will automatically terminate the old access leg (sending a BYE) upon receiving the ACK from the new access leg.
Once the ACK has been received the transfer is complete.
The signalling anchor (Sentinel instance) hosting the SCC features is now acting as a B2BUA between the new access leg (from the ATCF) and the remote leg (through the S-CSCF).
A call flow for this procedure is shown SCC Access Transfer Media Anchored Flow.
Call flows for Session transfer of an active session
The following flows described in 3GPP TS 24.237 and illustrate the signalling for transfer of a single active session.
