10.1.3 Subscription to the conference event package

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

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

10.1.3.1 General

The IETF RFC 4575 [30] defines a conference event package that shall be used to obtain the status of participants in group sessions.

The MCPTT client may subscribe to the conference event package at any time in a group session that the MCPTT client participates in. The clause 10.1.3.2 specifies the procedures in the MCPTT client when subscribing to the conference events.

The participating MCPTT function shall forward conference state subscriptions and notifications as specified in clause 10.1.3.3.

The controlling MCPTT function shall handle subscriptions and notification of conference events as specified in clause 10.1.3.4.

The non-controlling MCPTT function shall handle subscriptions and notification of conference events as specified in clause 10.1.3.5.

When the non-controlling MCPTT function connection model is used, the controlling MCPTT function subscribes to the conference event package from the non-controlling MCPTT function as specified in clause 10.1.3.4.3 and the non-controlling MCPTT function subscribes to the conference event package from the controlling MCPTT function as specified in clause 10.1.3.5.3.

10.1.3.2 MCPTT client

A MCPTT client may subscribe to the conference event package when a group call is ongoing and the ongoing group call is not initiated as a broadcast group call by sending a SIP SUBSCRIBE request to obtain information of the status of a group session.

When subscribing to the conference event package, the MCPTT client:

1) shall generate a SIP SUBSCRIBE request and use a new SIP-dialog according to IETF RFC 6665 [26], IETF RFC 4575 [30] and 3GPP TS 24.229 [4];

2) shall set the Request-URI of the SIP SUBSCRIBE request to the MCPTT session identity of the group session;

3) 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];

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

5) if the MCPTT client wants to receive the current status and later notification, shall set the Expires header field according to IETF RFC 6665 [26], to 4294967295;

NOTE 1: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [24].

6) if the MCPTT client wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [26], to zero;

7) shall include an Accept header field containing the application/conference-info+xml"MIME type;

8) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-request-uri> element set to the MCPTT group ID of the group session; and

9) shall send the SIP SUBSCRIBE request using a new SIP dialog according to 3GPP TS 24.229 [4].

The responses to the SIP SUBSCRIBE request shall be handled according to IETF RFC 6665 [26], IETF RFC 4575 [30] and TS 24.229 [4].

Upon receiving a SIP NOTIFY requests to the previously sent SIP SUBSCRIBE request the MCPTT client:

1) shall handle the request according to IETF RFC 6665 [26] and IETF RFC 4575 [30]; and

2) may process the current state information to the MCPTT client based on the information in the SIP NOTIFY request body and may display to the MCPTT user the MCPTT IDs of the participating MCPTT users and the functional alias the participating MCPTT user has bound to that MCPTT group if available.

When needed the MCPTT client shall terminate the subscription and indicate it terminated according to IETF RFC 6665 [26].

NOTE 2: The contents of the received SIP NOTIFY request body is specified in clause 6.3.3.4.

10.1.3.3 Participating MCPTT function

Upon receipt of a "SIP SUBSCRIBE request for conference event status subscription in the participating function" from a MCPTT client served by the participating MCPTT function and if the SIP SUBSCRIBE request contains:

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

2) an Accept header field containing the application/conference-info+xml"MIME type; and

3) an application/vnd.3gpp.mcptt-info+xml MIME body containing the <mcptt-request-uri> set to a MCPTT group ID;

then the participating MCPTT function:

1) shall attempt to resolve the received Request-URI to an existing MCPTT session identity;

2) if the participating MCPTT function could not resolve the received Request-URI to an existing MCPTT session identity, shall reject the SIP SUBSCRIBE response with a SIP 404 (Not Found) response with a warning text set to "137 the indicated group call does not exist" as specified in clause 4.4 and shall skip the rest of the steps

3) shall generate a SUBSCRIBE request as specified in TS 24.229 [4]

4) shall set the SIP URI in the Request-URI with the MCPTT session identity that is mapped to the MCPTT session identity in the received Request-URI;

5) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body the <mcptt-calling-user-id> element set to the MCPTT ID of the served user: and

6) shall insert a Record-Route header containing a URI identifying its own address; and

7) shall send the SIP SUBSCRIBE request according to 3GPP TS 24.229 [4].

Upon receiving a SIP response to the SIP SUBSCRIBE request the participating MCPTT function:

1) shall copy the content of the incoming SIP response to an outgoing SIP response;

2) if a SIP 200 (OK) response, shall include in the Contact header field of the outgoing SIP response an MCPTT session identity mapped to the MCPTT session identity provided in the Contact header field of the received SIP 200 (OK) response in the outgoing SIP response; and

3) shall forward the SIP response according to 3GPP TS 24.229 [4].

Upon receiving a SIP NOTIFY request within the dialog created by the SIP SUBSCRIBE request destined to a served MCPTT client, the participating MCPTT function:

