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

Related features that run in a SCC signaling anchor instance are:

Network operator data

None

Subscriber data

None

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.1].SbbID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].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 OC-Retry-After header for the remote update request.

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 4000ms 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.

Media not anchored in the ATGW

Please refer to 3GPP TS 24.237 appendix A.18.2. It contains a signalling flow for PS to CS SRVCC enhancements using the ATCF without media anchored in the ATGW.

Media anchored in the ATGW

Please refer to 3GPP TS 24.237 appendix A.18.3. It contains a signalling flow for PS to CS SRVCC enhancements using the ATCF where media is anchored in the ATGW.

Previous page Next page
Sentinel VoLTE Version 4.1