9.2.3 Subscription to the conference event package

24.2813GPPMission Critical Video (MCVideo) signalling controlProtocol specificationRelease 18TS

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

9.2.3.1 General

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

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

The participating MCVideo function shall forward conference state subscriptions and notifications as specified in clause 9.2.3.3.

The controlling MCVideo function shall handle subscriptions and notification of conference state events as specified in clause 9.2.3.4.

The non-controlling MCVideo function shall handle subscriptions and notification of conference state events as specified in clause 9.2.3.4.

When the non-controlling MCVideo function connection model is used, the controlling MCVideo function subscribes to the conference state event package from the non-controlling MCVideo function as specified in clause 9.2.3.4.3 and the non-controlling MCVideo function subscribes to the conference state event package from the controlling MCVideo function as specified in clause 9.2.3.5.3.

9.2.3.2 MCVideo client

A MCVideo client may subscribe to the conference state 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 state event package, the MCVideo client:

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

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

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

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.mcvideo" along with "require" and "explicit" header field parameters according to IETF RFC 3841 [20];

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

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

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

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

8) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideo-request-uri> element set to the MCVideo 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 [11].

The responses to the SIP SUBSCRIBE request shall be handled according to IETF RFC 6665 [16], IETF RFC 4575 [57] and TS 24.229 [11].

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

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

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

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

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

9.2.3.3 Participating MCVideo function

Upon receipt of a "SIP SUBSCRIBE request for conference event status subscription in the participating MCVideo function" and if the SIP SUBSCRIBE request contains:

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

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

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

then the participating MCVideo function:

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

2) if the participating MCVideo function could not resolve the received Request-URI to an existing MCVideo 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 exists" 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 [11]

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

5) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body the <mcvideo-calling-user-id> element set to the MCVideo 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 [11].

Upon receiving a SIP response to the SIP SUBSCRIBE request the participating MCVideo 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 MCVideo session identity mapped to the MCVideo 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 [11].

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

1) shall include the public service identity of the MCVideo 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 [11].

Upon receiving a SIP response to the SIP NOTIFY request the participating MCVideo 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 MCVideo session identity constructed from the MCVideo 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 [11].

9.2.3.4 Controlling MCVideo function

9.2.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 MCVideo function" and the SIP SUBSCRIBE request:

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

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

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

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

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

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 MCVideo function:

1) shall check if the <on-network-allow-conference-state> element in the group document in 3GPP TS 24.481 [24] allows the MCVideo ID or the constituent MCVideo group ID in the <mcvideo-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 MCVideo 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 [16] and IETF RFC 4575 [57];

3) shall cache information about the subscription;

4) shall send a conference state notification as specified in clause 9.2.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 MCVideo functions in the group session as specified in clause 9.2.3.4.3.

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

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

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 [11].

9.2.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 9.2.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 state event notification, the controlling MCVideo function:

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

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

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

9.2.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 MCVideo function of an MCVideo group and if at least one participant already has subscribed to the conference event package in the controlling MCVideo function as specified in clause 9.2.3.4.1; or

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

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

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

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

NOTE 1: The public service identity can identify the non-controlling function in the local MCVideo system or in an interconnected MCVideo system.

NOTE 2: If the non-controlling MCVideo function is in an interconnected MCVideo system in a different trust domain, then the public service identity can identify the MCVideo gateway server that acts as an entry point in the interconnected MCVideo system from the local MCVideo system.

NOTE 3: If the non-controlling MCVideo function is in an interconnected MCVideo system in a different trust domain, then the local MCVideo system can route the SIP request through an MCVideo gateway server that acts as an exit point from the local MCVideo system to the interconnected MCVideo system.

NOTE 4: How the controlling MCVideo function determines the public service identity of the non-controlling MCVideo function associated with the group identity or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

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

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

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

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

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

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

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

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

b) the <mcvideo-calling-group-id> set to the temporary MCVideo group ID; and

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

The responses to the SIP SUBSCRIBE request shall be handled according to IETF RFC 6665 [16], IETF RFC 4575 [57] and TS 24.229 [11].

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

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

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 [11] to all other participants with a subscription to the conference event package.

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

9.2.3.4.4 Terminating a subscription

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

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

2) if there are no remaining subscriptions to the event package in the ongoing MCVideo call in a temporary group session, shall terminate the subscriptions to the conference event package as specified in IETF RFC 6665 [16] in all non-controlling MCVideo 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 MCVideo call in a temporary group session, the controlling MCVideo function shall terminate the subscriptions to the conference event package as specified in IETF RFC 6665 [16] in all non-controlling MCVideo functions in the temporary group session.

9.2.3.5 Non-controlling MCVideo function

9.2.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 MCVideo function" and the SIP SUBSCRIBE request:

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

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

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

i) a participant in the group session; or

ii) the temporary MCVideo group ID;

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

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 MCVideo function:

1) shall check if the <on-network-allow-conference-state> element in the group document in 3GPP TS 24.481 [24] of the constituent group allows the MCVideo ID in the <mcvideo-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 non-controlling MCVideo 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 [16] and IETF RFC 4575 [57];

3) shall cache information about the subscription;

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

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

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

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 [11].

9.2.3.5.2 Sending notifications to the conference event package

The procedures in this clause are 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 MCVideo function:

1) shall generate a notification package as specified in clause 6.3.3.4 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 MCVideo function can notify using content-indirection as defined in IETF RFC 4483 [29].

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 [11].

9.2.3.5.3 Sending a subscription to the conference event package

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

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

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

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

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

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

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

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

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

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

b) the <mcvideo-calling-group-id> set to the constituent MCVideo group ID; and

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

The 2xx response to the SIP SUBSCRIBE request shall be handled according to IETF RFC 6665 [16], IETF RFC 4575 [57] and 3GPP TS 24.229 [11].

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

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

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.3.4; and

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

9.2.3.6 Coding

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

9.2.3.6.1.1 Introduction

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

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

9.2.3.6.1.2 Schema

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

<xs:schema

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

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

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

elementFormDefault="qualified" attributeFormDefault="unqualified">

<!– MCVideo 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 9.2.3.6.1.2-1.

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

Prefix	Namespace
mcvideoConfInfo	urn:3gpp:ns:mcvideoConfInfo: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.