A.1 Group regrouping flow

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

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

A.1.1 General

This clause describes how a temporary group call as the result of a group regroup operation is established.

A.1.2 Use case description

The police and a private security company cooperate during a fair. A temporary prearranged group is created as specified in TS 24.481 [31] to allow the policemen and security personal to communicate.

The temporary group consists of two groups of policemen and a group of security personal from the private security company. One of the groups of policemen is called in from another town. A dispatcher from the police creates the temporary group. The dispatcher is added to the group of policemen hosted by the controlling MCPTT function A.

Table A.1.2-1 shows the group coding details.

Table A.1.2-1: Group coding details

MCPTT group identity	Hosted by	Group type	MCPTT group members
mcptt-group-A-B@mcptt-op.gov	controlling MCPTT function A	Temporary group	mcptt-group-A1@mcptt-op.gov
			mcptt-group-B@mcptt-city1.net
			mcptt-group-A2@mcptt-op.gov
mcptt-group-A1@mcptt-op.gov	controlling MCPTT function A	Prearranged group	mcptt-id-A2@mcptt-op.gov
mcptt-group-B@mcptt-city1.net	non-controlling MCPTT function B	Prearranged group	mcptt-id-B@mcptt-city1.net
mcptt-group-A2@mcptt-op.gov	non-controlling MCPTT function A	Prearranged group	mcptt-id-A3@mcptt-op.gov

For readability reasons all prearranged groups have only one member. Table A.1.2-1 shows the group member coding details.

Table A.1.2-2: Group member coding details

MCPTT ID of group member	Registered public user identity	MCPTT client name	IP address audio / floor control port number (NOTE 2)
mcptt-id-A1@mcptt-op.gov	sip:userA1@ims-op.net	MCPTT client A1	5555::aaa:bbb:ccc:eee 3456 / 3457
mcptt-id-A2@mcptt-op.gov	sip:userA2@ims-op.net	MCPTT client A2	5555::aaa:ccc:aaa:bbb 26456 / 26457 (NOTE 1)
mcptt-id-A3@mcptt-op.gov	sip:userA3@ims-op.net	MCPTT client A3	5555::bbb:aaa:ccc:aaa 25644 / 25645
mcptt-id-B@mcptt-city1.net	sip:userB@ims-op.net	MCPTT client B	5555::baa:abb:ddd:ccc 62122 / 62122
NOTE 1: A pre-established session is used and the IP address and port numbers of the participating MCPTT function A2 is used. NOTE 2: The IP address is the same as for the registered contact.

Each MCPTT user is served by a different MCPTT function. Table A.1.2-3 shows the Participating MCPTT functions coding details.

Table A.1.2-3: Participating MCPTT functions coding details

Functional entity	Public service identity	IP address audio / floor control port number
participating MCPTT function A1	sip:pf-A1.ims-op.net	5555::aaa:bbb:ccc:eef 7890 / 7891
participating MCPTT function A2	sip:pf-A2.ims-op.net	5555::aaa:ccc:aaa:bbb 26456 / 26457
participating MCPTT function A3	sip:pf-A3.ims-op.net	5555::aaa:ccc:aaa:ccc 18412 / 18413
participating MCPTT function B	sip:pf-B.ims-op.net	5555::aaa:bbb:ccc:eef 16412 / 16413

Each group is hosted by a different MCPTT server. Table A.1.2-4 shows the Controlling and non-controlling MCPTT functions coding details.

Table A.1.2-4: Controlling and non-controlling MCPTT functions coding details

Functional entity	Public service identity	MCPTT session identifier	IP address audio / floor control port number
controlling MCPTT function A	sip:cf-A.ims-op.net	session@cf-A@ims-op.net	5555::aaa:bbb:ddd:aaa 23124 / 23125
non-controlling MCPTT function A	sip:cf-A2.ims-op.net	sessionA@cf-A2@ims-op.net	5555::aaa:bbb:ddd:eee 12344 / 12345
non-controlling MCPTT function B	sip:cf-B.ims-op.net	sessionB@cf-B@ims-op.net	5555::aaa:bbb:ddd:ddd 34456 / 34457

A.1.3 Signalling flow

The temporary group consists of a group A1 (police), group A2 (police in other town) and a group B (security company in a partner system).

For the mcptt-id-B@mcptt-city1.net the controlling MCPTT function is using the connection model in figure 5.3.2-5.

For the mcptt-id-A3@mcptt-op.gov the controlling MCPTT function is using the connection model in figure 5.3.2-2.

Preconditions:

1) the temporary group mcptt-group-A-B is already created and all members are affiliated to the group;

2) this is not an emergency or imminent peril call;

3) MCPTT client A2 has a pre-established session and the MCPTT services setting for the commencement mode is auto-answer;

4) MCPTT client A3 has no pre-established session and the MCPTT services setting for the commencement mode is manual-answer;

5) MCPTT client has no pre-established session and the MCPTT services setting for queueing the commencement mode is auto-answer;

6) the IMS service provider (ims-op.net) is the same for all groups;