1) shall include the public service identity of the MCPTT user in the Request-URI;

2) shall copy the content of the incoming SIP NOTIFY request to the outgoing SIP NOTIFY request; and

3) shall send the SIP NOTIFY request according to 3GPP TS 24.229 [4].

Upon receiving a SIP response to the SIP NOTIFY request the participating MCPTT function:

1) shall copy the content of the incoming SIP response to an outgoing SIP response;

2) if a SIP 200 (OK) response, shall include an MCPTT session identity constructed from the MCPTT session identity provided in the Contact header field of the received SIP 200 (OK) response in the outgoing SIP response; and

3) shall forward the SIP response according to 3GPP TS 24.229 [4].

10.1.3.4 Controlling MCPTT function

10.1.3.4.1 Receiving a subscription to the conference event package

Upon receipt of a "SIP SUBSCRIBE request for conference event status subscription in the controlling MCPTT function" and the SIP SUBSCRIBE request:

1) contains an application/vnd.3gpp.mcptt-info+xml MIME body with

a) the <mcptt-request-uri> element set to the group identity of the group session and the <mcptt-calling-user-id> element set to either:

i) the MCPTT ID of a participant in the group session; or

ii) a constituent MCPTT group ID of a non-controlling MCPTT function in a temporary group session;

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

3) contains an Accept header field containing the application/conference-info+xml MIME type; and

4) is not received in a group call initiated as a broadcast group call;

then the controlling MCPTT function:

1) shall check if the <on-network-allow-conference-state> element in the group document in 3GPP TS 24.481 [31] allows the MCPTT ID or the constituent MCPTT group ID in the <mcptt-calling-user-id> element to subscribe to the conference event package and if not allowed:

a) shall reject the "SIP SUBSCRIBE request for conference event status subscription in the controlling MCPTT function" with a SIP 403 (Forbidden) response to the SIP SUBSCRIBE request, with warning text set to "138 subscription of conference events not allowed" as specified in clause 4.4; and

b) shall not continue with the remaining steps;

2) shall handle the request according to IETF RFC 6665 [26] and IETF RFC 4575 [30];

3) shall cache information about the subscription;

4) shall send a conference state notification as specified in clause 10.1.3.4.2; and

5) if the SIP SUBSCRIBE request is the first SUBSCRIBE request from a participant in a temporary group session, shall subscribe to the conference event package from all non-controlling MCPTT functions in the group session as specified in clause 10.1.3.4.3.

Upon receipt of a "SIP SUBSCRIBE request for conference event status subscription in the controlling MCPTT function in an group call initiated as a broadcast group call, the controlling MCPTT function:

1) shall generate a SIP 480 (Temporarily Unavailable) response to the SIP SUBSCRIBE request as specified in 3GPP TS 24.229 [4];

2) shall include a Warning header field with the warning text set to "105 subscription not allowed in a broadcast group call" as specified in clause 4.4; and

3) send the SIP 480 (Temporarily Unavailable) response according to 3GPP TS 24.229 [4].

10.1.3.4.2 Sending notifications to the conference event package

The procedures in this clause is triggered by:

1) the receipt of a SIP SUBSCRIBE request as specified in clause 10.1.3.4.1;

2) the receipt of a SIP BYE request from one of the participants in a pre-arranged or a chat group session; or

3) when a new participant is added in a pre-arranged or chat group session.

When sending a conference event notification, the controlling MCPTT function:

1) shall generate a notification package as specified in clause 6.3.3.4 to all MCPTT clients which have subscribed to the conference event package; and

NOTE: As a group document can potentially have a large content, the controlling MCPTT function can notify using content-indirection as defined in IETF RFC 4483 [32].

2) shall send a SIP NOTIFY request to all participants which have subscribed to the conference event package as specified in 3GPP TS 24.229 [4].

10.1.3.4.3 Sending subscriptions to the conference event package

The procedure in this clause is triggered by:

1) the receipt of a SIP 200 (OK) response to a SIP INVITE request for non-controlling MCPTT function of an MCPTT group and if at least one participant already has subscribed to the conference event package in the controlling MCPTT function as specified in clause 10.1.3.4.1; or

2) the receipt of the first SIP SUBSCRIBE request as specified in clause 10.1.3.4.1 and one or more participant in the group session is a non-controlling MCPTT function;

then, for each non-controlling MCPTT function from where a SIP 200 (OK) response to a SIP INVITE request for non-controlling MCPTT function of an MCPTT group has been received and where a SIP SUBSCRIBE request is not already sent, the controlling MCPTT function:

1) shall generate a SIP SUBSCRIBE request and use a new SIP-dialog according to IETF RFC 6665 [26], IETF RFC 4575 [30] and 3GPP TS 24.229 [4];

