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 | SAS Support | Originating / Terminating | Point(s) in Session Plan | Network Operator Data | Subscriber Data | Stateful or Stateless | POJO Feature or SBB Feature | Other notes |
|---|---|---|---|---|---|---|---|---|
MMTel |
No |
Originating and/or Terminating |
|
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 IF NOT EXISTS 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 IF NOT EXISTS 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 IF NOT EXISTS 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)
)
WITH gc_grace_seconds = 172800; // 2 daysSession Input Variables
| Variable Name | Type | Comments |
|---|---|---|
Complex |
Read from the HSS in SubscriberDataLookupFromHSS |
|
TransfereeLegName |
String |
The |
TransferorLegName |
String |
The |
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 |
TransfereeCallID |
String |
The |
TransfereeFromTag |
String |
The |
TransfereeToTag |
String |
The |
ExpiresTime |
int |
The time indicated in the |
TransferTargetUri |
String |
The URI found in the |
TransfereeUri |
String |
The URI found in the |
TransferorReferSequenceNumber |
long |
The sequence number found in the |
ReleasedTransferorLeg |
boolean |
True if the Transferor’s |
NoSubscriptionForRefer |
boolean |
True if the REFER request contains the |
NoAnswerTimerId |
TimerID |
The ID of the Timer used to guard against unanswered requests. |
Session Output Variables
| Variable name | Type | Comments |
|---|---|---|
TransfereeLegName |
String |
The |
TransferorLegName |
String |
The |
TransferorReferSequenceNumber |
long |
The sequence number found in the |
TransfereeUri |
String |
The URI found in the |
NoSubscriptionForRefer |
boolean |
True if the REFER request contains the |
TransfereeCallID |
String |
The |
TransfereeFromTag |
String |
The |
TransfereeToTag |
String |
The |
TransferorIdentity |
String |
The ID of the Transferor as found in the |
ExpiresTime |
int |
The time indicated in the |
TransferTargetUri |
String |
The URI found in the |
EctSessionId |
String |
The unique ID of the ECT session. |
ReleasedTransferorLeg |
boolean |
True if the Transferor’s |
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/3.1.0;3.1.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 … |
|---|---|
Started |
each time the feature runs |
FailedDuringExecution |
a fatal error occurs while the feature is executing |
FailedToStart |
Sentinel VoLTE encounters an error while attempting to start the feature. |
IssuedWarning |
a non-fatal problem is encountered and the feature issues a warning. |
TimedOut |
the feature takes too long to complete and Sentinel VoLTE aborts execution. |
ReferReceivedFromServedUser |
a REFER request has been received from the served user |
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. |
Scope
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 |
|---|---|---|---|
|
integer |
|
Determines how long ECT session information should remain in the Cassandra DB before being cleared. |
|
boolean |
|
Determines if a transferor is authorized for ECT if no provisioning information is available. |
|
String |
|
The address of the Interrogating-CSCF, initially set by the installer. |
|
boolean |
|
Determines if an |
|
boolean |
|
Determines if an |
|
String |
|
Determines the prefix appended to generated URIs to identify them as relating to ECT session identifiers. |
|
integer |
|
Milliseconds to wait for a response to a request sent by this feature. |
Session Input Variables
Variable Name |
Type |
Comments |
Complex |
Read from the HSS in SubscriberDataLookupFromHSS |