7) the flow does not consider confidentiality and integrity protection; and

8) non-controlling model used between the Primary and the partner is the "untrusted" model.

Figure A.1.3-1 shows the signalling flow when the controlling MCPTT function invites the prearranged groups consisting in the temporary group.

Figure A.1.3-1: Temporary prearranged group call setup

The steps of the flow are as follows:

NOTE 1: The parameters in the coding parts are only those specified in the normative part of the present document. For information about other parameters, see 3GPP TS 24.229 [4].

1) SIP INVITE request (MCPTT client A1 to participating MCPTT function A1) – see example in table A.1.3-1

Upon receiving a request from an MCPTT user A1 to establish an MCPTT temporary group session the MCPTT client A1 sends a SIP INVITE request towards the participating MCPTT function A1 according to 3GPP TS 24.229 [4].

Table A.1.3-1: SIP INVITE request (MCPTT client A1 to participating MCPTT function A1)

INVITE sip: pf-A1.ims-op.net SIP/2.0

Accept-Contact: *;+g.3gpp.mcptt;require;explicit,+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt;require;explicit

P-Preferred-Service:urn:urn-7:3gpp-service.ims.icsi.mcptt

Supported: timer

Session-Expires: 3600;refresher=uac

Contact: <sip:[5555::aaa:bbb:ccc:eee]>;g.3gpp.mcptt;g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

P-Preferred-Identity:<sip:userA1@ims-op.net>

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ccc:eee

m=audio 3456 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=maxptime:20

i=speech

m=application 3457 udp mcptt

a=fmtp:MCPTT mc_queueing;mc_implicit_request

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-group-T@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1—

Request-URI: Contains the public service identity of the participating MCPTT function serving the MCPTT user.

Accept-Contact: Contains the g.3gpp.mcptt feature tag.

P-Preferred-Service: Contains the ICSI for MCPTT.

Contact: Contains the registered contact and the g.3gpp.mcptt feature tag.

P-preferred-Identity: Contains the public user identity of the MCPTT user.

mcptt-info: The application/vnd.3gpp.mcptt-info+xml contains the <mcptt-Params> element with the <session-type> element set to "prearranged" and the <mcptt-request-uri> element set to "mcptt-group-T@mcptt-op.gov".

SDP offer: Contains a media-level section for the MCPTT speech media stream and a media-level section for the media-floor control entity indicating that of floor requests is supported ("mc:queueing") and that the SIP INVITE request is an implicit floor request ("mc_implicit_request").

2) SIP INVITE request (participating MCPTT function A1 to controlling MCPTT function A) – see example in table A.1.3-2

Upon receiving of a "SIP INVITE request for originating participating MCPTT function" containing an application/vnd.3gpp.mcptt-info+xml MIME body with the <session-type> element set to a value of "prearranged", the participating MCPTT function authorizes the MCPTT user to initiate the prearranged group call and since the MCPTT user is authorized, the participating MCPTT function A1 forwards the SIP INVITE request according to 3GPP TS 24.229 [4].

Table A.1.3-2: SIP INVITE request (participating MCPTT function A to controlling MCPTT function A)

INVITE sip: cf-A.ims-op.net SIP/2.0

Accept-Contact:

P-Asserted-Service:

Supported:

Session-Expires:

Contact:

P-Asserted-Identity:<sip:userA1@ims-op.net>

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ccc:eef

m=audio 7890 RTP/AVP 97

m=application 7891 udp mcptt

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-group-T@mcptt-city1.gov</>

<mcptt-calling-user-id>mcptt-id-A1@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1–

Request-URI: Updated to include the public service identifier of the MCPTT server owning the mcptt-group-T@mcptt-city1.gov.

mcptt-info: The application/vnd.3gpp.mcptt-info+xml is updated to include the MCPTT ID of the MCPTT user in the <mcptt-calling-user-id> element. The participating MCPTT function A1 determines the MCPTT-ID using the public user identity to locate the binding formed during service authorisation.

SDP offer: The SDP offer is updated to include the IP address and port numbers of the participating MCPTT function.

3) HTTP GET request (controlling MCPTT function A to GMS A)

Upon receipt of the "SIP INVITE request for controlling MCPTT function of an MCPTT group" the controlling MCPTT functions fetches the group document mcptt-group-T@mcptt-op.gov from the GMS A.

4) HTTP 200 response (GMS A to controlling MCPTT function A)

The GMS A returns the mcptt-group-T@mcptt-op.gov group document and the document indicates that this is a temporary group consisting of mcptt-group-A1@mcptt-op.gov, mcptt-group-B@mcptt-city1.net and mcptt-group-A2@mcptt-op.gov.

5) HTTP GET request (controlling MCPTT function A to GMS A)

Since the mcptt-id-A1@mcptt-op.gov is affiliated to the mcptt-group-A1@mcptt-op.gov the controlling MCPTT function fetches the group document from GMS A by means of a HTPP GET request as described in 3GPP TS 24.481 [31].

6) HTTP 200 response (GMS A to controlling MCPTT function B)

The GMS A returns the mcptt-group-A1@mcptt-op.gov group document with the list of group members in a HTTP 200 response as described in 3GPP TS 24.481 [31].

The controlling MCPTT function verifies that the mcptt-id-A1@mcptt-op.gov is authorized to initiate a prearranged group call.

The following steps describe the invitation of the group member mcptt-id-A@mcptt-op.gov using a pre-established session between the participating MCPTT function A2 and MCPTT client A2. Other members can be invited using the same method or using on-demand session signalling.

7) SIP INVITE request (controlling MCPTT function A to participating MCPTT function A2) – see example in table A.1.3-7

The controlling MCPTT function sends an initial SIP INVITE request towards the participating MCPTT function A2 according to 3GPP TS 24.229 [4].

Table A.1.3-7: SIP INVITE request (controlling MCPTT function A to participating MCPTT function A2)

INVITE sip: pf-A2.ims-op.net SIP/2.0

Accept-Contact: *;+g.3gpp.mcptt;require;explicit,+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt;require;explicit

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mcptt

Supported:timer

Session-Expires:3600

Contact: <sip:session@cf-A@ims-op.net:66350>;g.3gpp.mcptt;isfocus;g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

P-Asserted-Identity:<sip:cf-a@ims-op.net>

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ddd:aaa

m=audio 23124 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=maxptime:20

i=speech

m=application 23125 udp mcptt

a=fmtp:MCPTT mc_queueing;

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-id-A2@mcptt-op.gov</>

<mcptt-calling-group-id>mcptt-group-T@mcptt-op.gov</>

<mcptt-calling-user-id>userA1@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1–

Request-URI: Contains the public service identity of the participating MCPTT function A2 associated to the MCPTT user mcptt-id-A2@mcptt-op.gov.

Contact: Contains the MCPTT session identity.

P-Asserted-Identity: Contains the public service identity of the controlling MCPTT function A.

mcptt-info Is copied from the received INVITE request and updated to include the "mcptt-id-A2@mcptt-op.gov" in the <mcptt-request-uri> element and mcptt-group-T@mcptt-op.gov in the <mcptt-calling-group-id> element.

SDP offer: The SDP offer is based on the received SDP offer where the IP address and port numbers are replaced with the IP address and port numbers of the controlling MCPTT function. The media-level section for the media-floor control entity is indicating that queueing of floor requests is supported ("mc:queueing").

8) SIP 200 (OK) response (participating MCPTT function A2 to controlling MCPTT function A) – see example in table A.1.3-8

The participating MCPTT function detects that there is a pre-established session to the MCPTT client A2 where negotiated MCPTT speech media stream parameters and media-floor control entity ‘fmtp’ attributes matches the incoming SIP INVITE request and that the MCPTT service setting for commencement mode is set to "auto-answer".

The participating MCPTT function A2 sends a SIP 200 (OK) response to the controlling MCPTT function A according to 3GPP TS 24.229 [4].

Table A.1.3-8: SIP 200 (OK) response (participating MCPTT function A2 to controlling MCPTT function A)

SIP/2.0 200 OK

Session-Expires:3600;refresher=uac

Require: timer

P-Asserted-Identity:<sip:userA2@ims-op.net>

Contact: <sip:[5555::aaa:ccc:aaa:bbbb]>; g.3gpp.mcptt;

Supported: tdialog, norefersub, explicitsub, nosub

P-Answer-State:Unconfirmed

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:ccc:aaa:bbbb

m=audio 26456 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=maxptime:20

i=speech

m=application 26457 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-called-party-id>mcptt-id-A2@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1—

P-Asserted-Identity: Contains a public user identity of the sip: userA2@ims-op.net.

Contact: Contains a URI that identifies the session in the participating MCPTT function A2.

P-Answer-State: Contains the value "Unconfirmed" to indicate that the participating MCPTT function A2 sent this on behalf of the MCPTT A2.

SDP answer: The SDP answer is based on the received SDP offer and is updated to IP address and port numbers of the participating MCPTT function A2. The media-floor control entity ‘fmtp’ attributes includes the "mc_queueing" to indicate that queueing is supported.

9) SIP ACK request (controlling MCPTT function A to participating MCPTT function A2)

The controlling MCPTT function A acknowledge the SIP 200 (OK) response by means of the SIP ACK request.

10) MCPC Connect message (participating MCPTT function to MCPTT client B)

Since the MCPTT client B has a pre-established session the participating MCPTT function B uses the pre-established session to invite the MCPTT client B by means of a MCPC Connect messages as described in 3GPP TS 24.380 [5] annex A.

11) MCPC Acknowledgement message (MCPTT client B to participating MCPTT B)

The MCPTT client B acceptes the invitation and sends an MCPC Acknowledge message as as described in 3GPP TS 24.380 [5] annex A.

12) SIP 200 (OK) response (controlling MCPTT function A to participating MCPTT function A1) – see example in table A.1.3-12

