6.2.10 Multimedia Conference Procedures

23.3333GPPMultimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface: Procedures descriptionsRelease 17TS

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

6.2.10.1 Context Model

A conference consists of one context with terminations representing connections to the participants. Each termination shall support up to three streams, one for audio, one for messaging and one for video. The MRFP shall consider the context to represent an ad-hoc conference when three or more terminations have been through-connected.

It is possible for a user supporting only one media, represented by one stream, to join a conference. The user will then only participate in the part of the conference that is using the supported stream.

6.2.10.2 Ad-hoc Conferences

6.2.10.2.1 General

An ad-hoc conference starts without any prior booking or reservation when a user initiates the conference, for further definition of ad-hoc conference, see 3GPP TS 24.147 [4]. Further participants can then be added to the conference without any prior reservation of resources, through either a method of "dial-out" where the conference calls the participant, or by a "dial-in" scenario where the end user calls the conference.

6.2.10.2.2 Create Ad-hoc Multimedia Conference Procedure

The MRFC receives a trigger to create an ad-hoc conference. The MRFC then initiates the "Reserve and Configure IMS Resources" procedure as specified in clause 8.20, where the connection address and resources shall have multiple values for speech, messaging and video.

The MRFC:

Requests a new context and a new bearer termination including the Remote Connection Addresses.

The MRFP:

Creates a new context

Adds a new termination to the context and returns the Local Connection Address.

The MRFC:

Notifies the new user about the Local Connection Address.

Figure 6.2.10.1 shows the message sequence chart example for creating multimedia conference procedure.

Figure 6.2.10.1 Create Ad-hoc conference

6.2.10.2.3 Closure of Multimedia Conference Procedure

The MRFP will in accordance with the general rules of H.248.1 delete the context when the last termination has been subtracted from the context..

6.2.10.2.4 Add Subsequent User to Conference; Dial-out

Precondition for this procedure is that a conference exists. The MRFC receives a trigger to add a new bearer termination. The trigger does not contain connection address nor resources that the new participant can use. The MRFC adds a new bearer termination by initiating the "Reserve IMS Resources" procedure as specified in clause 8.21 where the connection address and resources may have multiple values for speech, messaging and video.

The MRFC:

Requests a bearer termination to be added to the existing context.

The MRFP:

Adds a bearer termination to the existing context and notifies the MRFC about its reserved resources and connection address.

The MRFC:

Sends a notification to the new user about the MRFP’s resources and connection address.

The MRFC will then receive a trigger containing the new user’s address and resources. The MRFC initiates the "Configure IMS resources" procedure as specified in clause 8.22 where the connection address and resources may have multiple values for speech, messaging and video.

The MRFC:

Requests that remote address and resources be configured to the termination

The MRFP:

Modifies the termination using the received data and confirms the action

The MRFC:

Notifies the new participant about the result

Figure 6.2.10.2 shows the message sequence chart example for dial-out procedure of multimedia conference.

Figure 6.2.10.2 Procedure to add user in Dial-out scenario

6.2.10.2.5 Add subsequent user to conference; Dial-in

Precondition is that a conference exists. The MRFC receives a trigger to add a new user including Remote Connection Address. The MRFC then initiates the "Reserve and Configure IMS Resources" procedure as specified in clause 8.20 where the connection address and resources may have multiple values for speech, messaging and video.

The MRFC:

Requests a new bearer termination, including the Remote Connection Address, to be added to the existing context.

The MRFP:

Adds a new termination to the existing context and returns the Local Connection Address.

The MRFC notifies the new user about the Local Connection Address.

Figure 6.2.10.3 shows the message sequence chart example for dial-in procedure of multimedia conference.

Figure 6.2.10.3 Procedure to add user in Dial-in scenario

6.2.10.2.6 Remove Conference Participant Procedure

When the MRFC receives a trigger that a user has left the conference, it initiates the "Release IMS termination" procedure as specified in clause 8.23.

The MRFC:

Requests that the termination is released.

The MRFP:

Releases the termination and informs the MRFC about the result.

Figure 6.2.10.4 shows the message sequence chart example for removing multimedia conference participant procedure.

Figure 6.2.10.4 Procedure to remove conference participant

6.2.10.2.7 Create Ad-hoc Multi-stream Multiparty Conference Procedure

6.2.10.2.7.1 Context Model

