Content for  TS 23.218  Word version:  18.0.0

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 RFC 3264 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.

Notes for Figure B.2.2.1: