5 Protocol using SIP and SIP events for conferencing

24.1473GPPConferencing using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS

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

5.1 Introduction

Void

5.2 Functional entities

5.2.1 User Equipment (UE)

For the purpose of SIP based conferences, the UE shall implement the role of a Conference participant as described in subclause 5.3.1.

5.2.2 Media Resource Function Controller (MRFC)

For the purpose of SIP based conferences, the MRFC shall support the procedures for ad-hoc conferencing as described in subclause 5.8 of 3GPP TS 24.229 [5] and the procedures for media control of ad-hoc conferencing described in subclause 10.3 of 3GPP TS 24.229 [5]

For the purpose of SIP based conferences, the MRFC shall regard the MRFP as a mixer, as described in RFC 4353 [8].

5.2.3 Conferencing Application Server (AS)

For the purpose of SIP based conferences, the conferencing AS shall implement the role of a conference focus, as described in subclause 5.3.2 and as a conference notification service, as described in subclause 5.3.3. The conferencing AS may implement the role of a conference participant as described in subclause 5.3.1.

The conferencing AS shall use the procedures for 3^rd party call control as described in subclause 5.7.5 of 3GPP TS 24.229 [5] and the procedures for media control in subclause 10.2 of 3GPP TS 24.229 [5] to implement SIP based conferences.

5.2.4 Media Gateway Control Function (MGCF)

For the purpose of SIP based conferences, the MGCF shall implement the role of Conference participant as described in subclauses 5.3.1.3.2, 5.3.1.4.1, 5.3.1.5.4, 5.3.1.6.1 and 5.3.1.6.2. In addition, MGCF shall implement the functions except the "REFER" function in subclause 5.3.1.3.3.

5.3 Role

5.3.1 Conference Participant

5.3.1.1 General

In addition to the procedures specified in subclause 5.3.1, the conference participant shall support the procedures specified in 3GPP TS 24.229 [5] appropriate to the functional entity in which the conference participant is implemented.

5.3.1.2 Subscription for conference event package

The conference participant may subscribe to the conference event package, as described in RFC 4575 [11]. If the SUBSCRIBE request outside the existing INVITE dialog is rejected by a 403 (Forbidden) response, the conference participant should send a SUBSCRIBE request in the existing INVITE dialog.

If SUBSCRIBE request in the existing INVITE dialog fails, the UE should continue the conference call without conference event subscription.

NOTE: Pre-release 12 networks can support in-dialog SUBSCRIBE requests only. Sending a SUBSCRIBE in the existing dialog enables the UE to subscribe to the conference event package in this situation.

5.3.1.3 Conference creation

5.3.1.3.1 General

A conference can be created by means of SIP, as described in subclause 5.3.1.3.2 or subclause 5.3.1.3.3.

NOTE: Additionally, creation of a conference can be provided by other means.

The conference participant shall make use of the procedures for session establishment as described in subclauses 5.1.2A and 5.1.3 of 3GPP TS 24.229 [5] when creating conferences by means of SIP.

5.3.1.3.2 Conference creation with a conference factory URI

Upon a request to create a conference with a conference factory URI, the conference participant shall:

1) generate an initial INVITE request in accordance with subclause 5.1.3.1 of 3GPP TS 24.229 [5]; and

2) set the request URI of the INVITE request to the conference factory URI.

On receiving a 200 (OK) response to the INVITE request with the "isfocus" feature parameter indicated in Contact header, the conference participant shall store the content of the received Contact header as the conference URI. In addition to this, the conference participant may subscribe to the conference event package as described in RFC 4575 [11] by using the stored conference URI.

NOTE 1: A conference participant can decide not to subscribe to the conference event package for conferences with a large number of attendees, due to, e.g. the signalling traffic caused by the notifications about users joining or leaving the conference.

NOTE 2: A conference can also be created with a conference URI. The procedures for this case at the conference participant are identical to those for joining a conference, as described in subclause 5.3.1.4.1. It is not assumed that the conference participant is aware that the conference gets created in this case.

NOTE 3: The UE can discover the conference factory URI from the Management Object as defined in 3GPP TS 24.166 [38]. Further discovery mechanisms for the conference factory URI are outside the scope of the present document.

5.3.1.3.3 Three-way session creation

When a user is participating in two or more SIP sessions and wants to join together two of these active sessions to a so-called three-way session, the user shall perform the following steps.