Figure 6.2.10.2.7.1.1 shows an example of H.248 Context model for a multi-stream multiparty conference when the MRFC and the MRFP support the MMCHM feature and the floor control server functionality is embedded in the MRFP. Four users (A, B, C and D) participate in a conference and each user supports simulcast sending of a main video (one RTP video stream in high resolution and the other RTP video stream in low resolution), sending and receiving of a screenshare video, and a floor control using BFCP over TCP. In addition, the user A and the user D support receiving of one thumbnail video, and the user B and the user C support receiving of two thumbnail videos. The users A, B and C support simulcast sending of two audio RTP streams which are encoded using different codecs (e.g. one RTP audio stream is AMR-WB encoded and the other EVS encoded).

A conference consists of one context with terminations representing connections to the users. Each termination within the context supports: one audio media stream (S1), one video media stream for main video (S2), one video media stream for screenshare video (S3), one or more video media streams for thumbnail videos (S4 and S5), and one media stream for floor control protocol signalling (S6).

Video media streams S2 are configured with simulcast property and supports 3 simulcast RTP video streams: two simulcast RTP video streams (SC1 and SC3) with "recv" property and one RTP video stream (SC2) with "send" property towards the users. Video media streams S3 for screenshare video are configured with "sendrecv" property. Video media streams S4 and S5 for thumbnail videos are configured with "sendonly" property towards the users. In addition, video media streams S2, S3, S4 and S5 are configured with "RTP-level pause and resume" property.

In the example shown in figure 6.2.10.2.7.1.1 audio media streams S1 on terminations T2 and T3 are configured with:

– simulcast property and supports 3 simulcast RTP audio streams: two simulcast RTP audio streams (SC1 and SC3) with "recv" property and one RTP audio stream (SC2) with "send" property towards the users; and

– "RTP-level pause and resume" property.

Media stream S6 for floor control protocol signalling (BFCP over TCP) is configured with two separate floors: floor FL1 is used to control the audio and the main video (and thus associated with media streams S1 and S2) and floor FL2 is used to control the screenshare video (and thus associated with media stream S3).

The MMCMH interworking function (IWF) depicted in the context C1 symbolizes that the MRFP interworks media streams in that context according to the MMCMH policies defined in clause 5.11.3.5.

Figure 6.2.10.2.7.1.1: H.248 Context model for Multi-stream multiparty conference

6.2.10.2.7.2 MMCMH conference establishment procedure using "dial-in" method

The signalling flow shown in figures 6.2.10.2.7.2.1 and 6.2.10.2.7.2.2 gives an example for a multi-stream multiparty conference establishment ("dial-in" conference procedure) when "simulcast" and "RTP-level pause and resume" signalling for media endpoints are supported by the MRFC and the MRFP.

Figure 6.2.10.2.7.2.1: Multi-stream multiparty conference establishment ("dial-in" procedure) with support of "simulcast" and "RTP-level pause and resume"

Figure 6.2.10.2.7.2.2: Multi-stream multiparty conference establishment ("dial-in" procedure) with support of "simulcast" and "RTP-level pause and resume" (message sequence chart continue)

This procedure is identical to that of clause 6.2.10.2.2 apart from the MRFC provides simulcast formats to the MRFP according to 3GPP TS 26.114 [23] annex S, IETF RFC 8853 [57] and IETF RFC 8851 [58], and "RTP-level pause and resume" signalling according to IETF RFC 7728 [62] for multi-stream multiparty conference media handling.

The procedure in the figures 6.2.10.2.7.2.1 and 6.2.10.2.7.2.2 is described step-by-step with an emphasis on the additional aspects for the MRFC and the MRFP of the multi-stream multiparty conference media handling.

1. The MRFC receives a trigger to create an ad-hoc MMCMH conference from the end user (e.g. user A from figure 6.2.10.2.7.1.1). The received SDP offer includes:

a) an audio "m=" line with the "a=simulcast" attribute and the corresponding "a=rid" lines with a "pt" parameter defining the simulcast stream identification (in this example simulcast sending of two audio RTP streams which are encoded using codec1 and codec2 [rid-id values 0 and 2], and reception of one RTP audio stream which may be decoded using codec1 or codec2 [rid-id values 1 or 3]);

b) a video "m=" line with the "a=content:main" attribute, the "a=simulcast" attribute and the corresponding "a=rid" lines with a "pt" parameter defining the simulcast stream identification (in this example simulcast sending of RTP video stream in high resolution [rid-id value 0] and in low resolution [rid-id value 1], and reception of RTP video stream [rid-id value 2] in high resolution, the "a=rtcp-fb" line(s) with a "CCM" parameter, a "pause" CCM parameter and a "nowait" pause attribute;

c) a video "m=" line with the "a=content:slides" attribute indicating sending and receiving of a screenshare video;

