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 Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

SCC

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 volte.sentinel.sip SBB and can be found under the following parameter set in REM:
SLEE-Usage → volte.sentinel.sip service → volte.sentinel.sip SBB → feature → SCCProcessHandoverInsideAnchor
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].SbbID[name=volte.sentinel.sip,vendor=OpenCloud,version=2.7.0].feature.SCCProcessHandoverInsideAnchor"

Name Description
RemoteUpdateRequired

Incremented when the feature determines that a remote update is required.

RemoteUpdateNotRequired

Incremented when the feature determines that a remote update is not required.

SentRemoteUpdate

Incremented when a remote update is sent to the remote party.

RemoteUpdateSuccess

Incremented when a success response is received for the remote update request.

RemoteUpdateError

Incremented when a failure response is received for the remote update request.

CallAnsweredWith200

Incremented when a success response is sent for the handover INVITE on the new access leg.

ReleasedOldAccessLeg

Incremented when the old access leg is released.

LinkedNewAccessLegToRemoteLeg

Incremented when the new access leg is linked to the remote leg.

TerminatedSession

Incremented when the session is terminated due to an error during access transfer.

AccessTransferComplete

Incremented when the access transfer process is complete, after the ACK is received on the new access leg.

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 2.7.0