1) create a conference at the conference focus by sending an INVITE request with the conference factory URI for the three-way session towards the conference focus, as described in subclause 5.3.1.3.2;

2) decide and perform for each of the active sessions that are requested to be joined to the three-way session, how the remote user shall be invited to the three-way session, which can either be:

a) by performing the procedures for inviting a user to a conference by sending an REFER request to the user, as described in subclause 5.3.1.5.2; or

b) by performing the procedures for inviting a user to a conference by sending a REFER request to the conference focus, as described in subclause 5.3.1.5.3;

3) release the active session with the user, by applying the procedures for session release in accordance with RFC 3261 [7], provided that a BYE request has not already been received, after a NOTIFY request has been received, indicating that the user has successfully joined the three-way session, i.e. including:

a) a body of content-type "message/sipfrag" that indicates a "200 OK" response; and,

b) a Subscription-State header set to the value "terminated"; and,

4) treat the created three-way session as a normal conference, i.e. the conference participant shall apply the applicable procedures of subclause 5.3.1 for it.

5.3.1.4 Joining a conference

5.3.1.4.1 User joining a conference by using a conference URI

Upon generating an initial INVITE request to join a conference for which the conference URI is known to the conference participant, the conference participant shall:

1) set the request URI of the INVITE request to the conference URI; and

2) send the INVITE request towards the conferencing AS that is hosting the conference.

NOTE 1: The initial INVITE request is generated in accordance with 3GPP TS 24.229 [5].

NOTE 2: The conference participants can get the conference URI as described in subclause 5.3.1.4.2. Other mechanisms can also be used by the conference participant to become aware of the conference URI, but they are out of scope of this specification..

In addition, the conference participant may subscribe to the conference event package as described in RFC 4575 [11] by using the known conference URI.

NOTE 3: A conference participant can decide not to subscribe to the conference event package for conferences with a large number of attendees, due to the signalling traffic caused by the notifications about e.g. users joining or leaving the conference.

Upon receipt of an INVITE request that includes a Replaces header, the conference participant shall apply the procedures described in RFC 3891 [33] to the INVITE request.

5.3.1.4.2 User joining a conference after receipt of a REFER request

Upon receipt of a REFER request that either includes a Refer-To header which includes the "method" uri parameter set to INVITE or does not include the "method" URI parameter, the conference participant shall:

1) handle the REFER request in accordance with RFC 3515 [17] as updated by RFC 6665 [10];

2) perform the actions as described in subclause 5.3.1.4.1 for a user joining a conference; and

3) if the received REFER request included a Referred-By header, include the Referred-By header in accordance with RFC 3892 [20] in the INVITE request that is sent for joining the conference.

5.3.1.5 Inviting other users to a conference

5.3.1.5.1 General

Upon inviting other users to a conference, the conference participant has to decide which of the following procedures has to be applied:

1) inviting an user to a conference by sending a REFER request to the user directly, as described in subclause 5.3.1.5.2; or

2) inviting a user to a conference by sending a REFER request to the conference focus, as described in subclause 5.3.1.5.3; or

3) inviting one or more users to a conference by adding these users’ SIP URIs to the INVITE request that is sent to the Conference focus to create the conference (see subclause 5.3.1.3.2) as described in subclause 5.3.1.5.4.

NOTE: Additionally, users can be invited to a conference by other means.

It is out of the scope of the present document, how the UE decides which of the above procedures shall be applied.

5.3.1.5.2 User invites other user to a conference by sending a REFER request to the other user

Upon generating a REFER request in accordance with the procedures specified in 3GPP TS 24.229 [5], IETF RFC 3515 [17] as updated by IETF RFC 6665 [10] and IETF RFC 7647 [39] that is destined to a user in order to invite that user to a specific conference, the conference participant shall:

1) set the request URI of the REFER request to the address of the user who is invited to the conference;

2) set the Refer-To header of the REFER request to the conference URI of the conference that the other user shall be invited to, including the "method" URI parameter set to "INVITE" or omit the "method" parameter; and

NOTE: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5].

3) send the REFER request towards the user who is invited to the conference.

The UE may additionally include the Referred-By header to the REFER request and set it to the URI of the conference participant that is sending the REFER request.