Upon receiving the SIP 200 (OK) response from the participating MCPTT function A2, the controlling MCPTT function A interacts with the media plane as specified in 3GPP TS 24.380 [5] clause 6.3 and sends the SIP 200 (OK) towards the participating MCPTT function A1 according to 3GPP TS 24.229 [4].

NOTE 2: When more than one MCPTT user is invited (not done in this example) then when receiving additional SIP 200 (OK) responses from other participating MCPTT functions, the controlling MCPTT function sends the SIP ACK request towards the other participating MCPTT functions and interacts with the media plane as specified in clause 6.3 i.e. there is no SIP signalling sent towards the MCPTT client A1.

NOTE 3: If there more than one user in the group, the 200 (OK) response is not sent if the acknowledged timeout value for the group is running if some members of the group are marked as <on-network-required> as specified in 3GPP TS 24.481 [31], and responses are not received from those members.

Table A.1.3-12: SIP 200 (OK) response (controlling MCPTT function A to participating MCPTT function A1)

SIP/2.0 200 OK

Session-Expires:3600;refresher=uac

Require: timer

P-Asserted-Identity:<sip:cf-A.ims-op.net>

Contact: <sip:[5555::aaa:bbb:ddd:bbbb]>; +g.3gpp.mcptt;+g.3gpp.icsi-ref; isfocus

Supported: tdialog, norefersub, explicitsub, nosub

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ddd:bbbb

m=audio 23124 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=maxptime:20

i=speech

m=application 23125 udp mcptt

a=fmtp:MCPTT mc_queueing;mc_implicit_request

P-Asserted-Identity: Contains the public user identifier identifying the controlling MCPTT function.

Contact: Contains the MCPTT session identifier and the g.3gpp.icsi-ref and isfocus media feature tags.

SDP answer: Contains the SDP answer to the SDP offer received from the participating MCPTT function A2 updated with the IP address and port numbers of the controlling MCPTT function. The media-level section for the media-floor control entity acknowledges that queueing is supported ("mc_queueing") and that the SIP INVITE request is accepted as an implicit floor request.

13) SIP 200 (OK) response (participating MCPTT function A to MCPTT client A) – see example in table A.1.3-13

The participating MCPTT function A1 interacts with the media plane as specified in 3GPP TS 24.380 [5] clause 6.4 and sends the SIP 200 (OK) response towards the MCPTT client A1.

Table A.1.3-13: SIP 200 (OK) response (participating MCPTT function A to MCPTT client A1)

SIP/2.0 200 OK

Session-Expires:

Require:

P-Asserted-Identity:

Contact:

Resouce-Share: media-sharing; session-initiator; rules="k1::UL"; timestamp=55688

Priority-Share:allowed

Supported: tdialog

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:ccc:aaa:bbb

m=audio 7890 RTP/AVP 97

m=application 7891 udp mcptt

Resource-Share: Contains a new sharing key along with indication that MCPTT speech media can be shared in the uplink (UL) direction. The value "k1" is the key that P-CSCF can use to identify media streams towards MCPTT client A1 that can share media.

Priority-Share: The Priority-Share header field is set to "allowed" indicating that priority sharing can be applied by IMS.

SDP answer: Contains the SDP answer received from the controlling MCPTT function updated with the IP address and port numbers of the participating MCPTT function.

14)-15) SIP ACK request (MCPTT client A1 to controlling MCPTT function A via participating MCPTT function A1)

The MCPTT client A1 acknowledges the receipt of the SIP 200 (OK) response by means of a SIP ACK request. The ACK request is forwarded by the participating MCPTT function A1 to the controlling MCPTT function A.

16) SIP INVITE request (controlling MCPTT function A to non-Controlling MCPTT function C) – see example in table A.1.3-16

Since the GMS storing the group document of the "mcptt-group-B@mcptt-city1.net" is not available to the controlling MCPTT function A, the controlling MCPTT function A decides to use the non-controlling MCPTT function connectivity model (see figure 5.3.2-5) and sends a SIP INVITE request towards the MCPTT server hosting "mcptt-group-B@mcptt-city1.net" according to 3GPP TS 24.229 [4].

Table A.1.3-16: SIP INVITE request (controlling MCPTT function A to non-Controlling MCPTT function B)

INVITE sip:cf-B.ims-op.net SIP/2.0

Accept-Contact: *;+g.3gpp.mcptt;require;explicit,+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt;require;explicit

P-Asserted-Service:urn:urn-7:3gpp-service.ims.icsi.mcptt

Supported:timer

Session-Expires:3600

Contact: <sip:session@cf-A@ims-op.net:66350>;g.3gpp.mcptt;isfocus;g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

P-Asserted-Identity:<sip:cf-a@ims-op.net>

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ddd:aaa

m=audio 23124 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=maxptime:20

i=speech

m=application 23125 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-group-B@mcptt-city1.net</>

<mcptt-calling-user-id>userA1@mcptt-op.gov</>

<mcptt-calling-group-id>mcptt-group-T@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1–

Request-URI: Contains the public service identity of the MCPTT server hosting the "mcptt-group-B@mcptt-city1.net".

Contact: Contains the MCPTT session identity.

mcptt-info: Is copied from the received INVITE request and updated to include the "mcptt-group-B@mcptt-city1.net" in the <mcptt-request-uri> element and mcptt-group-T@mcptt-op.gov in the <mcptt-calling-group-id> element.

SDP offer: Is based on the received SDP offer where the IP address and port numbers are replaced with the IP address and port numbers of the controlling MCPTT function. The media-level section for the media-floor control entity is indicating that queueing is supported ("mc:queueing").

17) HTTP GET request (controlling MCPTT function A to GMS B)

Since mcptt-group-B@mcptt-city1.net is hosted by the non-controlling MCPTT function B the group document is fetched from GMS B.

The group document are fetched by means of a HTPP GET request as described in 3GPP TS 24.481 [31].

18) HTTP 200 response (GMS B to controlling MCPTT function B)

The GMS B returns the mcptt-group-B@mcptt-city1.net group document with the list of group members in a HTTP 200 response as described in 3GPP TS 24.481 [31].

The following steps describes the invitation of one group member, mcptt-id-B@mcptt-city1.net, using an on-demand session between the participating MCPTT function B and MCPTT client B. Other members can be invited using the same method or using pre-established session.

19) SIP INVITE request (non-controlling MCPTT function B to participating MCPTT function B) – see example in table A.1.3-19

The non-controlling MCPTT function B invites the MCPTT user "mcptt-id-B@mcptt-city1.net" to the session by sending and SIP INVITE request towards the terminating network in accordance with 3GPP TS 24.229 [4].

Table A.1.3-19: SIP INVITE request (non-Controlling MCPTT function B to participating MCPTT function B)

INVITE sip: pf-B.ims-op.net SIP/2.0

Accept-Contact:

P-Asserted-Service:

Supported:

Session-Expires:

Contact: <sip:sessionB@cf-B@ims-op.net:45678>;g.3gpp.mcptt; isfocus; g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

P-Asserted-Identity:<sip:cf-b@ims-op.net>

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ddd:ddd

m=audio 34456 RTP/AVP 97

m=application 34457 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-id-B@mcptt-city1.net</>

<mcptt-calling-user-id>mcptt-id-A@mcptt-op.gov</>

<mcptt-calling-group-id>mcptt-group-T@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1–

Contact: Contains a new MCPTT session identity and can be used by the members to rejoin the session.

NOTE 4: The MCPTT session identity received from the controlling MCPTT function A cannot be used since when a member of group mcptt-group-B@mcptt-city1.net rejoins the session, the member shall rejoin the session in the non-controlling MCPTT function B and not the session in the controlling MCPTT function A.

P-Asserted-Identity: Contains the public service identity of the non-controlling MCPTT function B.

mcptt-info: The identity of the invited MCPTT user mcptt-id-B@mcptt-city1.net is added.

SDP offer: The SDP offer is a copy of the received SDP offer updated with the IP address and port numbers of the non-controlling MCPTT function B.

20) SIP 183 (Session Progress) response (participating MCPTT function B to non-Controlling MCPTT function B) – see example in table A.1.3-20

The participating MCPTT function B sends a SIP 183 (Session Progress) response towards the non-controlling MCPTT function B according to 3GPP TS 24.229 [4].

Table A.1.3-20: SIP 183 (Session Progress) response (participating MCPTT function B non-Controlling MCPTT function B)

SIP/2.0 183 Session Progress

P-Asserted-Identity:

Contact: <sip:[5555::aaa:bbb:ccc:eef]>;+g.3gpp.mcptt;,+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

P-Answer-State:Unconfirmed

P-Answer-State: Contains the "Unconfirmed" indication acknowledging the automatic commencement mode.

21) SIP INVITE request (participating MCPTT function B to MCPTT client B) – see example in table A.1.3-21

The participating MCPTT function B sends the SIP INVITE request towards the MCPTT client B according to 3GPP TS 24.229 [4].

Table A.1.3-21: SIP INVITE request (participating MCPTT function B to MCPTT client B)

INVITE sip: userB@ims-op.net SIP/2.0

Accept-Contact:

P-Asserted-Service:

Supported:timer;tdialog

Session-Expires:refresher;uac

Contact:

Resouce-Share: media-sharing; session-receiver; rules="k2::UL"; timestamp=55750

Priority-Share:allowed

P-Asserted-Identity:<sip:cf-b@ims-op.net>

Answer-Mode:Auto

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ccc:eef

m=audio 16412 RTP/AVP 97

m=application 16413 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-id-B@mcptt-city1.net</>

<mcptt-calling-user-id>userA1@mcptt-op.gov</>

<mcptt-calling-group-id>mcptt-group-T@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1–

Request-URI: Contains the public user identity of the mcptt-id-B@mcptt-city1.net.

Resource-Share: Contains a new sharing key along with indication that MCPTT speech media can be shared in the uplink (UL) direction. The value "k2" is the key that P-CSCF can use to identify media streams towards MCPTT client A2 that can share media.