d) a video "m=" line with the "a=imageattr" attribute indicating receiving of RTP video stream in low resolution;

e) a BFCP "m=" line indicating support of a floor control client role; and

f) a session level "a=ccc_list" attribute (defined in 3GPP TS 26.114 [23], clause S.5.7.2) with the concurrent codec capabilities of the conference participant.

2. Based on the local configuration and the received session level "a=ccc_list" SDP attribute the MRFC selects the payload type and simulcast formats from the received SDP offer for each accepted audio and video media stream and creates the corresponding media stream identities. The MRFC creates one media stream for floor control protocol signalling. In this example the MRFC creates:

a) one audio media stream (StreamID = 1);

b) one video media stream for main video (StreamID = 2);

c) one video media stream for screenshare video (StreamID = 3);

d) one media stream for thumbnail video (StreamID = 4); and

e) one media stream for floor control using BFCP protocol signalling (StreamID = 6).

3. – 5. The MRFC uses the "Reserve and Configure IMS resources" procedure to request the MRFP to configure resources towards the user and for the accepted audio and video media streams (in this example StreamID values 1, 2, 3 and 4) the MRFC:

a) if the user is the first conference participant, requests the MRFP to create a new context and includes a "MMCMH policy" information element to indicate to the MRFP that the context is used for MMCMH and that the MRFP shall mix RTP media streams autonomously based on the MMCMH policies specified in clause 5.11.3.5;

b) provides an IP address and port received from the user;

c) requests a local IP address and port;

d) includes selected payload types in "Local IMS resources" and "Remote IMS resources" information elements;

e) for the video media streams where the "a=content" attribute was received in the SDP offer, includes in the Local and Remote descriptors a "Stream content" information element with the received "a=content" attribute to indicate content of stream;

f) for the audio and video media streams with the simulcast streams includes in the Local and Remote descriptors a "Simulcast desc" information element (containing the "a=simulcast" attribute) with the selected simulcast streams and request the MRFP to configure termination with a simulcast capability;

g) for the audio and video media streams with the simulcast streams includes in the Local and Remote descriptors a "Simulcast format" information element with the accepted "a=rid" attribute lines;

h) for the audio and video media streams where the "a=rtcp-fb" line(s) with a "CCM" parameter was received in the SDP offer, includes in the Local and Remote descriptors:

– a "CCM pause-resume" information element to indicate to the MRFP which RTCP feedback "CCM PAUSE-RESUME" messages the MRFP may send to the end user;

– if a "nowait" pause attribute was received in the SDP offer, include the "nowait" pause attribute in the "CCM pause-resume" information element to indicate to the MRFP that exchange of the RTCP feedback "CCM PAUSE-RESUME" messages will be point-to-point and no hold-off period will therefore be necessary when resuming paused streams;

– an "Autonomous request" information element to indicate that the MRFP is allowed to autonomously send RTCP feedback CCM PAUSE and RESUME messages; and

– an "Autonomous response" information element to indicate that the MRFP is allowed to autonomously send RTCP feedback CCM PAUSED and REFUSED messages; and

i) for the video media streams where the "a=imageattr" attribute was received in the SDP offer, includes a "Generic image attribute" information element in accordance to procedure specified in clause 6.2.17; and

j) includes in the Remote descriptor a "Concurrent Codec Capabilities" information element to indicate the concurrent codec capabilities of the conference participant.

Upon request from the MRFC, the MRFP creates:

a) if the user is the first conference participant, a new context and configure it according to value(s) received within the "MMCMH policy" information element; and

b) an incoming termination and configure it with the simulcast property.

The MRFP reserves resources for the received audio and media streams. In this example, the MRFP reserves the local IP address and port, and IMS resources (codecs and codec’s configurations) for one audio media stream and for the three video media streams and provide the requested information to the MRFC. The MRFP configures termination:

a) to receive the two simulcast audio RTP streams and to send one audio RTP stream and which are encoded using codec1 or codec2 (StreamID with value 1);

b) with the voice activity detection functionality;

c) to receive the two simulcast video RTP streams (one RTP video stream in high resolution and the other RTP video stream in low resolution) and to send one RTP video stream in high resolution and which are encoded using codec3 (StreamID with value 2); and

d) to support the full "RTP-level pause and resume" functionality corresponding to "config=1" on all audio and video media streams.