Afterwards the UE shall treat incoming NOTIFY requests that are related to the previously sent REFER request in accordance with RFC 3515 [17] as updated by RFC 6665 [10] and may indicate the received information to the user.

5.3.1.5.3 User invites other user to a conference by sending a REFER request to the conference focus

Upon generating a REFER request in accordance with the procedures specified in 3GPP TS 24.229 [5], IETF RFC 3515 [17] as updated by IETF RFC 6665 [10] and IETF RFC 7647 [39] that is destined to the conference focus in order to invite another user to a specific conference, the conference participant shall:

1) set the request URI of the REFER request to the conference URI to which the user is invited to;

2) set the Refer-To header of the REFER request to the SIP URI or tel URL of the user who is invited to the conference;

3) either include the "method" URI parameter with the value "INVITE" or omit the "method" URI parameter in the Refer-To header; and

NOTE: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5].

4) send the REFER request towards the conference focus that is hosting the conference.

The UE may additionally include the Referred-By header to the REFER request and set it to the URI of the conference participant that is sending the REFER request.

In case of an active session the UE may additionally include the Replaces header in the header portion of the SIP URI of the Refer-to header field of the REFER request. If the user involved in the active session is identified by a tel URI, the UE shall convert the tel URI to an SIP URI as described in RFC 3261 [7] before including the Replaces header field. The included Replaces header field shall refer to the active dialog that is replaced by the ad-hoc conference. The Replaces header field shall comply with RFC 3891 [33].

5.3.1.5.4 User invites other users to a conference by including URI list in initial INVITE request to the conference focus

Upon generating an INVITE request that is destined to the conference focus in order to create a conference using a conference factory URI (see subclause 5.3.1.3.2) the UE may attach a message body to the request that includes a URI list as described in RFC 5366 [34]. In order to do this the UE shall follow the procedures in subclause 5.3.1.3.2 for creation of the INVITE request and, in addition, the conference initiator shall build a list of URIs in accordance with RFC 5366 [34] including the SIP URIs of all the users that are to be invited to the conference.

In case of an ad-hoc conference where the conference creator is already involved in a dialog with a user who shall be invited to the conference, the UE may add information of this dialog ID (Call-ID header field, From header field, To header field, and if available a Session-ID header field as described in RFC 7989 [37]) to the URIs in the URI list, according to the procedures for adding header fields ("?" mechanism) described in subclause 19.1.1 of RFC 3261 [7].

Once the INVITE request has been sent, the conference participant shall behave as described in subclause 5.3.1.3.2 once the 200 (OK) response to the INVITE is received.

5.3.1.6 Leaving a conference

5.3.1.6.1 Conference participant leaving a conference

When leaving a conference, the conference participant shall:

1) generate a BYE request on the dialog that was established when joining or creating the conference, in accordance to the procedures described in 3GPP TS 24.229 [5] and RFC 3261 [7];

2) if the conference participant is subscribed to the conference state event information of that conference, the conference participant shall not renew this subscription and let the related subscription timer expire. When a related NOTIFY request is received which does not include a Subscription-State header set to the value "terminated", the conference participant shall:

a) wait for an implementation dependant time, if a related NOTIFY request with the Subscription-State header set to the value "terminated" is received; and

b) afterwards, if no such NOTIFY request is received, unsubscribe from the conference state event information by performing the procedures as described in RFC 6665 [10] and RFC 4575 [11].

NOTE 1: A conference participant leaving a conference will cause the conference notification service to send a NOTIFY request with updated conference state information to all conference participants, including the participant who just left. Therefore the time between sending the BYE request and receiving the next NOTIFY request is very short. The conference participant does not immediately unsubscribe from the conference event package in order not to cause unnecessary traffic on the air interface.

NOTE 2: After the conference participant leaves the conference, it can receive NOTIFY requests that cross the BYE request sent by the conference participant. In this case, the NOTIFY request will not include a Subscription-State header with the value "terminated", as it was issued before the conference focus / conference notification service got aware of the conference participant leaving the conference. Due to this another NOTIFY request may be received within a short period of time (see NOTE 1), that carries the Subscription-State header set to "terminated".

5.3.1.6.2 Conference focus removes conference participant from a conference

Upon receipt of a BYE request on the dialog that was established when joining or creating a conference, the conference participant shall:

1) respond to the BYE request as described in 3GPP TS 24.229 [5] and RFC 3261 [7]; and