Priority-Share: The Priority-Share header field is set to "allowed" indicating that priority sharing can be applied by IMS.

Answer-Mode: The MCPTT service setting is "auto-answer" so the participating MCPTT function includes the value "auto" in the Answer-Mode header field.

SDP offer: The SDP offer is a copy of the received SDP offer updated with the IP address and port numbers of the participating MCPTT function B.

22) SIP 200 (OK) response (non-controlling MCPTT function B to controlling MCPTT function A) – see example in table A.1.3-22

Upon receipt of the first SIP 200 (OK) response from the participating MCPTT function B serving the invited MCPTT user B in the prearranged group mcptt-group-C@mcptt-city1.net, the non-controlling MCPTT function interact with the media plane as specified in 3GPP TS 24.380 [5] and sends the SIP 200 (OK) response towards the controlling MCPTT function A in accordance with 3GPP TS 24.229 [4].

NOTE 6: The non-controlling function translates the SIP 183 (Session Progress) response with a P-Answer-State header field set to "Auto" to a SIP 200 (OK) response only if the non-controlling function supports media-buffering otherwise a SIP 183 (Session Progress) response is sent.

Table A.1.3-22: SIP 200 (OK) response (non-controlling MCPTT function B to controlling MCPTT function A)

SIP/2.0 200 OK

Session-Expires:3600;refresher=uac

Require: timer

P-Asserted-Identity:<sip:cf-B.op.net>

Contact: <sip:[5555::aaa:bbb:ddd:ddd]>; g.3gpp.mcptt;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

Supported: tdialog, norefersub, explicitsub, nosub

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ddd:ddd

m=audio 34456 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=maxptime:20

i=speech

m=application 34457 udp mcptt

a=fmtp:MCPTT mc_queueing

P-Asserted-Identity Contains a public service identity identifying the non-controlling MCPTT function B.

Contact Contains a contact address and the media feature tags g.3gpp.mcptt and g.3gpp.icsi-ref.

SDP Contains the SDP answer to the SDP offer received from the controlling MCPTT function A. The media-level section for the media-floor control entity acknowledges that queueing is supported ("mc_queueing").

NOTE 5: The SDP answer is based on the capabilities of the non-controlling MCPTT function and not based on the SIP 200 (OK) response received from the participating MCPTT function.

23) SIP ACK request (controlling MCPTT function A to MCPTT client B via non-controlling MCPTT function B and participating MCPTT function B)

The controlling MCPTT function acknowledges the receipt of the SIP 200 (OK) response by means of a SIP ACK request.

24)-25) SIP 200 (OK) response (MCPTT client B to non-controlling MCPTT function B via participating MCPTT function B) – see example in table A.1.3-24

Upon receiving the SIP INVITE request the MCPTT client B accepts the invitation, interacts with the media plane as specified in 3GPP TS 24.380 clause 6.2 and sends the SIP 200 (OK) response towards the MCPTT server according to rules and procedures of 3GPP TS 24.229 [4].

Table A.1.3-24: SIP 200 (OK) response (MCPTT client B to non-controlling MCPTT function B via participating MCPTT function B)

SIP/2.0 200 OK

Session-Expires:3600;refresher=uas

Require: timer

Contact:<sip:[5555::baa:abb:ddd:cccc]>;+g.3gpp.mcptt;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt"

P-Asserted-Identity:<sip:userB@ims-op.net>

Supported: tdialog, norefersub, explicitsub, nosub

P-Answer-State:Confirmed

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::baa:abb:ddd:cccc

m=audio 62122 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=maxptime:20

i=speech

m=application 62123 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-called-party-id>mcptt-id-B@mcptt-city1.net</>

</mcptt-Params>

</mcpttinfo>

–boundary1—

Contact: Contains the registered contact and the g.3gpp.mcptt feature tag.

P-Answer-State: Contains the value "Confirmed" to indicate that the MCPTT client B sent the response.

SDP answer: The received SDP offer is accepted and updated with the IP address and port numbers of the MCPTT client B. The MCPTT client B confirms that queueing of floor requests are supported in the ‘fmtp’ attribute "mc_queueing".

The participating MCPTT function B updates the IP address and port numbers with the IP address and port numbers of the participating MCPTT function B.

26)-27) SIP ACK request (non-controlling MCPTT function B to MCPTT client B via participating MCPTT function B)

The non-controlling MCPTT function acknowledges the receipt of the SIP 200 (OK) response by means of a SIP ACK request.

28) SIP INVITE request (controlling MCPTT function A to non-controlling MCPTT function A) – see example in table A.1.3-28

Since the GMS storing the group document of the "mcptt-group-A2@mcptt-op.gov" is not available to the controlling MCPTT function A, the controlling MCPTT function A decides to use the non-controlling MCPTT function connectivity model (see figure 5.3.2-2) and sends a SIP INVITE request towards the MCPTT server hosting "mcptt-group-A2@mcptt-op.gov" in accordance with 3GPP TS 24.229 [4].

Table A.1.3-28: SIP INVITE request (controlling MCPTT function A to non-Controlling MCPTT function A)

INVITE sip: cf-A2.ims-op.net SIP/2.0

Accept-Contact: *;+g.3gpp.mcptt;require;explicit,+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt;require;explicit

P-Asserted-Service:urn:urn-7:3gpp-service.ims.icsi.mcptt

Supported:timer

Session-Expires:3600

Contact: <sip:session@cf-A@ims-op.net:66350>;g.3gpp.mcptt;isfocus;g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

P-Asserted-Identity:<sipcf-a@ims-op.net>

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ddd:aaa

m=audio 23124 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=maxptime:20

i=speech

m=application 23125 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-group-A2@mcptt-op.gov</>

<mcptt-calling-user-id>userA1@mcptt-op.gov</>

<mcptt-calling-group-id>mcptt-group-T@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1–

Request-URI: Contains the public service identity of the MCPTT server hosting the "mcptt-group-A2@mcptt-op.gov".

Contact: Contains the MCPTT session identity.

mcptt-info: Is copied from the received INVITE request and updated to include the "mcptt-group-A2@mcptt-op.gov" in the <mcptt-request-uri> element and mcptt-group-T@mcptt-op.gov in the <mcptt-calling-group-id> element.

29) HTTP GET request (controlling MCPTT function A to GMS B)

Since mcptt-group-A@mcptt-city1.net is hosted by the non-controlling MCPTT function A the group document is fetched from GMS A2.

The group document is fetched by means of a HTPP GET request as described in 3GPP TS 24.481 [31].

30) HTTP 200 response (GMS B to controlling MCPTT function B)

The GMS B returns the mcptt-group-A2@mcptt-op.gov group document with the list of group members in a HTTP 200 response as described in 3GPP TS 24.481 [31].

The following steps describes the invitation of one group member, mcptt-id-A@mcptt-op.gov, using an on-demand session between the participating MCPTT function B and MCPTT client B. Other members can be invited using the same method or using pre-established session.

31) SIP INVITE request (non-controlling MCPTT function A to participating MCPTT function A3) – see example in table A.1.3-31

The non-controlling MCPTT function A invites the MCPTT user mcptt-id-A3@mcptt-op.gov to the session by sending and SIP INVITE request towards the terminating network in accordance with 3GPP TS 24.229 [4].

Table A.1.3-31: SIP INVITE request (non-Controlling MCPTT function A to participating MCPTT function A3)

INVITE sip: pf-A3.ims-op.net SIP/2.0

Accept-Contact:

P-Asserted-Service:

Supported:

Session-Expires:

Contact: <sessionA@cf-A2@ims-op.net61234>;g.3gpp.mcptt; isfocus; g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

P-Asserted-Identity:<sip:cf-A2.ims-op.net>

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ddd:eee

m=audio 12344 RTP/AVP 97

m=application 12345 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-id-A3@mcptt-op.gov</>

<mcptt-calling-user-id>mcptt-id-A@mcptt-op.gov</>

<mcptt-calling-group-id>mcptt-group-T@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1–

Contact: Contains a new MCPTT session identity and can be used by the members to rejoin the session.

NOTE 7: The MCPTT session identity received from the controlling MCPTT function A cannot be used since when a member of group mcptt-group-A2@mcptt-op.gov rejoins the session, the member shall rejoin the session in the non-controlling MCPTT function A and not the session in the controlling MCPTT function A.

P-Asserted-Identity: Contains the public service identity of the non-controlling MCPTT function A.

mcptt-info: The identity of the invited MCPTT user mcptt-id-A3@mcptt-op.gov is added.

SDP offer: The SDP offer is a copy of the received SDP offer updated with the IP address and port numbers of the non-controlling MCPTT function A.

32) SIP INVITE request (participating MCPTT function A3 to MCPTT client A3) – see example in table A.1.3-32

The participating MCPTT function A3 sends the SIP INVITE request towards the MCPTT client A3 according to 3GPP TS 24.229 [4].

Table A.1.3-32: SIP INVITE request (participating MCPTT function A3 to MCPTT client A3)

INVITE sip: userA3@ims-op.net SIP/2.0

Accept-Contact:

P-Asserted-Service:

Supported:timer;tdialog

Session-Expires:refresher;uac

Contact:

Resouce-Share: media-sharing; session-receiver; rules="k3::UL"; timestamp=32651

Priority-Share:allowed

P-Asserted-Identity:<sip:cf-A2.ims-op.net>

Answer-Mode:Manual

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:ccc:aaa:ccc

m=audio 18412 RTP/AVP 97

m=application 18413 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-request-uri>mcptt-id-A3@mcptt-op.gov</>

<mcptt-calling-user-id>mcptt-id-A@mcptt-op.gov</>

<mcptt-calling-group-id>mcptt-group-T@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1–

Request-URI: Contains the public user identity of the userA3@ims-op.net.

