The Explicit Communication Transfer (ECT) service enables a party involved in a communication to transfer their role in that communication to a third party .

For a general overview of the service see Explicit Communication Transfer.

Consultative ECT using the 3pcc procedure does not support reusing the existing leg between the AS and the transfer-target, instead a new leg is created to link to the transferee.

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

MMTel

Originating and/or Terminating

  • MMTelOrig_SubscriptionSipRequest

  • MMTelTerm_SubscriptionSipRequest

  • MMTelOrig_SubscriptionSipResponse

  • MMTelTerm_SubscriptionSipResponse

  • MMTelOrig_SipAccess_SubscriberCheck

  • MMTelTerm_SipAccess_SubscriberCheck

  • MMTelOrig_SipAccess_PartyRequest

  • MMTelTerm_SipAccess_PartyRequest

  • MMTelOrig_SipAccess_PartyResponse

  • MMTelTerm_SipAccess_PartyResponse

  • MMTelOrig_SipMidSession_PartyRequest

  • MMTelTerm_SipMidSession_PartyRequest

  • MMTelOrig_SipMidSession_PartyResponse

  • MMTelTerm_SipMidSession_PartyResponse

  • MMTelOrig_SipAccess_ServiceTimer

  • MMTelTerm_SipAccess_ServiceTimer

Yes

Yes — Transferor authorization is stored in the HSS

Stateful

POJO

Implications on Charging for transferred communications

Cassandra storage

The ECT feature utilises the Cassandra database to store session information for transfers

Data Schema

The Cassandra table for ECT exists in a keyspace named opencloud_mmtel_ect

  • For a production environment, the keyspace can be created such that it is replicated. A sample command for creating this keyspace is:

CREATE KEYSPACE opencloud_mmtel_ect WITH REPLICATION={'class' : 'SimpleStrategy' ,'replication_factor' : 3 };

  • For testing purposes, replication may not be necessary. A sample CQL command for creating such a keyspace is:

CREATE KEYSPACE opencloud_mmtel_ect WITH REPLICATION={'class' : 'SimpleStrategy', 'replication_factor' : 1};

Once the keyspace is created, the required table can be created. The following CQL statements provides the structure of the required table.

USE opencloud_mmtel_ect;

CREATE TABLE ExplicitCommunicationTransfer (
ect_id text,                           // The generated ECT identifier
target_uri text,                       // URI of the transfer target
transferor_p_asserted_id text,         // P-Asserted-Identity of transferor
transfer_timeout int,                  // Value of REFER request's Expired header
PRIMARY KEY (ect_id)
);

Session Input Variables

Variable Name Type Comments 
MMTelECTServiceData

Complex

Read from the HSS in SubscriberDataLookupFromHSS

 
TransfereeLegName

String

The LegManager leg-name of the Transferee.

 
TransferorLegName

String

The LegManager leg-name of the Transferor.

 
ReferNotAllowedByTransferee

boolean

True if the Transferee is not allowed to send a REFER request.

 
EctSessionId

String

The unique ID of the ECT session.

 
TransferorIdentity

String

The ID of the Transferor as found in the P-Asserted-Identity header of his/her REFER request.

 
TransfereeCallID

String

The CallId of the Transferee’s dialogue.

 
TransfereeFromTag

String

The From tag of the Transferee’s dialogue.

 
TransfereeToTag

String

The To tag of the Transferee’s dialogue.

 
ExpiresTime

int

The time indicated in the Expires header of the REFER request.

 
TransferTargetUri

String

The URI found in the From header’s Address part of the Transfer Target’s dialogue.

 
TransfereeUri

String

The URI found in the From header’s Address part of the Transferee’s dialogue.

 
TransferorReferSequenceNumber

long

The sequence number found in the CSeq header of the Transferor’s REFER request.

 
ReleasedTransferorLeg

boolean

True if the Transferor’s LegManager leg has been released.

 
NoSubscriptionForRefer

boolean

True if the REFER request contains the ReferSub=false header/value.

 
NoAnswerTimerId

TimerID