2) if the conference participant is subscribed to the conference state event information of that conference, perform the actions for not renewing the subscription to the conference state event information as described for the conference participant leaving a conference in subclause 5.3.1.6.1.

5.3.1.6.3 Removing a conference participant from a conference

Upon generating a REFER request in accordance with the procedures specified in 3GPP TS 24.229 [5], IETF RFC 3515 [17] as updated by IETF RFC 6665 [10] and IETF RFC 7647 [39] to remove a conference participant from a conference, the removing conference participant shall:

1) set the request URI of the REFER request to the conference URI of the conference from which the conference participant shall be removed

2) set the Refer-To header of the REFER request:

a) to the address of the conference participant who should be removed from the conference, including the "method" parameter set to "BYE“, if a single conference participant should be removed from the conference. If the address of conference participant is a global tel URI, it shall be converted to SIP URI as described in RFC 3261 [7]; or

b) to the conference URI and the “method" parameter to “BYE“, if all conference participants shall be removed from the conference.

NOTE 1: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5].

NOTE 2: The removal of all conference participants from the conference will terminate the conference if the conference policy is set accordingly.

3) send the REFER request towards the conference focus that is hosting the conference.

Afterwards the removing conference participant shall treat incoming NOTIFY requests that are related to the previously sent REFER request in accordance with RFC 3515 [17] as updated by RFC 6665 [10] and may indicate the received information to the user.

NOTE: Additionally, a conference participant can be removed from a conference by other means.

5.3.1.7 Consent to list server distribution

A participant capable of receiving a request to join a conference should support the requirements of a recipient defined in RFC 5360 [36].

5.3.2 Conference Focus

5.3.2.1 General

In addition to the procedures specified in subclause 5.3.2, the conference focus shall support the procedures specified in 3GPP TS 24.229 [5] appropriate to the functional entity in which the conference focus is implemented. When performing 3rd party call control the conference focus shall follow the procedures of subclause 5.7.5 of 3GPP TS 24.229 [5].

5.3.2.2 Generic procedures for all conference related methods at the conference focus

5.3.2.2.1 Conference focus originating case

The conference focus shall follow the procedures of 3GPP TS 24.229 [5] subclause 5.7.3 when acting as an originating UA.

5.3.2.2.2 Conference focus terminating case

Upon receipt of a conference related initial request, the conference focus shall follow the procedures of 3GPP TS 24.229 [5] subclause 5.7.1.2 in relation to the contents of the P-Charging-Function-Addresses header and the P-Charging-Vector header.

When creating the first response for this initial request, the conference focus shall:

1) include the P-Charging-Vector header including:

a) the value of the icid parameter as received in the initial request;

b) the value of the orig-ioi parameter as received in the initial request; and

c) the term-ioi parameter, indicating the network of the conference focus; and

2) include the P-Charging-Function-Addresses header as received in the initial request or, if the P-Charging-Function-Addresses header was not received in the initial request, indicate the values applicable for the conference in the P-Charging-Function-Addresses header.

When creating responses for an initial INVITE request, the conference focus shall additionally send the 200 (OK) response to the initial INVITE request only after the resource reservation has been completed.

5.3.2.3 Conference creation

5.3.2.3.1 Conference creation with a conference factory URI

Upon receipt of an INVITE request that includes a conference factory URI in the request URI, the conference focus shall:

1) check if the conference factory URI is allocated and reject the request in accordance with RFC 3261 [7] if it is not allocated. The following actions in this subclause shall only be performed if the conference factory URI is allocated;

NOTE: The mechanism by which the conference focus gets aware whether a URI is a conference factory URI is out of the scope of the present document. One possibility would be that an operator uses a specific user part (e.g. conference-factory@home1.net) or host part (e.g. conference-factory.home1.net) for identification of conference factory URIs.

2) verify the identity of the user as described in subclause 5.7.1.4 of 3GPP TS 24.229 [5] and authorize the request as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be performed if the request can be authorized;

3) allocate a conference URI and if needed a temporary conference URI; and

4) if "preconditions" were indicated as required in the INVITE request are not satisfied, generate a first provisional response to the INVITE request, indicating the temporary conference URI in the Contact header if allocated, else the conference URI.

At the same time, resources will also be requested from the mixer.

