4 CONFerence (CONF)
24.6053GPPConference (CONF) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 18TS
4.1 Introduction
The CONFerence (CONF) service enables a user to participate in and control a simultaneous communication involving a number of users.
4.2 Description
4.2.1 General description
When the CONF service is invoked, conference resources are allocated to the served user.
Once a conference is active, users can join and leave a conference, and remote users can be added to or removed from the conference.
Conference participants can request to be informed of these actions.
The Management Object as defined in 3GPP TS 24.166 [14] provides a mechanism for the UE to discover the Conference Factory URI to be used for the CONF service. If the UE is not configured with the Conference Factory URI within the Management Object then the UE shall derive a Conference Factory URI for MMTEL as described in subclause 13.10 of 3GPP TS 23.003 [15] to be used for the CONF service.
NOTE: Depending on the network operator, various mechanisms can be applied to discover the Conference Factory URI (e.g., include the Conference Factory URI in a letter written to the user or publish it on a website). A derived Conference Factory URI might not be a valid URI.
4.3 Operational requirements
4.3.1 Provision/withdrawal
The CONF service shall be provided after prior arrangement with the service provider.
4.3.2 Requirements on the originating network side
No specific requirements are needed in the network.
4.3.3 Requirements in the network
No specific requirements are needed in the network.
4.3.4 Requirements on the terminating network side
No specific requirements are needed in the network.
4.4 Coding requirements
For coding requirements see 3GPP TS 24.147 [7], clause 5.
4.5 Signalling requirements
4.5.1 Activation/deactivation
The CONF service is activated at provisioning and deactivated at withdrawal.
4.5.1a Registration/erasure
The CONF service requires no registration. Erasure is not applicable.
4.5.1b Interrogation
Interrogation of CONF is not applicable.
4.5.2 Invocation and operation
This subclause describes the usage of and the changes to the procedures of 3GPP TS 24.147 [7] for invoking and operating a conference.
4.5.2.1 Actions at the originating UE
4.5.2.1.1 User joining a conference
Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.4 shall apply.
4.5.2.1.2 User inviting another user to a conference
Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.5 shall apply with the following additions to subclause 5.3.1.5.3 of 3GPP TS 24.147 [7]:
– A UE that has initiated an emergency call, shall not perform any procedures to add the remote user in that call to a conference.
– In order to avoid the establishment of a second communication to the invited user, 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 of the REFER request. The included Replaces header shall refer to the active dialog that is replaced by the ad-hoc conference. The Replaces header shall comply with RFC 3891 [8].
NOTE 1: In case of an interworking to the PSTN the routing of the INVITE request from the conference focus to the MGCF that handles the Replaces information is not deterministic and the replacement of the active dialog might fail.
EXAMPLE: Refer-To: <sip:mgcf1.home1.net; method=INVITE?Replaces=cb03a0s09a2sdfglkj490333%3Bto-tag%3D 314159%3Bfrom-tag%3D171828&Requrie=replaces >.
NOTE 2: If a conference participant invites another user to a conference by using a REFER request targeted at the other user (following 3GPP TS 24.147 [7] , subclause 5.3.1.5.2), there can be cases where such REFER request is intercepted by an AS serving the requesting user which applies special REFER handling procedures according to 3GPP TS 24.628 [11] subclause 4.7.2.9.7.2. The consequence of this is that the conference focus AS will receive an INVITE from the referrers AS and not from the targeted user. This however does not affect the conference focus procedures in any way.
4.5.2.1.3 User leaving a conference
Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.6 shall apply.
4.5.2.1.4 User creating a conference
Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.3 shall apply.
4.5.2.1.5 Subscription for the conference event package
Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.2 shall apply.
4.5.2.2 Actions at the conferencing AS
4.5.2.2.1 Conference focus
Procedures according to 3GPP TS 24.147 [7], subclauses 5.3.2 and 6.3.2 shall apply with the following additions to subclause 5.3.2.5.2 of 3GPP TS 24.147 [7]:
– If a Referred-By header is available in the REFER request, the AS shall verify if the provided Referred-By header contains a valid identity of the requesting user. If not, the AS shall replace the Referred-By header with a valid value matching the P-Asserted-Identity header in the REFER request.
– If no Referred-By header is available in the request, the AS shall add a Referred-By header that matches the P-Asserted-Identity header in the REFER request.
The procedures described in subclause 5.3.2.5.5 of 3GPP TS 24.147 [7] shall not apply.
4.5.2.2.1A Void
4.5.2.2.2 Conference notification service
In case of the subscription of a conference participant to the conference notification service, procedures according to 3GPP TS 24.147 [7], subclause 5.3.3 shall apply.
4.5.2.2A Procedures at the AS serving the originating user
4.5.2.2A.1 General
Upon receiving a REFER request in an existing dialog or outside of an existing dialog containing a Target-Dialog header field identifying an existing dialog, from a user involved also in a conference, the AS serving the originating user shall first check that the REFER request is valid:
– the Request-URI in the REFER request is targeted to the same UE instance (remote UE) that is involved in the dialog; and
– the Refer-To header in the REFER request contains an URI so that the method constructed from the URI is equal to an INVITE request to the Conference focus.
Otherwise, the AS may, depending on operator policy:
– reject the REFER request; or
– handle the REFER request with another service; or
– proxy the REFER request on.
If any of the following is true:
– the dialog on which the REFER request is received or the dialog which is identified by the Target-Dialog header field in the REFER request, was that established by an initial INVITE request that was identified as a PSAP callback request; or
– the Refer-To header field in the REFER request contains a URI with which the referor is involved in a dialog where the initial INVITE request was identified as a PSAP callback request.
the AS shall based on local policy on how to handle PSAP callbacks reject the REFER request.
The mechanism to identify an INVITE request as a PSAP callback depends on local policy and can be based on the PSAP callback indicator specified in IETF RFC 7090 [13].
If the AS determines that the REFER request shall not be sent to the remote UE and the AS decides to apply 3pcc the AS shall follow the special REFER request handling procedures in 3GPP TS 24.628 [11] with the following addition:
– the AS shall include the "isfocus" header field parameter in the Contact header field in the INVITE request sent towards the remote UE.
4.5.2.2A.2 Priority handling
For the following conditions:
– the AS serving the originating user supports priority; and
– the originating user is authorized for priority, according to operator policy, for a call that can possibly be replaced by an ad-hoc conference;
the following shall apply:
– if an active dialog that can possibly be replaced by an ad-hoc conference contains a Resource-Priority header field, the AS shall store the Resource-Priority header field value and sufficient dialog details (e.g., the dialog ID, P-Asserted-Identity header field value and the Request-URI value) to correlate the dialog with a subsequent conference;
– if the AS decides to apply 3pcc for a REFER request that pertains to an existing priority dialog that is to be replaced by an ad-hoc conference, the AS shall add the stored Resource-Priority header field value to the outgoing INVITE requests resulting from the special REFER request handling procedures in 3GPP TS 24.628 [11]. After establishing the conference leg, the AS sends an UPDATE request or a re-INVITE request to the originating user with the Resource-Priority header field;
– upon receiving a REFER request that pertains to an existing priority dialog that is to be replaced by an ad-hoc conference and the REFER request includes a conference URI in the Request-URI, the AS shall add the stored Resource-Priority header field value to the REFER request and to the Refer-To header field in accordance with the procedures for adding header fields ("?" mechanism) described in subclause 19.1.1 of RFC 3261 [16] prior to forwarding the REFER request toward the conference AS; and
– if the AS receives an INVITE request that includes a conference URI in the Request-URI, and a "recipient‑list" message body, then for each URI in the "recipient-list" that pertains to an existing priority dialog that is to be replaced by an ad-hoc conference, the AS shall add the stored Resource-Priority header field value to the URI in the "recipient-list", in accordance with the procedures for adding header fields ("?" mechanism) described in subclause 19.1.1 of RFC 3261 [16]. If the AS has added a Resource-Priority header to any of the URIs in the "recipient-list", then the AS inserts the Resource-Priority header field in the outgoing INVITE request.
4.5.2.3 Void
4.5.2.4 Void
4.5.2.5 Void
4.5.2.6 Void
4.5.2.7 Actions at the destination UE
Upon receipt of an INVITE request that includes a Replaces header, the UE shall apply the procedures described in RFC 3891 [8] to the INVITE request.
4.5.2.8 Void
4.5.2.9 Void
4.6 Interaction with other services
4.6.1 Communication HOLD (HOLD)
The AS supporting the CONF service shall support the procedures for the held UE as specified in 3GPP TS 24.610 [12]
4.6.2 Terminating Identification Presentation (TIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.3 Terminating Identification Restriction (TIR)
For the conferencing AS implementing the conference focus, the following applies:
– If a participant is added to the conference and if TIR is active for the terminating party of this session, then the identity information of that participant shall not be included in conference notifications to other participants.
4.6.4 Originating Identification Presentation (OIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.5 Originating Identification Restriction (OIR)
For the conferencing AS implementing the conference focus, the following applies:
– If a participant joins the conference and if OIR is active for the originating party of this session, then the identity information of that participant shall not be included in conference notifications to other participants.
– If a REFER request is received and if the Privacy header field is set to "header" or "user", then for the INVITE request to the refer-to target, the conference AS shall:
a) not insert the Referred-by header field, if it does not exist in the REFER request; or
b) remove the Referred-By header field, if the Privacy header field of the REFER request is set to "user".
– If an INVITE request with "recipient-list" body is received, and if the Privacy header field is set to "user", then the conference AS shall anonymize the From header field of resulting reINVITE request, if there is established dialog between the conference controller and the target of the reINVITE request.
4.6.6 CONFerence calling (CONF)
Not applicable.
NOTE: Cascading conference services are out of scope of the present specification.
4.6.7 Communication DIVersion services (CDIV)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.8 Malicious Communication IDentification (MCID)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.9 Anonymous Communication Rejection and Communication Barring (ACR/CB)
The focus AS shall not accept REFER requests with a refer-to target that is barred by the conference creators Outgoing Communication Barring (OCB) rules.
The focus AS shall remove the URI that is barred by the conference creator Outgoing Communication Barring (OCB) rules from the list of URIs in the "recipient-list" body of INVITE request.
4.6.10 Explicit Communication Transfer (ECT)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.11 Multi-Device (MuD)
No impact.
4.6.12 Multi-Identity (MiD)
No impact.
4.7 Interworking with other networks
4.7.1 Void
4.7.2 Void
4.7.3 Void
4.8 Parameter values (timers)
Not applicable.
Annex A (informative):
Signalling flows