6. – 8. The MRFC uses the "Configure Conference For Floor Control" procedure (specified in clause 6.2.13.2.2) to request the MRFP to configure context C1 with a Floor Control Server property. The MRFC provides in a "Conference Identifier" information element the Conference Identity "555" to be used by BFCP floor control signalling, includes a "Floor-Resource Associations" information element to indicate to the MRFP that two floors will be used within the context C1:

a) floor with identity "333" will be used to control the audio and the main video (and thus associated with StreamID with values 1 and 2); and

b) floor with identity "444" will be used to control the screenshare video (and thus associated with StreamID with value 3),

and includes a "Floor Control Algorithm" information element to indicate to the MRFP the algorithm used in granting the floor for each floor identity.

The MRFC uses the "Configure BFCP Termination" procedure to modify the termination to support BFCP over TCP media stream (StreamID with value 6) in accordance to procedure specified in clause 6.2.13.2.2. The MRFC provides an IP address and port received from the user and requests a local IP address and port from the MRFP. The MRFC includes an "User Identifier information" element indicating user identity and an "Available Floors" information element indicating the floor identities to be used for BFCP signalling.

If the MRFP needs to act as a TCP client, the MRFC requests the MRFP to start a TCP connection establishment with an "Establish TCP connection" information element. The MRFC includes a "Notify TCP connection establishment Failure Event" information element to request the MRFP to report an unsuccessful TCP connection set-up.

If the MRFC and the MRFP support IMS media plane security, they will apply additional procedures as specified in clause 6.2.19.3.

9. The MRFC inserts in the SDP answer the IP address and RTP port received from the MRFP for the accepted media streams and includes in the SDP answer:

– if the simulcast streams were included in the SDP offer, the accepted simulcast streams;

– if an "a=rtcp-fb" line with a "pause" CCM parameter was included in the SDP offer for the accepted media stream, an "a=rtcp-fb" line with a "pause" CCM parameter and "nowait" pause attribute;

– an "a=floorctrl:s-only" to indicate that the MRFP will act as a floor control server;

– an "a=confid" attribute indicating the conference identity to be used by BFCP signalling;

– an "a=userid" attribute indicating the user identity to be used by BFCP signalling;

– "a=floorid" attribute lines containing the BFCP floor identities ("333" which will be used to control main audio and main video media streams and "444" which will be used to control the screenshare video);

– "a=label" attribute lines indicating which audio and video media streams will be BFCP controlled; and

– an "a=setup:active" attribute to indicate that the MRFP will act as a TCP client.

10. The MRFC inserts in the SIP message (200 (OK) final response or 18x provisional response to the SIP INVITE request) an "isfocus" media feature tag and the SDP answer, and sends the SIP message towards the user.

6.2.10.3 Message Conferencing

The procedures specified in clauses 6.2.10.1- 6.2.10.6 for "General Multimedia Conferencing" shall be followed. The following clauses describe the additional requirements for the message conferencing.

6.2.10.3.1 General

For message conferencing, the Message Session Relay Protocol (MSRP) (see IETF RFC 4975 [18]) shall be used to transport messages. The message content may carry different media including text, image, video and audio. The Media types shall be MIME encoded. The TCP connection that the MSRP runs over shall be established when adding a new participant into the conference according to clause 6.2.20.

In order to manage the message conferencing, the following features may be supported:

– Message statistics.

– Message filtering.

An MRFC and an MRFP that support a session based messaging, as defined in IETF RFC 4975 [18], shall support the following procedures.

When receiving an SDP offer for a MSRP media, the MRFC:

– shall provide the value of the received "a=path" SDP attribute (defined in IETF RFC 4975 [18]) to the MRFP in the "MSRP URI Path" information element, as part of a remote descriptor;

– shall indicate "TCP/MSRP" or "TCP/TLS/MSRP" (if e2e media security is applied) as transport protocol to the MRFP;

– if the "a=msrp-cema" SDP attribute, as defined in IETF RFC 6714 [40], is not contained in the SDP offer, should use the IP address and port within the first entry of the "a=path" SDP attribute from the received SDP offer to configure the remote IP address and port at the MRFP;

NOTE 1: It is a normal MRFC procedure to configure the received SDP "c=" line and "m=" line IP address and TCP port information as the remote address and port at the MRFP. The SDP "c=" line and "m=" line address and port information will match the "a=path" address information unless there is an MSRP relay in the path.

– shall request the MRFP to allocate the IP address, TCP port and MSRP session-id and provide this information in the "MSRP URI Path" information element;

– shall include the "a=path" SDP attribute received from the MRFP in an SDP answer it sends; and

– if the SDP offer included the "a=msrp-cema" SDP attribute, shall include the "a=msrp-cema" SDP attribute in the SDP answer.

When sending an SDP offer for MSRP media, the MRFC:

– shall request the MRFP to allocate an IP address, TCP port and MSRP session-id and provide this information in the "MSRP URI Path" information element;

– shall indicate "TCP/MSRP" or "TCP/TLS/MSRP" (if e2e media security is applied) as transport protocol to the MRFP;

– shall include the value of the "MSRP URI Path" information element received from the MRFP in the "a=path" SDP attribute of the SDP offer it sends; and

– should include the "a=msrp-cema" SDP attribute in the SDP offer.

When receiving a corresponding SDP answer for MSRP media, the MRFC:

– shall provide the value of the received "a=path" SDP attribute to the MRFP in the "MSRP URI Path" information element; and

– if the "a=msrp-cema" SDP attribute is not contained in the SDP answer, should use the IP address and TCP port within the first entry of the "a=path" SDP attribute from the received SDP answer to configure the remote IP address and port at the MRFP.

When the MRFP is configured to handle MSRP media and is requested to allocate an IP address, TCP port and MSRP session-id, it shall provide this information in the "a=path" SDP attribute and shall store this information. When the MRFP then receives MSRP packets, it shall compare the session-id part of the received MSRP packets with the stored session-id.

NOTE 2: Comparing only the session-id, but not the address information, is in accordance with IETF draft-ietf-simple-msrp-sessmatch-10, but also compatible with peers using IETF RFC 4975 [18] without extensions or in combination with IETF RFC 6714 [40]. No procedures to indicate the method of session matching (according to IETF RFC 4975 [18] or IETF draft-ietf-simple-msrp-sessmatch-10) to the MRFP are defined.

The MRFP shall include MSRP URI(s) received in the "MSRP URI Path" information element from the MRFC in the "To-Path" header field of MSRP packets it sends.

6.2.10.3.2 Messages Statistics

The MRFP may report the statistics for the number of messages sent and/or received in two ways described as following.

1. The MRFC indicates quotas granted to the MRFP. The granted quotas indicate the units specifying the number of messages or volume of messages allowed to be received or sent by users. The MRFC may also indicate to the MRFP a valid time together with the granted quotas. The valid time indicates the time until the specific unit may be measured, after which the quota shall be reported, whether or not it has reached its granted quota. The MRFC initiates this via the "Configure Granted Quota" procedure as specified in clause 8.50. The quotas granted by MRFC may include any of the following:

– Quota for number of messages sent

– Quota for number of messages received

– Quota for volume (size) of messages sent

– Quota for volume (size) of messages received

When the quota granted is reached or the valid time elapses the MRFP shall report statistics information of messages according to the indication by the MRFC. The MRFP uses the "Report Message Statistics" procedure as specified in clause 8.51 to report the statistics of messages. The statstistics of messages sent and/or received may include any of the following:

– number of messages sent

– number of messages received

– volume (size) of messages sent

– volume (size) of messages received

– reason for report i.e. quota reached or granted time elapsed

2. The MRFC requests the MRFP to report the statistics information of messages sent and/or received at the end of the session or during the session. In this case, the quotas or the valid time is not required, and the MRFP should report the statistics of message as requested by the MRFC. The statstistics of messages are the same as described above.

Figure 6.2.10.3.2.1 shows the message sequence chart example for reporting message statistics.

Figure 6.2.10.3.2.1 Message statistics according to the granted quota

6.2.10.3.3 Message Filtering

When the MRFC receives the trigger to config the filtering rules, the MRFC may initiate the "Configure Filtering Rules" procedure as specified in clause 8.52 to set filtering rules in the MRFP. The filtering rule is composed of two parts: the criteria and the treatment of the filtered message. The MRFP should handle messages according to the filtering rules.

The MRFC may indicate to the MRFP the following criterias:

Sender address

Message size

Message content type (e.g. video, audio)

Message content format(e.g. mpeg, jpeg)

Message subject

The MRFC may indicate to the MRFP the following message treatments:

Block the delivery of the message content

Store the message content

Redirect the message to another address

The MRFC may indicate to the MRFP the "store url" when messages storage is needed, or the MRFC may indicate the MRFP to allocate the "store url" and return the generated "store url" to the MRFC.

The MRFC may indicate to the MRFP the "redirect url" when messages redirection is needed.

Figure 6.2.10.3.3.1 shows the message sequence chart example to config the filtering rules.

Figure 6.2.10.3.3.1 Configure the filtering rules