11.1.8 Private call transfer

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

11.1.8.1 General

In the procedures of clause 11.1.8:

– the term "requesting MCPTT user" is used to refer to the MCPTT user who sent a request to initiate a private call transfer;

– the term "transferred MCPTT user" is used to refer to the MCPTT user who is being transferred to the new target MCPPT user; and

– the term "target MCPTT user" is used to refer to the MCPTT user that is the new target of the private call.

11.1.8.2 Client procedures

11.1.8.2.1 Private call transfer request procedures

Upon receiving a request from an MCPTT user to transfer an ongoing MCPTT private call to a target MCPTT user, the MCPTT client:

1) if:

a) the <allow-call-transfer> element of the <ruleset> element is not present in the requesting MCPTT user’s MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false";

then:

a) should indicate to the requesting MCPTT user that the requesting MCPTT user is not authorised to initiate a private call transfer request; and

b) shall skip the rest of the steps of the present clause;

2) if the request from the MCPTT user is for an announced transfer of an ongoing MCPTT private call to a target MCPTT user, shall follow the procedure of clause 11.1.8.2.3;

3) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] with the following clarifications:

a) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Preferred-Service header field according to IETF RFC 6050 [9] in the SIP MESSAGE request;

b) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

c) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [4];

d) shall include an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element containing:

i) the <mcptt-called-party-id> element set to MCPTT ID of the target MCPTT user; and

ii) an <anyExt> element containing:

A) the <request-type> element set to a value of "transfer-private-call-request"; and

B) if the call is requested to be transferred to a functional alias and the MCPTT client is aware of active functional aliases, then the <call-to-functional-alias-ind> element set to "true"; otherwise, the <call-to-functional-alias-ind> element set to "false";

iii) if the request from the MCPTT user is for an announced transfer, and the incoming SIP INVITE request contained a Supported header field containing an option tag "replaces", and, if present, the <replaces-header-value> element set to content copied from the call to the target MCPTT user provided in step 2;

NOTE: For a call transfer to a MCPTT ID the value is the MCPTT ID of the target user, while for call transfer to a functional alias the value is the functional alias of the target user.

e) shall insert in the SIP MESSAGE request an application/resource-lists+xml MIME body with the MCPTT ID of the transferred MCPTT user, according to rules and procedures of IETF RFC 5366 [20]; and

f) shall set the Request-URI to the public service identity identifying the participating MCPTT function serving the MCPTT user; and

4) shall send the SIP MESSAGE request towards the MCPTT server according to rules and procedures of 3GPP TS 24.229 [4].

Upon receipt of a SIP 4xx, 5xx or 6xx response to the SIP MESSAGE request, should indicate to the requesting MCPTT user the failure of the sent private call transfer request and skip the rest of the steps.

Upon receiving a "SIP MESSAGE request for transfer private call response for terminating client", the MCPTT client:

1) shall determine the success or failure of the sent transfer private call request from the value of the <transfer-call-outcome> element contained in the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element of the application/vnd.3gpp.mcptt-info+xml MIME body included in the received SIP MESSAGE request and generate and send a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [4];

2) if the outcome of the private call transfer is a success, the MCPTT client shall invoke the procedures of clause 11.1.3.1 to end the MCPTT private call with the transferred MCPTT user; and

3) should indicate to the requesting MCPTT user the success or failure of the sent private call transfer request.

11.1.8.2.2 Client procedures for handling incoming private call transfer request

Upon receiving a "SIP MESSAGE request for transfer private call request for terminating client", the MCPTT client:

1) should indicate to the transferred MCPTT user that a request to transfer the previously ongoing call to a new target MCPTT user has been received;

2) shall extract the MCPTT ID of the target MCPTT user from the <mcptt-called-party-id> element contained in the <mcptt-Params> element of the <mcpttinfo> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP MESSAGE request;

3) if present in the received SIP MESSAGE request, shall extract the content of the <replaces-header-value> element contained in the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP MESSAGE request;

4) if according to local policy on-demand sessions are to be used for transfer of private calls, shall invoke the procedures of clause 11.1.1.2.1.1 to originate an MCPTT private call to the target MCPTT user; and

5) if according to local policy pre-established sessions are to be used for transfer of private calls and a pre-established session is available, shall invoke the procedures of clause 11.1.1.2.2.1 to originate an MCPTT private call to the target MCPTT user;

Upon completion of the procedures of clause 11.1.1.2.1.1 or clause 11.1.1.2.2.1, the MCPTT client:

1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] with the following clarifications:

c) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [4];

d) shall include in a "uri" attribute of <entry> element of a <list> element of the <resource-lists> element of an application/resource-lists+xml MIME body the MCPTT ID contained in the <mcptt-calling-user-id> element in the application/ vnd.3gpp.mcptt-info+xml MIME body of the received SIP MESSAGE request; and

e) shall include an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element containing:

i) the <mcptt-called-party-id> set to the MCPTT ID of the target MCPTT user called by the transferred MCPTT user; and

ii) an <anyExt> element containing:

A) the <response-type> element set to a value of "transfer-private-call-response";

B) if the procedures of clause 11.1.1.2.1.1 or clause 11.1.1.2.2.1 were successful in originating an MCPTT private call to the identified MCPTT user, a <transfer-call-outcome> element set to a value of "success"; and

C) if the procedures of clause 11.1.1.2.1.1 or clause 11.1.1.2.2.1 were not successful in originating an MCPTT private call to the identified MCPTT user, a <transfer-call-outcome> element set to a value of "fail";

2) shall set the Request-URI to the public service identity identifying the participating MCPTT function serving the transferred MCPTT user; and

3) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [4].

11.1.8.2.3 Announced private call transfer

When the MCPTT user requests an announced private call transfer of an ongoing private MCPTT call, the MCPTT client:

1) shall put the ongoing MCPTT private call with the transferred MCPTT user on hold following the procedures as described in RFC 5359, clause 2.1.

2) shall initiate an on-demand private call as specified in clause 11.1.1.2.1, or a private call using pre-established session as specified in clause 11.1.1.2.2 to the target MCPTT user with the following clarification:

a) shall include an <transfer-announced-ind> element contained in the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body;

2a) if present in the the 200 (OK) response received for the MCPTT call in step 2, shall copy content of the <replaces-header-value> element contained in the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body;

3) once the call to the target MCPPT user is established, the MCPTT client should notify the requesting MCPTT user to announce the call transfer to the target MCPTT user;

4) if no <replaces-header-value> element was received in the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body of the 200 (OK) response message in step 2a,;shall terminate the MCPTT private call with the target user as specified in clause 11.1.3; and

5) should offer the MCPTT user the option to retrieve the ongoing call with the transferred MCPTT user, to announce the transfer to the calling MCPTT user.

11.1.8.3 Participating MCPTT function procedures

11.1.8.3.1 Originating procedures

Upon receiving a "SIP MESSAGE request for transfer private call for originating participating MCPTT function" the participating MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24] and skip the rest of the steps;

2) shall determine the MCPTT ID of the calling user from the public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request;

NOTE 1: The MCPTT ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.

3) if the participating MCPTT function cannot find a binding between the public user identity and an MCPTT ID or if the validity period of an existing binding has expired, then the participating MCPTT function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

4) if:

a) the "SIP MESSAGE request for transfer private call for originating participating MCPTT function" contains the <request-type> element set to a value of "transfer-private-call-request"; and

b) if the <allow-call-transfer> element of the <ruleset> element is not present in the requesting MCPTT user’s MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false";

then:

a) shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "170 user not authorised to make a private call transfer request" in a Warning header field as specified in clause 4.4, and skip the rest of the steps;

5) if the "SIP MESSAGE request for transfer private call for originating participating MCPTT function" contains the <request-type> element set to a value of "transfer-private-call-request" and:

a) if the <allow-call-transfer-to-any-user> element of the <ruleset> element is not present in the requesting MCPTT user’s MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false"; or

b) if the call is transferred to an MCPTT ID and none of the "uri" attributes of all the <entry> elements of all <list> elements of the <resource-lists> element of the application/resource-lists+xml MIME body matches with the "uri" attribute of one of the <entry> elements of the <AllowedMCPTTIdsForCallTransfer> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); or

c) if the call is transferred to functional alias and none of the "uri" attributes of all the <entry> elements of all <list> elements of the <resource-lists> element of the application/resource-lists+xml MIME body matches with the "uri" attribute of one of the <entry> elements of the <AllowedFunctionalAliasesForCallTransfer> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]);

then:

a) shall reject the "SIP MESSAGE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "170 user not authorised to make a private call transfer request" in a Warning header field as specified in clause 4.4 and shall skip the rest of the steps;

6) shall determine the public service identity of the controlling MCPTT function for the private call transfer service for the requesting MCPTT user;

NOTE 2: The public service identity can identify the controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 3: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 4: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 5: How the participating MCPTT function determines the public service identity of the controlling MCPTT function associated with the private call transfer service for the requesting MCPTT user or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 6: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

7) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

8) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCPTT function determined in step 6);

9) shall copy the contents of the application/vnd.3gpp. mcptt-info+xml MIME body in the received SIP MESSAGE request into an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 included in the outgoing SIP MESSAGE request;

10) shall set the <mcptt-calling-user-id> contained in <mcptt-Params> element of the application/vnd.3gpp.mcptt-info+xml MIME body to the MCPTT ID determined in step 2) above;

11) shall copy the contents of the application/resource-lists+xml MIME body in the received SIP MESSAGE request into an application/resource-lists+xml MIME body in the outgoing SIP MESSAGE request;

12) shall set the P-Asserted-Identity in the outgoing SIP MESSAGE request to the public user identity in the P-Asserted-Identity header field contained in the received SIP MESSAGE request;

13) shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

14) shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

15) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), into the P-Asserted-Service header field of the outgoing SIP MESSAGE request; and

16) shall send the SIP MESSAGE request as specified to 3GPP TS 24.229 [4].

Upon receipt of a SIP 2xx response in response to the SIP MESSAGE request sent in step 16), the participating MCPTT function shall generate a SIP 200 (OK) response and forward the SIP 200 (OK) response to the MCPTT client and

Upon receipt of a SIP 4xx, 5xx or 6xx response to the SIP MESSAGE request, shall forward the error response to the MCPTT client.

11.1.8.3.2 Terminating procedures

Upon receiving a

– "SIP MESSAGE request for transfer private call request for terminating participating MCPTT function"; or

– "SIP MESSAGE request for transfer private call response for terminating participating MCPTT function";

the participating MCPTT function:

2) shall use the MCPTT ID present in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP MESSAGE request to retrieve the binding between the MCPTT ID and public user identity;

3) if the binding between the MCPTT ID and public user identity does not exist, then the participating MCPTT function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response and skip the rest of the steps;

4) shall generate an outgoing SIP MESSAGE request as specified in clause 6.3.2.2.11;

5) if the "SIP MESSAGE request for transfer private call for originating participating MCPTT function" contains the <request-type> element set to a value of "transfer-private-call-request"

a) shall extract the MCPTT ID of the target MCPTT user from the <mcptt-called-party-id> element contained in the <mcptt-Params> element of the <mcpttinfo> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP MESSAGE request;

b) shall cache the mapping of the MCPTT ID used in step 2) and target MCPTT ID extracted in step a);

NOTE 1: If multiple private calls transfers are in progress at the same time for the same user, multiple mappings have to be stored.

6) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), into the P-Asserted-Service header field of the outgoing SIP MESSAGE request; and

7) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

11.1.8.4 Controlling MCPTT function procedures

Upon receiving a:

– "SIP MESSAGE request for transfer private call request for controlling MCPTT function"; or

– "SIP MESSAGE request for transfer private call response for controlling MCPTT function";

the controlling MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The controlling MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24] and skip the rest of the steps;

2) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt";

3) if the incoming SIP MESSAGE request does not contain an application/resource-lists+xml MIME body or contains an application/resource-lists+xml MIME body with a total of more than one <entry> element in all <list> elements of the <resource-lists> element, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall skip the rest of the steps;

4) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

5) shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

6) shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

7) shall copy the contents of the application/vnd.3gpp. mcptt-info+xml MIME body in the received SIP MESSAGE request into an application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP MESSAGE request;

8) if the incoming SIP MESSAGE request contains in the application/vnd.3gpp. mcptt-info+xml MIME body <call-to-functional-alias-ind> set to "true" shall identify the MCPTT ID(s) of the MCPTT user(s) that have activated the received functional alias by performing the actions specified in clause 9A.2.2.2.8:

a) if the functional alias is not activated by any MCPTT user, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall skip the rest of the steps;

b) if the functional alias is activated by one MCPTT user, shall use the MCPTT ID of that user as new target MCPTT ID;

c) if the functional alias is simultaneously activated by multiple MCPTT users, shall select an appropriate MCPTT ID based on local policy. The selection of an appropriate MCPTT ID is left to implementation. The outcome of the selection includes rejection. Upon completion of the selection process,:

i) if the controlling MCPTT function was unable to select an MCPTT ID, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall skip the rest of the steps; or

ii) if the selection process concluded by selecting an appropriate MCPTT ID, this MCPTT ID shall be used as new target MCPTT ID;

d) shall copy the new target MCPTT ID into the <mcptt-called-user-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the outgoing SIP MESSAGE request.

e) shall set <call-to-functional-alias-ind> to "false" in the application/vnd.3gpp. mcptt-info+xml MIME body of the outgoing SIP message;

9) shall copy the MCPTT ID of the MCPTT user listed in the MIME resources body of the incoming SIP MESSAGE request, into the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the outgoing SIP MESSAGE request;

10) shall set the Request-URI to the public service identity of the terminating participating MCPTT function associated to the MCPTT user identified by the MCPTT ID contained in the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the outgoing SIP MESSAGE request;

NOTE 1: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 2: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 3: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 4: How the controlling MCPTT function determines the public service identity of the terminating participating MCPTT function associated with the targeted MCPTT user or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 5: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

11) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcptt";

12) shall copy the public user identity of the calling MCPTT user from the P-Asserted-Identity header field of the incoming SIP MESSAGE request into the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

13) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [4].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the controlling MCPTT function shall generate a SIP 200 (OK) response and forward the SIP 200 (OK) response to the originating participating MCPTT function.

Upon receipt of a SIP 4xx, 5xx or 6xx response to the SIP MESSAGE request, controlling MCPTT function shall forward the error response to the originating participating MCPTT function.