2) shall set the Request-URI of the SIP SUBSCRIBE request to the public service identity of the non-controlling MCPTT function serving the group identity of the MCPTT group owned by the partner MCPTT system;

3) shall include the same P-Asserted-Identity header field as included in the SIP INVITE request for non-controlling MCPTT function of an MCPTT group;

4) 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];

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

6) shall set the Expires header field according to IETF RFC 6665 [26], to 4294967295;

NOTE: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [24].

7) shall include an Accept header field containing the application/conference-info+xml MIME type;

8) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with:

a) the <mcptt-request-uri> element set to the constituent MCPTT group ID; and

b) the <mcptt-calling-group-id> set to the temporary MCPTT group ID; and

9) shall send the SIP SUBSCRIBE request using a new SIP dialog according to 3GPP TS 24.229 [4].

The responses to the SIP SUBSCRIBE request shall be handled according to IETF RFC 6665 [26], IETF RFC 4575 [30] and TS 24.229 [4].

Upon receiving an incoming SIP NOTIFY requests to the previously sent SIP SUBSCRIBE request, the controlling MCPTT function:

1) shall handle the request according to IETF RFC 6665 [26] and IETF RFC 4575 [30];

2) shall modify the SIP NOTIFY request as specified in clause 6.3.3.4; and

3) shall forward the modified SIP NOTIFY request according to 3GPP TS 24.229 [4] to all other participants with a subscription to the conference event package.

NOTE: A non-controlling MCPTT function of an MCPTT group is regarded as a participant in a temporary group session.

10.1.3.4.4 Terminating a subscription

Upon receipt of a "SIP SUBSCRIBE request for conference event status subscription in the controlling MCPTT function" that terminates the subscription of the conference event package as specified in IETF RFC 6665 [26], the controlling MCPTT function:

1) shall send a SIP 200 (OK) response as specified in IETF RFC 6665 [26]; and

2) if there are no remaining subscriptions to the event package in the ongoing MCPTT call in a temporary group session, shall terminate the subscriptions to the conference event package as specified in IETF RFC 6665 [26] in all non-controlling MCPTT functions in the temporary group session.

Upon expiry of the subscription timer and if there are no remaining subscriptions to the event package in the ongoing MCPTT call in a temporary group session, the controlling MCPTT function shall terminate the subscriptions to the conference event package as specified in IETF RFC 6665 [26] in all non-controlling MCPTT functions in the temporary group session.

10.1.3.5 Non-controlling MCPTT function

10.1.3.5.1 Receiving subscriptions to the conference event package

Upon receipt of "SIP SUBSCRIBE request for conference event status subscription in the non-controlling MCPTT function" and the SIP SUBSCRIBE request:

1) contains an application/vnd.3gpp.mcptt-info+xml MIME body with

a) the <mcptt-request-uri> element set to the constituent MCPTT group ID; and

b) the <mcptt-calling-user-id> element is set to:

i) a participant in the group session; or

ii) the temporary MCPTT group ID;

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

3) contains an Accept header field containing the application/conference-info+xml MIME type; and

4) is not received in a group call initiated as a broadcast group call;

then the non-controlling MCPTT function:

1) shall check if the <on-network-allow-conference-state> element in the group document in 3GPP TS 24.481 [31] of the constituent group allows the MCPTT ID in the <mcptt-calling-user-id> element to subscribe to the conference event package and if not allowed:

b) shall not continue with the remaining steps;

2) shall handle the request according to IETF RFC 6665 [26] and IETF RFC 4575 [30];

3) shall cache information about the subscription;

4) shall generate a notification package as specified in clause 6.3.4.3 and send a SIP NOTIFY request according to 3GPP TS 24.229 [4] to the MCPTT client which have subscribed to the conference event package; and

5) if the SIP SUBSCRIBE request is the first SIP SUBSCRIBE request from a MCPTT client, shall subscribe to the conference event package from the controlling MCPTT functions in the group session as specified in clause 10.1.3.5.3.

Upon receipt of a "SIP SUBSCRIBE request for conference event status subscription in the controlling MCPTT function" in a group call initiated as a broadcast group call, the controlling MCPTT function:

1) shall generate a SIP 480 (Temporarily Unavailable) response to the SIP SUBSCRIBE request as specified in 3GPP TS 24.229 [4];

2) shall include a Warning header field with the warning text set to "105 subscription not allowed in a broadcast group call" as specified in clause 4.4; and

3) send the SIP 480 (Temporarily Unavailable) response according to 3GPP TS 24.229 [4].

10.1.3.5.2 Sending notifications to the conference event package

The procedures in this clause is triggered by:

1) the receipt of a receipt of a SIP BYE request from one of the participants in a pre-arranged or a chat group session; or