If the conference focus generates any 1xx or 2xx response to the INVITE request, the conference focus shall include the "isfocus" feature parameter in accordance with the procedures of RFC 3840 [19].

Upon receipt of an indication from the mixer that conference resources have been through-connected, the conference focus shall generate a 200 (OK) response to the INVITE request, indicating the "isfocus" feature parameter as a parameter to the conference URI in the Contact header.

5.3.2.3.2 Conference creation with a conference URI

Upon receipt of an INVITE request that includes a conference URI in the request URI and the conference has not been created yet, the conference focus shall:

1) check if the conference URI is allocated reject the request in accordance with RFC 3261 [7] if it is not allocated. The following actions in this subclause shall only be performed if the conference URI is allocated;

3) if a contact header is included in the response, set the contact header to the conference URI. At the same time, resources will also be requested from the mixer.

If the conference focus generates any 1xx or 2xx response to the INVITE request, the conference focus shall include the "isfocus" feature parameter in accordance with the procedures of RFC 3840 [19].

Upon receipt of an indication from the conference mixer that conference resources have been through-connected, the conference focus shall generate a 200 (OK) response to the INVITE request, indicating the conference URI in the Contact header.

5.3.2.4 User joining a conference

5.3.2.4.1 User joining a conference by using a conference URI

Upon receipt of an INVITE request that includes a conference URI in the request URI, the conference focus shall:

1) check if the conference URI is allocated. If the conference URI is not allocated, the conference focus shall reject the request in accordance with RFC 3261 [7]. The following actions in this subclause shall only be performed if the conference URI is allocated;

3) if a contact header is included in the response, set the contact header to the conference URI.

At the same time, resources will also be requested from the mixer.

If the conference focus generates any 1xx or 2xx response to the INVITE request, the conference focus shall include the "isfocus" feature parameter in accordance with the procedures of RFC 3840 [19].

5.3.2.5 Invitation of users to a conference

5.3.2.5.1 General

The conference focus can invite users to a conference by sending an INVITE request to the user, as described in subclause 5.3.2.5.4. This procedure will be triggered at the conference focus either by a REFER request received from authorized users, that request the conference focus to invite other users to the conference, as described in subclause 5.3.2.5.2, or by the initial INVITE request that creates the conference when it includes a" recipient-list" message body as described in subclause 5.3.2.5.3.

NOTE: Additionally, invitation of users to a conference can be triggered by other means.

Additionally, the conference focus can invite users to a conference by sending a REFER request to the user, as described in subclause 5.3.2.5.5. How these procedures are triggered is outside the scope of this specification.

5.3.2.5.2 Request from a user to invite another user to a conference using a REFER request

Upon receipt of an REFER request that includes:

a) a conference URI in the request URI; and

b) a Refer-To header including:

– a valid SIP URI or tel URL; and,

– the "method" parameter either set to "INVITE" or omitted;

NOTE: If the "method" URI parameter is omitted, the conference focus assumes that the method is INVITE.

the conference focus shall:

3) generate a final response to the REFER request in accordance with RFC 3515 [17] as updated by RFC 6665 [10];

4) invite the user indicated in the Refer-To header by performing the procedures as described in subclause 5.3.2.5.4;

5) if the received REFER request included a Referred-By header, include the Referred-By header in accordance with RFC 3892 [20] in the INVITE request that is sent for inviting the user to join the conference;

5a) if the received REFER request included a Replaces header, include the Replaces header in accordance with RFC 3891 [33] and 3GPP TS 24.229 [5] in the INVITE request that is sent for joining the conference; and

6) based on the progress of this invitation, send NOTIFY messages in accordance with the procedures of RFC 3515 [17] as updated by RFC 6665 [10] towards the user who sent the REFER request.

5.3.2.5.3 Request from a user to invite another user to a conference using an INVITE request for conference creation

Upon receipt of an INVITE request for conference creation (see subclause 5.3.2.3) after receiving a valid "recipient-list" as defined in RFC 5366 [34], the conference focus shall, in addition to the procedures described in subclause 5.3.2.3, perform following actions:

1) support the procedures of RFC 5360 [36] associated with such a URI list. The conference focus shall act as the relay and may act as a store and forward server as defined in RFC 5360 [36]; and

2) send an INVITE request to each of the SIP URIs contained in the URI list that is embedded in the message body of the INVITE request for conference creation, by following the procedures in subclause 5.3.2.5.4.

