Feature Cheat Sheet

Feature Script Name

AccessLegTracking

MMTel or SCC

Both

Call-Type

All

Session Plan

MMTel, SCC, SCC-Term-Anchor

Execution Point

SipAccess_SubscriberCheck, SipAccess_PartyResponse, SipAccess_PartyRequest, SipMidSession_PartyRequest, SipMidSession_PartyResponse

Network Operator Config

None

Subscriber Config

None

POJO or SBB

POJO

Feature FSMs

None

Feature Parameters

None

SAS Support

No

Related features

ExternalSessionTracking

Feature Statistics

AccessLegTracking statistics are tracked by the sentinel.volte.sip SBB and can be found under the following parameter set:
SLEE-Usage → sentinel.volte.sip service ID → sentinel.volte.sip SBB ID → feature.DetermineSessionReplication

Name Type Description 
Started

Counter

Incremented when the feature is triggered.

 
FailedToStart

Counter

Incremented when the feature fails to start.

 
FailedDuringExecution

Counter

Incremented when the feature fails while executing.

 
IssuedWarning

Counter

Incremented when the feature issues a warning.

 
TimedOut

Counter

Incremented when the feature times out during execution.

 
TrackingDataOnInitialInvite

Counter

Incremented when the feature updates tracked data due to an initial INVITE.

 
TrackingDataOnProvisionalResponse

Counter

Incremented when the feature updates tracked data due to a provisional response to the initial INVITE.

 
TrackingDataOnAck

Counter

Incremented when the feature updates tracked data due to the ACK for the initial INVITE.

 
TrackingDataOnHoldStatusChange

Counter

Incremented when the feature updates tracked data due to a change in the hold status of a session.

Behaviour

This feature uses the Sentinel SIP Leg API to provide information to the ExternalSessionTracking feature. This allows the Session Ownership Facility to be used for tracking sessions for the purposes of access transfer.

The feature passes through four phases during session processing. Each phase is associated with a particular point in the session plan. At each phase the feature updates different sets of data.

Tracked Data

There are several sets of data that the feature maintains in the session tracking system. Different sets are updated at different times based on where in the session plan the feature is running. The data sets are:

  • Basic Tracking Data

  • Call Setup Data

  • Media State Data

The following sections outline each piece of information that is handled by this feature, and which of the above sets each belongs to.

Tracking Enabled

Data Set Leg API Field

Basic Tracking Data

 
TrackingEnabled

Flags a leg for tracking be the External Session Tracking feature. The Access Leg Tracking feature will set it to true for all access legs.

WaitForTrackingResultEnabled

Data Set Leg API Field

Basic Tracking Data

 
WaitForTrackingResultEnabled

Flag that indicates to the External Session Tracking feature that it should wait for the result of any session ownership facility operations relating to this leg before allowing the session to proceed. The Access Leg Tracking feature will set this flag to true for all access legs. This is done to ensure access transfer is prepared to run before the session is allowed to continue.

Owner

Data Set Leg API Field

Basic Tracking Data

 
Owner

URI of the node that currently owns the session. The feature will always ensure this matches the URI of the node it’s running on.

Additional Tracking Keys

Data Set Leg API Field

Basic Tracking Data

 
AdditionalTrackingKeys

These are alternative keys (i.e. keys besides the leg’s dialog ID) that can be used to retrieve tracking data for a leg. The feature retrieves these keys from the AccessLegTrackingKeys session state field. The keys present in this session state field are set by various VoLTE features that make use of access leg tracking.

Dialog State

Data Set Leg API Field

Basic Tracking Data

 
AdditionalTrackedAttributes (with attribute key: dialog-state)

This field describes the current state of the leg. The current dialog state is determined first by how far through call setup the leg is, and once call setup is complete, by whether the call is held or not (as determined by the Detect Hold Resume feature). The field will have one of the following values:

  • PARTIAL_DIALOG

  • PRE_ALERTING

  • ALERTING

  • ACTIVE

  • HELD

Media Feature Tags

Data Set Leg API Field