The ID of the Timer used to guard against unanswered requests.

Session Output Variables

Variable name Type Comments 
TransfereeLegName

String

The LegManager leg-name of the Transferee.

 
TransferorLegName

String

The LegManager leg-name of the Transferor.

 
TransferorReferSequenceNumber

long

The sequence number found in the CSeq header of the Transferor’s REFER request.

 
TransfereeUri

String

The URI found in the From header’s Address part of the Transferee’s dialogue.

 
NoSubscriptionForRefer

boolean

True if the REFER request contains the ReferSub=false header/value.

 
TransfereeCallID

String

The CallId of the Transferee’s dialogue.

 
TransfereeFromTag

String

The From tag of the Transferee’s dialogue.

 
TransfereeToTag

String

The To tag of the Transferee’s dialogue.

 
TransferorIdentity

String

The ID of the Transferor as found in the P-Asserted-Identity header of his/her REFER request.

 
ExpiresTime

int

The time indicated in the Expires header of the REFER request.

 
TransferTargetUri

String

The URI found in the From header’s Address part of the Transfer Target’s dialogue.

 
EctSessionId

String

The unique ID of the ECT session.

 
ReleasedTransferorLeg

boolean

True if the Transferor’s LegManager leg has been released.

 
NoAnswerTimerId

TimerID

The ID of the Timer used to guard against unanswered requests.

 
RanEct

boolean

True if the ECT feature was invoked.

 
ThirdPartyCallInitialisationRequested

boolean

True if Third-Party Call Control (3PCC) was invoked.

 
ECTOngoing

boolean

True if an ECT operation is still ongoing.

Behaviour

The ECT feature acts on INVITE, REFER, and NOTIFY requests and their responses. It also acts on service timers.

REFER Path

The feature creates an identifier for the transfer session by concatenating the prefix configured in Network Operator Data along with the from-tag, call-id, and to-tag of the REFER request. It then extracts the URI of the transfer-target from the Refer-To header, the P-Asserted-Identity and the value of the Expires header field. This information is stored in the database against the generated ID to be used when the transferee sends an INVITE request to the generated URI.

The feature then manipulates the outgoing REFER request by replacing the Refer-To header address with the generated URI and sets the Referred-By header to the P-Asserted-Identity in the request.

If ID privacy was requested the feature then adds a Privacy header with priv-value 'user'.

INVITE Path

The feature checks if the Request URI of the INVITE request could have been generated by the REFER handling behaviour of the ECT feature and if so attempts to query the database for the ECT session information. If no record can be found in the database table matching the Request URI the request is forwarded to the recipient without modification. If a record is found, the feature replaces the Request-URI of the downstream INVITE request with the URI of the transfer target.

If the retrieved Request-URI contains a 'Replaces' parameter the feature adds a 'Replaces' header with the same value to the INVITE request. If the Request-URI contains a Require header field parameter with a 'Replaces' token the feature adds a Require header field parameter with a 'Replaces' token to the INVITE request. If the downstream INVITE message does not contain a Referred-By header containing the transferor’s P-Asserted-Identity then the feature adds one.

NOTIFY Path

If the feature is triggered by a NOTIFY, and that NOTIFY is for a SIP 400 (Bad Request), the feature will invoke the 3PCC procedures. Otherwise, the NOTIFY is not acted upon.

Third Party Call Control

Scenarios

Under certain conditions where the standard signalling flow is impossible the feature invokes the Third Party Call Control (3pcc) procedures. These conditions are described in the following tables.

Terminating party sends a REFER request
Content of the Allow header in the initial INVITE request Actions of the feature on the REFER request Actions of the feature on the initial INVITE request

INVITE request with an Allow header with no REFER token

Invoke the 3pcc procedures directly

Add a REFER token to the allow header

INVITE request with an Allow header including a REFER token

Forward the REFER request and if a 403 (Forbidden) or 501 (Not Implemented) response is received invoke the 3pcc procedure

No actions

INVITE request without an Allow header

Forward the REFER request and if a 403 (Forbidden) or 501 (Not Implemented) response is received invoke the 3pcc procedure

