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