Feature listing

Feature What it does

prepares a signalling anchor such that it is ready to receive and process an access transfer request for the current session

receives an Access Transfer INVITE or MESSAGE request and forwards the request to the appropriate Signalling Anchor instance

implements the procedures for SCC-AS transferring of a single active session. It executes inside a signalling anchor instance

determines the transferable set for access transfer

sends SIP MESSAGE requests to instruct superfluous session removal

terminates a superfluous session as part of access transfer procedures

enables Access Leg Tracking for the current session if the UE is SR-VCC capable and has a C-MSISDN

implements SCC-AS procedures for access transfer of a terminating call in the alerting phase using PS to CS SRVCC

implements SCC-AS procedures for access transfer of an originating call in the alerting or pre-alerting phases using PS to CS SRVCC

assists with originating sessions towards the Conference Factory by augmenting the REFER request sent from the UE to the Conference Factory

Relationship between the features

A high level relationship between the features is illustrated through a series of diagrams.

Access transfer of a single established session

Call flow diagrams for this case are shown on Call flows for Session transfer of an active session.

The following diagram shows the main features used for transfer of a single active session. It assumes all signalling involves a single cluster member for the purposes of simplicity.

scc-single-active-session-transfer

There are two sessions shown:

  1. the "Anchored session" - the session to be transferred and

  2. the "Transfer session" - the session initiated by the Handover INVITE

The Anchored session is shown twice in the diagram to represent its two phases, the initial phase and the transfer phase. At the top of the diagram, the Anchored session in its initial phase is first executed until SCCBindEnhancedSRVCC feature has finished. The diagram shows that the DetermineVoltePlanId, SCCDetermineSessionType, SCCDetermineExternalSessionTracking, TrackSession, and SCCBindEnhancedSRVCC features are executed sequentially. At this point the call is answered.

In the middle of the diagram the Transfer session is shown. Some time after the Anchored session is answered, a Handover INVITE arrives at the SCC-AS. This then executes the DetermineVoltePlanId, SCCDetermineSessionType, SCCDetermineTransferableSet, and SCCSendRequestToAnchor features in sequence. The SCCSendRequestToAnchor feature internally passes the Handover INVITE to the existing Anchored session. The Transfer session is then deleted without performing any further signalling.

Finally at the bottom of the diagram, the Anchored session is shown for the transfer phase. It executes the SCCProcessHandoverInsideAnchor feature to perform access transfer for the established session, and then the SCCCoordinateSignallingAnchors feature once access transfer has completed. In this case there are no superfluous sessions and so it finishes execution without modifying any state.

Access transfer of an originating session in the alerting or pre-alerting state

The following diagram shows the main features used for transfer of an outgoing call in the alerting phase. It assumes all signalling involves a single cluster member for the purposes of simplicity.

scc originating access transfer

There are two sessions shown:

  1. the "Anchored session" - the session to be transfered (in the alerting phase), and

  2. the "Transfer session" - the session initiated by the Handover INVITE

The Anchored session is shown twice in the diagram to represent its two phases, the initial phase and the transfer phase. The initial phase in starts on receipt of an initial INVITE request and has finished when the call is in the alerting state. The sequence of the features executed in the initial phase are DetermineVoltePlanId, SCCDetermineSessionType, SCCDetermineExternalSessionTracking, AccessLegTracking, SCCBindEnhancedSRVCC, and ExternalSessionTracking. At this point the call is in the alerting phase.

In the middle of the diagram the Transfer session is shown. Some time after the Anchored session is alerting, a Handover INVITE arrives at the SCC-AS. This executes the DetermineVoltePlanId, SCCDetermineSessionType, SCCDetermineTransferableSet, and SCCSendRequestToAnchor features in sequence. The SCCSendRequestToAnchor feature internally passes the Handover INVITE to the existing Anchored session. The Transfer session is then deleted without performing any further signalling.

The last stage of the diagram shows the Anchored session during the transfer phase. It executes the SCCOriginatingPreAnswerSessionTransfer feature to perform access transfer for the originating alerting session. Once the transfer is complete (a 2xx to the Handover INVITE has been sent to the MSC and an ACK to that 2xx received) the SCCCoordinateSignallingAnchors feature executes. In this case there are no superfluous sessions and so it finishes execution without modifying any state.

Access transfer of a single established session and removal of a held session

A call flow for a similar case is shown in the Administration guide on the Complex co-ordination example.

The following diagram simplifies the case to simply having two established sessions, one in the held state (i.e call on hold), and another in the active state (i.e. call in speech).

scc superfluous session

There are three sessions shown:

  1. the active session,

  2. the held session, and

  3. the transfer session

In time, prior to the diagram there are two established sessions, one active and one held.

The top of the diagram shows the receipt of a Handover INVITE. The transfer session executes these features in order DetermineVoltePlanId, SCCDetermineSessionType, SCCDetermineTransferableSet, SCCSendRequestToAnchor. In this example the transferable set indicates that there is one session to transfer (the active session), and one superfluous session (the held session).

The Handover INVITE is provided to the active session. This causes execution of SCCProcessHandoverInsideAnchor. Once the handover has completed, the SCCCoordinateSignallingAnchors feature executes. As the transferable set contains a superfluous session, SCCCoordinatingSignallingAnchors informs the held session to clean up. This is achieved through the use of a SIP MESSAGE request containing an OC-Access-Transfer-Procedure header with value remove-superfluous. The active session continues to exist until the call is terminated.

The MESSAGE request is received inside the held session. The SCCRemoveSuperfluousSession feature executes checking the OC-Access-Transfer-Procedure header value. As the session is established, it terminates the session through sending a BYE request on both the access leg and remote leg.

Reuse of Access Transfer procedures for conferencing

The SCC-AS is able to be configured to convert an INVITE w/Replaces from the Conference Factory to a re-INVITE on the consulting call. It follows similar procedures to Access transfer of a single established session with the following key differences:

  • The "Anchored Session" is the consulting call between the conference moderator and the participant, that will be in the held state.

  • The "Transfer Session" is the INVITE w/Replaces sent towards the participant from the conference factory.

  • No sessions are classified as superfluous or additional sessions.

For how this affects the call flow see Re-INVITE Based Three-party conference setup overview

As of version 3.0.0.2 and later in the 3.0.0 series, the SCCAugmentRefer feature was added to enable Conference Moderator access transfer and make iFC treatment more consistent.

Previous page Next page
Sentinel VoLTE Version 3.0.0