The invitation of the users whose SIP URIs are included in the URI list should be initiated by the conference focus in parallel, since the objective of using the URI-list method of inviting users to a conference is usually a fast conference set-up. However, in case the conference focus is not able to keep track of multiple parallel invitations associated to a single conference the conference focus may issue the invitations serially.

Sending of the multiple invitations should be initiated by the MRFC/AS as soon as a conference URI for the conference has been created, and should run in parallel to the procedure described in subclause 5.3.2.3 in order to speed up conference establishment. If establishment of a session to any of the invitees fails, the further actions depends on local policy whether the conference will continue with the accepted participants or release the whole conference.

If the conference focus is included in the signalling path between the conference creator and the invited user as a B2B UA, and

– if the URIs in the URI list contain a Session-ID header field, the focus shall verify if the Session ID information matches to a partial dialog between the focus and the conference creator; else

– if the URIs in the URI list contain Call-ID header field, From header field and To header field, the focus shall verify if this dialog ID information matches to a partial dialog between the focus and the conference creator.

In the case of a match the focus may use this information to send re-INVITE request in the partial dialogs between the focus and the invited users in order to connect the media of the invited users to the MRFP.

In the case of no match the focus shall discard Call-ID header field, From header field, To header field and Session-ID header field form the URIs in the URI list, if those header fields are included.

5.3.2.5.4 Inviting a user to a conference by sending an INVITE request

When generating an INVITE request in order to invite a user to a specific conference, the conference focus shall:

1) set the request URI of the INVITE request to the address of the user who is invited to the conference;

2) set the P-Asserted-Identity header of the INVITE request to the conference URI of the conference that the user shall be invited to;

3) set the Contact header of the INVITE request to the conference URI of the conference that the user shall be invited to, including the "isfocus" feature parameter;

4) if the INVITE request is generated due to a received REFER request from another conference participant and that received REFER request included a Referred-By header, include the Referred-By header in accordance with RFC 3892 [20] in the INVITE request;

4a) if the INVITE request is generated due to a received REFER request from another conference participant and the received REFER request included a Replaces header, include the Replaces header in accordance with RFC 3891 [33] and 3GPP TS 24.229 [5] in the INVITE request;

5) send the INVITE request towards the user who is invited to the conference.

NOTE 1: The conference focus will request the resources required for the new user from the conference mixer.

NOTE 2: Requests are generated in accordance with 3GPP TS 24.229 [5].

Afterwards the conference focus shall proceed the session establishment as described in 3GPP TS 24.229 [5].

5.3.2.5.5 Inviting a user to a conference by sending a REFER request

When generating a REFER request in accordance with the procedures specified in 3GPP TS 24.229 [5], IETF RFC 3515 [17] as updated by IETF RFC 6665 [10] and IETF RFC 7647 [39] in order to invite a user to a specific conference, the conference focus shall:

1) set the request URI of the REFER request to the address of the user who is invited to the conference;

2) set the P-Asserted-Identity header of the REFER request to the conference URI of the conference that the user shall be invited to;

3) set the Refer-To header of the REFER request to the conference URI of the conference that the other user shall be invited to, and either including the "method" URI parameter set to "INVITE" or omitting the "method" URI parameter; and

NOTE 1: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5].

4) send the REFER request towards the user who is invited to the conference.

NOTE 2: Requests are generated in accordance with 3GPP TS 24.229 [5].

Afterwards the conference focus shall treat incoming NOTIFY requests that are related to the previously sent REFER request in accordance with RFC 3515 [17] as updated by RFC 6665 [10].

5.3.2.6 Leaving a conference

5.3.2.6.1 Conference participant leaving a conference

Upon receipt of a BYE message from a conference participant, the conference focus shall:

1) respond to the BYE request as described in 3GPP TS 24.229 [5] and RFC 3261 [7]; and

2) release the resources, related to the conference participant from the conference mixer.

5.3.2.6.2 Removing a conference participant from a conference

5.3.2.6.2.1 General

The conference focus can remove a conference participant from a conference by terminating the dialog with the conference participant. This is done by sending a BYE request to the participant, as described in subclause 5.3.2.6.2.3. The removal of a conference participant by the conference focus will be triggered:

1) by a REFER request received from authorized users, that request the conference focus to remove the conference participant from the conference, as described in subclause 5.3.2.6.2.2; or

2) by local administration procedures.

NOTE: Additionally, a conference participant may be removed from a conference by other means.

5.3.2.6.2.2 Request from a conference participant to remove another conference participant from a conference

Upon receipt of a REFER request that includes:

a) a conference URI in the request URI; and,

b) a Refer-To header including:

1) a valid SIP URI; and

2) the "method" parameter set to "BYE".

The conference focus shall:

1A) if the SIP URI contains a user parameter that equals "phone" and if the SIP URI of the Refer-To header can be converted to a global tel URI as described in RFC 3261 [7], convert the SIP URI to the equivalent global tel URI. Verify that the tel URI belongs to user who is currently a participant of the referenced conference. If this verification fails, then reject the request in accordance with RFC 3261 [7] and RFC 3515 [17] as updated by RFC 6665 [10];

2) check if the SIP URI of the Refer-To header is identical to the conference URI or belongs to a user who is currently a participant of the referenced conference. If this verification fails, then reject the request in accordance with RFC 3261 [7] and RFC 3515 [17] as updated by RFC 6665 [10];

3) verify the identity of the user as described in subclause 5.7.1.4 of 3GPP TS 24.229 [5] and authorize the request as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be performed if the request can be authorized;

4) generate a final response to the REFER request in accordance with RFC 3515 [17] as updated by RFC 6665 [10];

5) if a single conference participant is indicated in the Refer-To header, remove this conference participant from the conference according to subclause 5.3.2.6.2.3. If the Refer-To header includes the conference URI, remove all conference participants from the conference by performing the procedures described in subclause 5.3.2.6.2.3 for each conference participant individually; and

6) based on the progress of this removal, send NOTIFY messages in accordance with the procedures of RFC 3515 [17] as updated by RFC 6665 [10] towards the conference participant who sent the REFER request.

5.3.2.6.2.3 Conference focus removes conference participant from a conference

When removing a conference participant from a conference, the conference focus shall:

1) generate a BYE request on the dialog that was established when the conference participant joined or created the conference, in accordance to the procedures described in 3GPP TS 24.229 [5] and RFC 3261 [7];

2) release the resources, related to the conference participant from the conference mixer.

5.3.2.7 Conference termination

A conference shall be terminated by the conference focus:

1) when the conference has been created by means of the procedure described in subclause 5.3.2.5.3 and session establishment to one or more of the invitees has failed; or

2) when the conference policy dictates it; or

3) when no dedicated rules for conference termination exist in the conference policy; and:

– either the conference was created with a conference factory URI and the conference creator has left the conference; or

– the last conference participant has left or has been removed from the conference.

NOTE: How the conference policy can be created or changed is out of the scope of this specification.

To terminate an existing conference, the conference focus shall:

1) remove all present conference participants from the conference by performing the procedures as described in subclause 5.3.2.6.2.3 for each participant individually; and

2) deallocate the conference URI.

5.3.3 Conference Notification Service

5.3.3.1 General

In addition to the procedures specified in subclause 5.3.3, the conference notification service shall support the procedures specified in 3GPP TS 24.229 [5] appropriate to the functional entity in which the conference notification service is implemented.

5.3.3.2 Subscription to conference event package

Upon receipt of a SUBSCRIBE request that includes a conference URI in the request URI and the "conference" tag in the Event header, the conference notification service shall:

1) check if the conference URI is allocated and reject the request in accordance with RFC 3261 [7] if it is not allocated. The following actions in this subclause shall only be performed if the conference URI is allocated;

2) verify the identity of the user as described in subclause 5.7.1.4 of 3GPP TS 24.229 [5] and authorize the request as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions shall only be performed if the request can be authorized; and

3) establish the subscription to the conference state event information as described in RFC 6665 [10] and RFC 4575 [11].

5.3.3.3 Leaving a conference

When generating a NOTIFY request with conference state event information that is destined to a subscriber that has either left the conference or was removed from it, the conference notification service shall, include in the NOTIFY request a Subscription-State header with the value "terminated" in accordance with RFC 6665 [10].

5.3.3.4 Conference termination

The conference notification service shall terminate all subscriptions to the conference event package in accordance with RFC 4575 [11] when the conference is terminated, as described in subclause 5.3.2.7.