No actions
Originating party sends a REFER request
Content of the Allow header in the 200 (OK) response to the initial INVITE request Actions of the feature on the REFER request Actions of the feature on the 200 (OK) response to the initial INVITE request

200 (OK) response with an Allow header with no REFER token

Invoke the 3pcc procedures directly

Add a REFER token to the allow header

200 (OK) response with an Allow header including a REFER token

Forward the REFER request and if a 403 (Forbidden) or 501 (Not Implemented) response is received invoke the 3pcc procedure

No actions

200 (OK) response without an Allow header

Forward the REFER request and if a 403 (Forbidden) or 501 (Not Implemented) response is received invoke the 3pcc procedure

No actions

Procedure

If the 3pcc procedures were triggered by a REFER request or a 403 (Forbidden) or 501 (Not Implemented) response the feature intercepts the message before it is forwarded to the recipient and instead responds to the REFER request by sending a 202 (Accepted). It then creates and sends a hold reINVITE request according to the procedures specified in 3GPP TS 24.610 subclause 4.5.2.1.

If however the 3pcc procedures were triggered by a NOTIFY request with a 420 (Bad Extension) status line the feature responds to the NOTIFY request with a 200 (OK) message and removes the message from the outgoing queue before sending the hold request.

Upon receipt of a success response to the hold request the feature then creates a new INVITE request to the transfer-target, and places this on the outgoing message queue of a new leg. The feature then creates a re-INVITE request to the transferee. If the Refer-To URI in the REFER request contained an Expires header, the feature starts a service timer set to its value. It then creates the re-INVITE request with same Call-ID, from-tag and to-tag as the existing dialogue between the transferee and the transferor, but replaces the address field of the From header with the address of the transfer-target. The feature then places the re-INVITE request on the outgoing message queue of the leg to the transferee and unlinks this leg from the leg to the transferor. MMTelECT then handles the call setup and SDP negotiation between the transferee and transfer-target.

MMTelECT continues to monitor the legs to the transferee and the transfer-target. When the INVITE to the transfer-target is acknowledged with a 200 (OK) response the feature sends a NOTIFY request with a 100 (trying) status line on the original leg to the transferor and when the re-INVITE to the transferee is acknowledged with a 200 (OK) the feature sends a NOTIFY request with a 200 (OK) status line towards the transferor and releases the leg.

If the Expires Service Timer fires before the transfer-target responds the feature sends a CANCEL and closes the partial dialogue to the transfer-target, then sends a NOTIFY request to the transferor with Subscription-State terminated and relinks the transferor and transferee legs resuming their original dialogue.

If the transfer-target responds to the INVITE request with a failure status code, the feature sends a NOTIFY request to the transferor with the Subcription-State header set to terminated and resumes the original dialogue between the transferor and transferee.

The transferor can request to not receive NOTIFY messages regarding the transfer progress by including a Refer-Sub header with value 'false' in the REFER request. The transferor can also release its leg at any time during the transfer attempt, in which case the feature will release the leg to the transferee and end the call in the event of a transfer failure.

Response Timer

The platform operator can configure a response timer for the feature which will trigger if the feature did not receive a response to a previously sent request within the configured period.

Scenarios where the response timer may be triggered:

  • The transferee did not respond to a REFER request — Respond to the REFER request with a 603 (Decline) and send a REFER request with a cancel URI parameter in the Refer-To address

  • The transfer-target did not respond to the INVITE request when executing 3pcc procedures — Release the newly-created leg to the transfer-target and attempt to resume the dialogue between the transferor and transferee. If the transferor has left the call release the leg to the transferee.

Source Code

This feature’s source code is available in the Sentinel VoLTE SDK in the mmtel-explicit-communication-transfer module pack. It can be viewed by using the create-module command in the SDK with that module pack, for example:

> create-module new-ect-module opencloud#mmtel-explicit-communication-transfer#volte/2.7.0;2.7.0.0

This command will prompt you for information needed to create the new modules, once completed the original source for the feature can be found in the new modules.

