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

For an architectural view of co-ordinating signalling anchors refer to Shared ATU-STI.

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

SipAccess_SessionStart, SipTransaction_Start

Yes

None

Stateless

Feature SBB

Looks up an AC Name and fires an event

Prerequisite features

SCCDetermineSessionType must run before this feature.

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

Network operator data

Network operator data for SCCSendRequestToAnchor is stored in a profile table named SCCSendRequestToAnchorConfigProfileTable.

The data is scoped according to a Sentinel selection key.

SRTAAttemptWithReversedTags attribute

This is of type Boolean.

If true, the feature will reverse the remote and local tags when attempting to lookup a SIP session using its dialog ID.

Defaults for network operator data

Attribute Name Default Value 
AttemptWithReversedTags
 
false

Subscriber data

None

Session input and output variables

Session input variables

Variable Type Description

AccessTransferType

Enum

Determines aspects of how a request is handled by the feature.

SentinelSelectionKey

SentinelSelectionKey

Used to load configuration data.

AccessTransferIsLocal

boolean

Determines if the feature should deliver to a session on the same node or proxy to another node in the cluster

SessionToTransfer

TrackedSession (POJO)

The session to transfer, as provided by the DetermineTransferableSetFeature

Session output variables

None

Statistics

SCCSendRequestToAnchor statistics are tracked by the scc-send-request-to-anchor-sbb SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.volte.sip service → scc-send-request-to-anchor-sbb
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.volte.sip,vendor=OpenCloud,version=4.1].SbbID[name=scc-send-request-to-anchor,vendor=OpenCloud,version=4.1]"

Name Description 
Invoked

Incremented each time the feature runs

 
Error

Incremented when a fatal error occurs during feature execution

 
TerminatedSessionWith480

Incremented when the feature rejects an access transfer request with a 480 response

 
SentInviteRequest

Incremented when the feature sends an access transfer INVITE to the signalling anchor instance

 
SentMessageRequest

Incremented when the feature sends an access transfer MESSAGE to the signalling anchor instance

 
InviteSessionMismatched

Incremented when the dialog-ID from the access transfer request does not match the session to transfer in session state

Behaviour

On starting, the feature will check the method of the triggering SIP Request and read the session input attribute AccessTransferType.

If the request method is INVITE, and the AccessTransferType has the value eSRVCC_Anchored, eSRVCC_Not_Anchored or SRVCC the feature will execute the behaviour described in Handling of Access Transfer Request.

If the request method is MESSAGE, and the AccessTransferType has the value Internal_Directive the feature will execute the behaviour described in Handling of Access Transfer Request - Local.

Otherwise the feature finishes execution without modifying any state.

Handling of Access Transfer Request

If the session variable AccessTransferIsLocal is set to true the feature will execute the behaviour described in Handling of Access Transfer Request - Local. Otherwise the behaviour described in Handling of Access Transfer Request - Remote will be executed.

Handling of Access Transfer Request - Local

The feature will examine certain headers in the incoming request to determine a Activity Context Name that can be used to find the session that the request is targeted at. Which headers that are considered depend on the method of the request.

  • For INVITE requests, the feature will check the Target-Dialog header first, if one is not found the Replaces header will also be checked.

  • For MESSAGE requests, only the Target-Dialog header is considered.

If no appropriate header is present, the feature rejects the incoming request with a 480 Temporarily Unavailable error response and complete execution.

The feature will use the header to create a normalised lookup string as described in Creation of Activity Context Naming lookup string. This string is used to look up an Activity Context from the Activity Context Naming Facility.

If the naming lookup indicates that there was no Activity Context bound to the name the feature will reject the incoming request with a 480 Temporarily Unavailable error response and complete execution.

If the naming lookup returns an Activity Context the feature:

  • fires the INVITE or MESSAGE request event on the returned activity context;

  • removes the AC name binding (unbinds the ACName that was just looked up);

  • instructs the Sentinel core that this Sentinel instance shall finish; and in doing so, shall not modify any SIP signaling on the dialog.

Handling of Access Transfer Request - Remote

The feature:

  • adds an OC-Access-Transfer-Procedure header with the value of the AccessTransferType variable,

  • removes the topmost route header from the request so the local node is removed from the call path, and

  • forwards the request to the URI stored in the SessionToTransfer.

If forwarding the request fails because the target node is no longer a member of the cluster, the feature will fall back to the procedure described in bxref:#handling-of-access-transfer-request-local.

Creation of Activity Context Naming lookup string

The feature creates a normalised string from the Target-Dialog or Replaces header using four values:

  • the Call-ID value

  • the remote-tag parameter value (or from-tag in Replaces)

  • the local-tag parameter value (or to-tag in Replaces)

  • and a string to help with readability (the value esr short form for “Enhanced SRVCC”).

It then takes these four values and constructs a lookup key as follows:

  • Call-ID value, followed by a semi-colon

  • r= followed by the value of the remote-tag parameter, and a semi-colon

  • l= followed by the value of the local-tag parameter, and a semi-colon

  • esr;

If the AttemptWithReversedTags configuration option is set to true the values for l= and 'r=' will be swapped.

The following example shows a Target-Dialog header and the normalised form:

  • header is Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321; local-tag=64727891

  • normalised form is me03a0s09a2sdfgjkl491777;r=774321;l=64727891;esr;

  • normalised form with reversed tags is me03a0s09a2sdfgjkl491777;r=64727891;l=774321;esr;

Previous page Next page
Sentinel VoLTE Version 4.1