Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.333  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   4   5…   5.8…   5.12…   5.14…   5.20…   5.24…   6…   6.1.8…   6.2…   6.2.3…   6.2.4…   6.2.5   6.2.6…   6.2.7…   6.2.8…   6.2.9…   6.2.10…   6.2.10.2.7   6.2.10.3…   6.2.11…   6.2.13…   6.2.13.2.6…   6.2.14…   6.2.15…   6.2.16…   6.2.18…   6.2.19…   6.2.19.3…   6.2.20…   6.2.21…   6.2.22…   6.2.23   6.2.24…   7   8…   8.11…   8.20   8.21   8.22   8.23…   8.30…   8.39…   8.45…   8.56… 
6.2.10.2.7 Create Ad-hoc Multi-stream Multiparty Conference Procedure 
...

 

6.2.10.2.7  Create Ad-hoc Multi-stream Multiparty Conference Procedure |R14|  p. 95
6.2.10.2.7.1  Context Model  p. 95
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.
Copy of original 3GPP image for 3GPP TS 23.333, Fig. 6.2.10.2.7.1.1: H.248 Context model for Multi-stream multiparty conference
Figure 6.2.10.2.7.1.1: H.248 Context model for Multi-stream multiparty conference
(⇒ copy of original 3GPP image)
Up
6.2.10.2.7.2  MMCMH conference establishment procedure using "dial-in" method  p. 96
The signalling flow shown in Figure 6.2.10.2.7.2.1 and Figure 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.
Copy of original 3GPP image for 3GPP TS 23.333, Fig. 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.1: Multi-stream multiparty conference establishment "dial-in" procedure) with support of "simulcast" and "RTP-level pause and resume"
(⇒ copy of original 3GPP image)
Up
Copy of original 3GPP image for 3GPP TS 23.333, Fig. 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)
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)
(⇒ copy of original 3GPP image)
Up
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 TS 26.114 Annex S, RFC 8853 and RFC 8851, and "RTP-level pause and resume" signalling according to RFC 7728 for multi-stream multiparty conference media handling.
The procedure in the Figure 6.2.10.2.7.2.1 and Figure 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.
Step 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:
  1. 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]);
  2. 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;
  3. a video "m=" line with the "a=content:slides" attribute indicating sending and receiving of a screenshare video;
  4. a video "m=" line with the "a=imageattr" attribute indicating receiving of RTP video stream in low resolution;
  5. a BFCP "m=" line indicating support of a floor control client role; and
  6. a session level "a=ccc_list" attribute (defined in clause S.5.7.2 of TS 26.114) with the concurrent codec capabilities of the conference participant.
Step 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:
  1. one audio media stream (StreamID = 1);
  2. one video media stream for main video (StreamID = 2);
  3. one video media stream for screenshare video (StreamID = 3);
  4. one media stream for thumbnail video (StreamID = 4); and
  5. one media stream for floor control using BFCP protocol signalling (StreamID = 6).
Step 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:
  1. 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;
  2. provides an IP address and port received from the user;
  3. requests a local IP address and port;
  4. includes selected payload types in "Local IMS resources" and "Remote IMS resources" information elements;
  5. 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;
  6. 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;
  7. 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;
  8. 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
  9. 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
  10. 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:
  1. 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
  2. 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:
  1. 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);
  2. with the voice activity detection functionality;
  3. 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
  4. to support the full "RTP-level pause and resume" functionality corresponding to "config=1" on all audio and video media streams.
Step 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:
  1. 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
  2. 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.
Step 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.
Step 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.
Up

Up   Top   ToC