The module-pack includes the following modules:

Module Name Description

mmtel-explicit-communication-transfer

Group module for the feature that includes all of the modules listed below.

mmtel-ect-feature

The feature itself.

mmtel-ect-profile

The profile for this feature.

Statistics

Name Increments when …​

ReferReceivedFromServedUser

a REFER request has been received from the served user

ReferDeclined

the feature has sent responded to a REFER request with 603 (Decline)

ReferSuccessful

the transferee has responded to a processed REFER request with a 202 Accepted)

ReferProcessedAndForwarded

a REFER request has been received from the transferor, appropriately modified and sent to the transferee

EctInviteReceived

an INVITE request has been received from the transferor as a result of a previous REFER request

EctInviteProcessedAndForwarded

an ECT INVITE request has been received by the transferee, appropriately modified and sent to the transfer-target

ThirdPartyCallControlProceduresInvoked

the Third Party Call Control (3pcc) transfer procedures have been invoked

ThirdPartyCallControlProceduresFailed

the Third Party Call Control (3pcc) transfer procedures did not result in a successful dialogue between the transferee and transfer-target

OriginalCallResumed

the original dialogue between the transferee and the transferor has been resumed if the 3pcc procedures failed

CassandraInsertSucceeded

ECT session information has been successfully inserted into the Cassandra DB

CassandraInsertFailed

an error occurred attempting to insert ECT session information into the Cassandra DB

CassandraQuerySucceeded

ECT session information has been successfully retrieved from the Cassandra DB

CassandraQueryFailed

an error occurred attempting to retrieve ECT session information from the Cassandra DB

DeletedCassandraRow

REFER request was cancelled by user, and so the Cassandra ECT record was deleted.

StoppedHandlingAndAllowedB2BUA

an INVITE request with a Request URI matching the ECT URI pattern was received and forwarded without modification

TransferSuccessful

a 200 (OK) was received from the transfer-target as a result of the ECT procedures

ErrorOccurredDuringExecution

an error occurred attempting to execute the feature

NoAnswerTimerFired

The feature timed-out waiting for an answer from a sent request.

Specification References

3GPP TS 24.629 Version 12.7

Scope

In Scope

  • Blind and consultative communication transfer

  • Blind and consultative communication transfer using 3pcc

Out of Scope

  • Consultative ECT using the 3pcc procedure does not support reusing the existing leg between the AS and the transfer-target, instead a new leg is created to link to the transferee

  • The feature does not play an announcement to the transferor when initiating the transfer attempt

Network Operator Data

Network configuration is stored in the JSLEE profile table named MMTelECTConfigProfileTable.

The data is scoped on Sentinel Selection Key. The fields present in the JSLEE profile table are used to configure the behaviour of the Explicit Communication Transfer feature.

Parameter Type Default Value Description

TimeToLive

integer

60

Determines how long ECT session information should remain in the Cassandra DB before being cleared.

AuthorizedByDefault

boolean

true

Determines if a transferor is authorized for ECT if no provisioning information is available.

ICSCFURI

String

null

The address of the Interrogating-CSCF.

AddOrigParameter

boolean

true

Determines if an orig parameter should be added to the Route header field when creating new INVITE requests.

UseLRParameter

boolean

true

Determines if an lr parameter should be added to the address parameter of the Route header field when creating new INVITE requests.

EctPrefix

String

"ect-"

Determines the prefix appended to generated URIs to identify them as relating to ECT session identifiers.

ResponseTimeout

integer

2000

Milliseconds to wait for a response to a request sent by this feature.

Session Input Variables

Variable Name Type Comments 
MMTelECTServiceData

Complex

Service data read from the HSS

Example Call Flows

Note Various IMS core elements and some SIP messages are omitted from the call flow diagrams for the sake of clarity.

Blind ECT

blind-ect

Consultative ECT

consultive-ect

3pcc procedure for Blind ECT after receiving a 501 (Not Implemented) response from a REFER

blind3pcc

Previous page Next page
Sentinel VoLTE Version 2.7.0