4 CONFerence (CONF)

24.5053GPPProtocol specificationPSTN/ISDN simulation services: Conference (CONF)Release 8TISPANTS

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.

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 TS 124 147 [7], clause 5.

4.5 Signalling requirements

4.5.1 Activation/deactivation/registration

Not applicable.

4.5.2 Invocation and operation

This clause describes the usage of and the changes to the procedures of TS 124 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 TS 124 147 [7], clause 5.3.1.4 shall apply.

4.5.2.1.2 User inviting another user to a conference

Procedures according to TS 124 147 [7], clause 5.3.1.5 shall apply with the following additions to clause 5.3.1.5.3 of
TS 124 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 TS 124 147 [7] , clause 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 TS 183 028 [11] sub clause 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 TS 124.147 [7], clause 5.3.1.6 shall apply.

4.5.2.1.4 User creating a conference

Procedures according to TS 124.147 [7], clause 5.3.1.3 shall apply.

4.5.2.1.5 Subscription for the conference event package

Procedures according to TS 124.147 [7], clause 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 TS 124 147 [7] , clauses 5.3.2 and 6.3.2 shall apply with the following additions to clause 5.3.2.5.2 of TS 124 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 REFER request’s P-Asserted-Identity.

If no Referred-By header is available in the request, the AS shall add a Referred-By header that matches the REFER request’s P-Asserted-Identity.

The procedures described in clause 5.3.2.5.5 of TS 124 147 [7] shall not apply.

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
TS 124.147 [7], clause 5.3.3 shall apply.

4.5.2.3 Actions at the incoming I-CSCF

Basic communication procedures according to ES 283 003 [2] shall apply.

4.5.2.4 Actions at the outgoing IBCF

Basic communication procedures according to ES 283 003 [2] shall apply.

4.5.2.5 Actions at the incoming IBCF

Basic communication procedures according to ES 283 003 [2] shall apply.

4.5.2.6 Actions at the destination P-CSCF

Basic communication procedures according to ES 283 003 [2] shall apply.

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 Actions at the MGCF

Procedures according to TS 124 147 [7] , clause 5.2.4 shall apply.

NOTE: In the case of an interworking a request to a PSTN user to dial into a conference (by means of sending a REFER request to the PSTN user) will result in a 403 Forbidden response from the MGCF.

4.5.2.9 Actions at the S-CSCF

Basic communication procedures according to ES 283 003 [2] shall apply.

4.6 Interaction with other supplementary services

4.6.1 Communication HOLD (HOLD)

No impact, i.e. neither service shall affect the operation of the other service.

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 Privacy header field is set to "header" or "user", then for the INVITE request to the refer-to target, the conference AS shall:
  1. not insert Referred-by header field, if it does not exist in the REFER request; or
  2. remove Referred-By header field, if Privacy header field of the REFER request set to "user".
  • If an INVITE request with "recipient-list" body is received, and if 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.7 Interworking with other networks

4.7.1 Interworking with PSTN/ISDN

The procedures of TS 129 163 [10] shall apply with the additions of ES 283 027 [9] and the additions in clause 4.7.1.1.

4.7.1.1 Interworking between the IMS conference status notifications and the notification messages of the PSTN/ISDN CONF supplementary service

In this clause the interworking from the conference event package RFC 4575 [3] to the messages of the PSTN/ISDN CONF supplementary service is described. Note that an interworking from the PSTN/ISDN to the NGN is out of scope.

4.7.1.1.1 Procedures at the MGCF

4.7.1.1.1.1 Subscribing for the conference event package

Based on local policy, the MGCF may subscribe for the conference event package on behalf of the PSTN/ISDN participant after he joins or is added to a conference.

When the conference event package option is implemented, and one of the following events occurs at the MGCF:

  • A 200 OK is received as a response to an initial INVITE request originated by the MGCF, where the Contact header field contains an "isfocus" parameter; or
  • An ACK message is received which acknowledges a 200 OK response to the initial INVITE request, and the initial INVITE request is originated by the conferencing AS and contains an "isfocus" parameter in the Contact header field.

Then the following steps shall be performed:

  1. A SUBSCRIBE request shall be created according to RFC 4575 [3];
  2. The request URI is set to the Contact address of the conferencing AS;
  3. The P-Asserted-Identity header field, the From header field and the Privacy header field are set with the same value as:
  • the P-Asserted-Identity header field, the From header field and the Privacy header field in the initial INVITE request originated by the MGCF; or
  • the P-Asserted-Identity header field, the To header field and the Privacy header field in a 1xx or 2xx response sent by the MGCF to the initial INVITE request from the conferencing AS.

4.7.1.1.1.2 Interworking the Notification

NOTE: There is a need to differentiate between the procedures of interworking for a full and a partial type of notification.

When a full type of notification is received a check is made of the content. If the changes with respect a previous version of the notification have not been sent on to the PSTN/ISDN for this session, the MGCF shall do an ISUP interaction towards the PSTN. If the changes with respect a previous version of the notification have been sent to the PSTN/ISDN for this session, the MGCF shall not do an ISUP interaction towards the PSTN.

When a partial notification is received then it is assumed that a value of a received notification has changed, so the MGCF shall do an ISUP interaction towards the PSTN.

  • Conference established:

Upon the receipt of a conference information document with the <conference-state-type> element active is set to "true", the MGCF shall send a CPG message to the CS side with a notification "conference established".

  • Participant added:

Upon the receipt of a conference information document with the <endpoint-type> and the element status of endpoint‑status-type is set to "connected" and it was not set to "on-hold" before and the Contact URI in the element entity is not the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the CS side with a notification "other party added".

  • Served PSTN/ISDN participant isolated:

Upon the receipt of a conference information document with the <endpoint-type> and the element status of endpoint‑status-type is set to "on-hold" and it was set to "connected" before and the Contact URI in the element entity is the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the CS side with a notification "isolated".

  • Other participant isolated:

Upon the receipt of a conference information document with the <endpoint-type> and the element status of endpoint‑status-type is set to "on-hold" and it was set to "connected" before and the Contact URI in the element entity is not the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the CS side with a notification "other party isolated".

  • Served PSTN/ISDN participant reattached:

Upon the receipt of a conference information document with the <endpoint-type> and the element status of endpoint‑status-type is set to "connected" and it was set to "on-hold" before and the Contact URI in the element entity is the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the CS side with a notification "reattached".

  • Other participant reattached:

Upon the receipt of a conference information document with the <endpoint-type> and the element status of endpoint‑status-type is set to "connected" and it was set to "on-hold" before and the Contact URI in the element entity is not the address of the served PSTN/ISDN participant, the MGCF shall send a CPG message to the CS side with a notification "other party reattached".

  • Other party disconnected:

Upon the receipt of a conference information document with the <endpoint-type> and the element status of endpoint‑status-type is set to "disconnected" and the element joining-method of joining-type is not set to "focus-owner, the MGCF shall send a CPG message to the CS side with a notification "other party disconnected".

4.7.2 Interworking with PSTN/ISDN Emulation

The interworking with PSTN/ISDN Emulation is for further study.

4.7.3 Interaction with external IP network

For SIP based networks the procedures used shall be compliant with ES 283 003 [1].

The interworking with non SIP networks is for further study.

4.8 Parameter values (timers)

Not applicable.

Annex A (informative):
Signalling flows