2) when a new participant is added in a pre-arranged or chat group session.

When sending a conference event notification, the non-controlling MCPTT function:

1) shall generate a notification package as specified in clause 6.3.4.3 to all participants which have subscribed to the conference event package; and

NOTE: As a group document can potentially have a large content, the controlling MCPTT function can notify using content-indirection as defined in IETF RFC 4483 [32].

2) shall send a SIP NOTIFY request to all participants which have subscribed to the conference event package as specified in 3GPP TS 24.229 [4].

10.1.3.5.3 Sending a subscription to the conference event package

Upon receipt of the first subscription to the conference event package from an MCPTT client, the non-controlling MCPTT function:

1) shall generate a SIP SUBSCRIBE request and use a new SIP-dialog according to IETF RFC 6665 [26], IETF RFC 4575 [30] and 3GPP TS 24.229 [4];

2) shall set the Request-URI of the SIP SUBSCRIBE request to the temporary MCPTT session identity;

NOTE: The SIP URI received in the Contact header field of the SIP INVITE request for non-controlling MCPTT function of an MCPTT group is the temporary MCPTT session identity. Towards MCPTT clients the non-controlling MCPTT function uses an internal generated MCPTT session identity.

3) 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-Asserted-Service header field according to IETF RFC 6050 [9];

5) shall set the Expires header field according to IETF RFC 6665 [26], to 4294967295;

NOTE 2: 4294967295, which is equal to 2³²-1, is the highest value defined for Expires header field in IETF RFC 3261 [24].

6) shall include an Accept header field containing the application/conference-info+xml MIME type;

7) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with:

a) the <mcptt-request-uri> element set to the temporary MCPTT group ID: and

b) the <mcptt-calling-group-id> set to the constituent MCPTT group ID; and

8) shall send the SIP SUBSCRIBE request using a new SIP dialog according to 3GPP TS 24.229 [4].

The 2xx response to the SIP SUBSCRIBE request shall be handled according to IETF RFC 6665 [26], IETF RFC 4575 [30] and TS 24.229 [4].

Upon receiving an incoming SIP NOTIFY requests to the previously sent SIP SUBSCRIBE request the non-controlling MCPTT function:

1) shall handle the request according to IETF RFC 6665 [26] and IETF RFC 4575 [30];

2) shall store conference information based on the SIP NOTIFY request content;

3) shall modify the SIP NOTIFY request as specified in clause 6.3.4.3; and

4) forward the modified SIP NOTIFY request according to 3GPP TS 24.229 [4] to all MCPTT clients with a subscription to the conference event package.

10.1.3.5.4 Terminating a subscription

Upon receipt of a "SIP SUBSCRIBE request for conference event status subscription in the non-controlling MCPTT function" that terminates the subscription of the conference event package as specified in IETF RFC 6665 [26], the non-controlling MCPTT function:

1) shall send a SIP 200 (OK) response as specified in IETF RFC 6665 [26]; and

2) if there are no remaining subscriptions to the event package (excluding any subscriptions to the event package made by the controlling MCPTT function), shall terminate the subscriptions to the conference event package in the controlling MCPTT function as specified in IETF RFC 6665 [26].

Upon expiry of the subscription timer and if there are no remaining subscriptions to the event package (excluding any subscriptions to the event package made by the controlling MCPTT function), the non-controlling MCPTT function shall terminate the subscriptions to the conference event package in the controlling MCPTT function as specified in IETF RFC 6665 [26].

NOTE: The subscription to the event package made by the controlling MCPTT function will be terminated by the controlling MCPTT function when the last subscription to the event package is terminated in the controlling MCPTT function.

10.1.3.6 Coding

10.1.3.6.1 Extension of application/conference-info+xml MIME type

10.1.3.6.1.1 Introduction

The present clause describes an extensions of the application/conference-info+xml MIME body specified in IETF RFC 4575 [30].

The functional alias extension is used to indicate per-user functional alias association with MCPTT group.

10.1.3.6.1.2 Schema

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

targetNamespace="urn:3gpp:ns:mcpttConfInfo:1.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:mcpttConfInfo="urn:3gpp:ns:mcpttConfInfo:1.0"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<!– MCPTT specific child element of endpoint element –>

<xs:element name="functional-alias" type="xs:anyURI" use="optional"/>

</xs:schema>

The application/conference-info MIME body refers to namespaces using prefixes specified in table 10.1.3.6.1.2-1.

Table 10.1.3.6.1.2-1: Assignment of prefixes to namespace names in the application/pidf+xml MIME body

Prefix	Namespace
mcpttConfInfo	urn:3gpp:ns:mcpttConfInfo:1.0
NOTE: The "urn:ietf:params:xml:ns:conference-info" namespace is the default namespace so no prefix is used for it in the application/conference-info MIME body.