Call Setup Data

 
AdditionalTrackedAttributes (with attribute key: media-feature-tags)

These are the media feature tags that have been seen on this session. They are retrieved from the contact header of the initial INVITE for originating access legs, and the initial INVITE response for terminating access legs.

Associated Dialog ID

Data Set Leg API Field

Call Setup Data

 
AdditionalTrackedAttributes (with attribute key: associated-dialog)

This is the dialog ID of the leg currently linked to the access leg.

Last Active Time

Data Set Leg API Field

Media State Data

 
AdditionalTrackedAttributes (with attribute key: last-active-time)

This is the timestamp for the last time the session entered the active state (i.e. the time the ACK was received, or the last time the call was resumed after being held).

Last Held Time

Data Set Leg API Field

Media State Data

 
AdditionalTrackedAttributes (with attribute key: last-held-time)

This is the timestamp for the last time the session entered the held state.

Committed SDP

Data Set Leg API Field

Media State Data

 
AdditionalTrackedAttributes (with attribute key: committed-sdp)

This is the current negotiated SDP in use on the access leg.

Committed SDP Timestamp

Data Set Leg API Field

Media State Data

 
AdditionalTrackedAttributes (with attribute key: committed-sdp-timestamp)

This is the time at which the current committed SDP on the access leg was accepted.

Feature Phases

The four phases the feature passes through are:

  • Initial Request Processing

  • INVITE Response Processing

  • ACK Processing

  • Mid-Session Message Processing

Once any type of access transfer has been executed on a session, this feature will no longer attempt to maintain access leg information, and will always end without executing any phase.

Initial Request Processing

Execution Point: SipAccess_SubscriberCheck

This phase is only executed on originating AS instances, and only on the initial INVITE request. This means that the access leg will always be the leg the INVITE was received on, and there will never be any forked access legs.

The feature will skip this phase if the PartialDialogAccessLegTrackingActive session state field is false. This session state field is set by the SCCDetermineExternalSessionTracking feature, based on the presence of a g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag on the INVITE request.

In this phase:

  • The feature will record the media-feature tags present on the initial INVITE.

  • The feature will set the dialog state to PARTIAL_DIALOG.

  • Basic Tracking Data will be updated.

  • Call Setup Data will be updated.

INVITE Response Processing

Execution Point: SipAccess_PartyResponse

This phase is executed when the feature receives a provisional response for the initial INVITE request. On terminating AS instances the leg the response is received on is the access leg, and on originating AS instances the leg the response will be forwarded on is the access leg. The access leg may be forked during this phase, so multiple legs could be tracked in a single session at this time.

In this phase:

  • The feature will record the media-feature tags present on the response if the AS is a terminating instance.

  • The feature will set the dialog state to PRE_ALERTING or ALERTING based on whether a 180 Ringing response has been received.

  • Basic Tracking Data will be updated.

  • Call Setup Data will be updated.

ACK Processing

Execution Point: SipAccess_PartyRequest

This phase is executed when the feature receives a ACK request for the initial INVITE 2xx response. On originating AS instances the leg the ACK is received on is the access leg, and on terminating AS instances the leg the ACK will be forwarded on is the access leg. Any forked access legs will have ended by the time this message is received, so there will only be one access leg in this phase. The ExternalSessionTracking feature will have automatically cleaned up tracked data for these forks.

In this phase:

  • The feature will record the last active time for the call as now.

  • The feature will set the dialog state to HELD (very unlikely) or ACTIVE based on the hold status of the call.

  • Basic Tracking Data will be updated.

  • Call Setup Data will be updated.

  • Media State Data will be updated.

Mid-Session Message Processing

Execution Points: SipMidSession_PartyRequest and SipMidSession_PartyResponse

This phase is executed on receipt of any message after call setup that results in a change to the hold status of the call. The access leg is determined by looking up its name from the CurrentLocalLegName session state field.

In this phase:

  • The feature will set the dialog state to HELD or ACTIVE based on the hold status of the call.

  • Basic Tracking Data will be updated.

  • Media State Data will be updated.

Previous page Next page
Sentinel VoLTE Version 4.1