Resource-Share: Contains a new sharing key along with indication that MCPTT speech media can be shared in the uplink (UL) direction. The value "k3" is the key that P-CSCF can use to identify media streams towards MCPTT client A3 that can share media.

Priority-Share: The Priority-Share header field is set to "allowed" indicating that priority sharing can be applied by IMS.

Answer-Mode: The MCPTT service setting is "manual-answer" so the participating MCPTT function includes the value "Manual" in the Answer-Mode header field.

SDP offer: The SDP offer is a copy of the received SDP offer updated with the IP address and port numbers of the participating MCPTT function B.

33)-34) SIP 200 (OK) response to the SIP INVITE request (MCPTT client A3 to non-controlling MCPTT function A) – see example in table A.1.3-33

Upon receiving the SIP INVITE request the MCPTT client A3 accepts the invitation, interacts with the media plane as specified in 3GPP TS 24.380 clause 6.2 and sends the SIP 200 (OK) response towards the MCPTT server according to rules and procedures of 3GPP TS 24.229 [4].

Table A.1.3-33: SIP 200 (OK) response (MCPTT client A3 to non-controlling MCPTT function via participating MCPTT function A3)

SIP/2.0 200 OK

Session-Expires:3600;refresher=uas

Require: timer

Contact:<sip:[5555::bbb:aaa:ccc:aaa]>;+g.3gpp.mcptt;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt"

P-Asserted-Identity:<sip:userA3@ims-op.net>

Supported: tdialog, norefersub, explicitsub, nosub

P-Answer-State:Confirmed

Content-Type: multipart/mixed;boundary="boundary1"

–boundary1

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::baa:abb:ddd:cccc

m=audio 25644 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=maxptime:20

i=speech

m=application 25644 udp mcptt

a=fmtp:MCPTT mc_queueing

–boundary1

Content-Type: application/vnd.3gpp.mcptt-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<mcptt-Params>

<session-type>prearranged</>

<mcptt-called-party-id>mcptt-id-A3@mcptt-op.gov</>

</mcptt-Params>

</mcpttinfo>

–boundary1—

Contact: Contains the registered contact, the g.3gpp.mcptt feature tag and the g.3gpp.icsi-ref media feature tag with the IMS communication service MCPTT.

P-Answer-State: Contains the value "Confirmed" to indicate that the MCPTT client sent the response.

SDP answer: The received SDP offer is accepted and updated with the IP address and port numbers of the MCPTT client A3. The MCPTT client A3 confirms that queueing of floor requests are supported in the ‘fmtp’ attribute "mc_queueing".

The participating MCPTT function A3 updates the IP address and port numbers with the IP address and port numbers of the participating MCPTT function A3.

35)-36) SIP ACK request (non-controlling MCPTT function A to MCPTT client A3 via participating MCPTT function A3.

The non-controlling MCPTT function A acknowledges the receipt of the SIP 200 (OK) response to the INVITE request by means of a SIP ACK request.

37) SIP 200 (OK) response to the SIP INVITE request (non-controlling MCPTT function A to controlling MCPTT function A) – see example in table A.1.3-37

Upon receipt of the first SIP 200 (OK) response from the participating MCPTT function A3 serving the invited MCPTT user A3 in the prearranged group mcptt-id-A3@mcptt-op.gov, the non-controlling MCPTT function A interact with the media plane as specified in 3GPP TS 24.380 [5] and sends the SIP 200 (OK) towards the controlling MCPTT function A in accordance with 3GPP TS 24.229 [4].

Table A.1.3-37: SIP 200 (OK) response (non-controlling MCPTT function A to controlling MCPTT function A)

SIP/2.0 200 OK

Session-Expires:3600;refresher=uac

Require: timer

P-Asserted-Identity:<sip:cf-B.ims-op.net>

Contact: <sip:[5555::aaa:bbb:ddd:eee]>;+g.3gpp.mcptt;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt

Supported: tdialog, norefersub, explicitsub, nosub

Content-Type: application/sdp

Content-Length: (…)

c=IN IP6 5555::aaa:bbb:ddd:eee

m=audio 12344 RTP/AVP 97

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=maxptime:20

i=speech

m=application 12345 udp mcptt

a=fmtp:MCPTT mc_queueing

P-Asserted-Identity Contains a public service identity identifying the non-controlling MCPTT function A3.

Contact Contains a contact address and the media feature tags g.3gpp.mcptt and g.3gpp.icsi-ref.

SDP Contains the SDP answer to the SDP offer received from the controlling MCPTT function A. The media-level section for the media-floor control entity acknowledged that queueing is supported ("mc_queueing").

NOTE 8: The SDP answer is based on the capabilities of the non-controlling MCPTT function and not based on the SIP 200 (OK) response received from the participating MCPTT function.

38) SIP ACK request (controlling MCPTT function A to non-controlling MCPTT function A.

The controlling MCPTT function A acknowledges the receipt of the SIP 200 (OK) response to the INVITE request by means of a SIP ACK request.

Annex B (normative):
Timers