B.2.2 Example information flow for a UE-originating IP multimedia ad-hoc conferencing session (multiparty call)

23.2183GPPIM call modelIP Multimedia (IM) session handlingRelease 17Stage 2TS

Figure B.2.1.1 shows an example of an ad hoc conference (multiparty call). An AS (acting as B2BUA) performs third party call control with the MRFC, where the S-CSCF is in the signalling path.

The "[x]" notation in the figure is an indicator of a unique SIP dialog. The "dot" notation on the AS line indicates B2BUA actions are taking place along with AS service logic. The 100 (Trying) responses are not shown in the figure, but it is assumed that a 100 (Trying) response is sent in response to each INVITE request.

The Application Server is in control of the ad hoc conference, is aware of the MRFC capabilities and is also operating as a B2BUA performing third party call control.

An INVITE request is generated from UE-1 indicating a desire to start a multiparty call (ad hoc conference) by taking the existing sessions, between UE-1 to UE-2 and UE-1 to UE-3, and bringing them together. The AS uses third party call control to request the conference facilities from the MRFC. A separate dialog is established from the AS to the MRFC for each of the three parties (UE-1, UE-2, UE-3). New dialogs are also established between the AS and each of the UE endpoints. The media from each UE is connected at the conferencing resource at the MRFP. The first INVITE request to the MRFC should contain a unique conference identifier. The same conference identifier will be used for subsequent INVITE requests to add or drop parties to the conference.

The offer/answer model as defined in IETF RFC 3264 [15] is used for SDP negotiation between the AS/S-CSCF and the MRFC. The MRFC should always grant the requests from the AS (unless there is a resource problem). The MRFC responds to the INVITE request with a 200 (OK) response indicating the selected media in the SDP. The MRFC will also reserve the requested local resources at that time and return the appropriate resource identifiers in the 200 (OK) response.

Figure B.2.2.1: Ad hoc conference call flow

Notes for figure B.2.2.1:

1) INVITE request received at S-CSCF from UE-1 indicating desire to start ad hoc conference (multiparty call) for the existing sessions between UE-1 to UE-2 and UE-1 to UE-3.

2) 100 (Trying) response returned.

3) INVITE request forwarded to AS.

4) AS performs service logic and allows attempt to start ad hoc conference.

5 – 8) New INVITE request sent to MRFC with a unique conference identifier to initiate multiparty call, and prepare dialog for UE-2 [Call-ID 2].

9 – 13) ReINVITE request sent to UE-2 to establish dialog between AS and UE-2 [Call-ID 3].

14 – 17) ACK request sent for Call-ID 2 and Call-ID 3.

18 – 21) New INVITE request sent to MRFC using the same conference identifier and prepare dialog for UE-3 [Call-ID 4].

22 – 26) ReINVITE request sent to UE-3 to establish dialog between AS and UE-3 [Call-ID 5].

27 – 30) ACK request sent for Call-ID 4 and Call-ID 5.

31 – 34) New INVITE request sent to MRFC using the same conference identifier and prepare dialog for UE-1 [Call-ID 6].

35 – 36) 200 (OK) response returned to UE-1 with SDP.

37) The session is established.

38 – 41) ACK request sent for Call-ID 1 and Call-ID 6.