idnits 2.17.1 draft-jennings-xcon-media-control-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 859. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 549 has weird spacing: '...udio-in strea...' == Line 551 has weird spacing: '...ideo-in strea...' == Line 557 has weird spacing: '...udio-in strea...' == Line 559 has weird spacing: '...ideo-in strea...' == Line 565 has weird spacing: '...udio-in strea...' == (4 more instances...) -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Once a conference begins, the template and parameters are fixed and MAY NOT be manipulated during the conference. As a result, flow graphs can only be uploaded prior to the start of the conference, although they could be downloaded by a participant during a conference using CPCP. In general, however, flow graphs will only be used by the creator of the conference prior to the start of the conference. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 16, 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 785, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 789, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 793, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 802, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 807, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 811, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-02) exists of draft-boulton-xcon-media-template-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-02) exists of draft-barnes-xcon-framework-01 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-01) exists of draft-mahy-xcon-media-policy-control-00 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-00 Summary: 4 errors (**), 0 flaws (~~), 19 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON WG C. Jennings 3 Internet-Draft Cisco Systems 4 Expires: January 17, 2006 B. Rosen 5 Emergicon 6 July 16, 2005 8 Media Conference Server Control for XCON 9 draft-jennings-xcon-media-control-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 17, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Conference servers have many controls that change how the media is 43 combined for the various conference participants. It is necessary to 44 describe these controls to the clients connected to a centralized 45 conference, so that the clients can render a user interface and allow 46 the user to manipulate them. 48 This work is being discussed on the xcon@ietf.org mailing list. This 49 draft has not changed since the 02 version. 51 Table of Contents 53 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. TODO Items . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Non Problems . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1 Templates . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.2 Controls . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.4 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5.5 Streams . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 6.1 Simple Audio Example . . . . . . . . . . . . . . . . . . . 10 65 6.2 Simple Audio Video Example . . . . . . . . . . . . . . . . 11 66 7. Types of Controls . . . . . . . . . . . . . . . . . . . . . 14 67 7.1 Strings . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7.2 Integer . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 7.3 Boolean . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 7.4 Selection . . . . . . . . . . . . . . . . . . . . . . . . 15 71 7.5 Multiple Selection . . . . . . . . . . . . . . . . . . . . 16 72 7.6 Control Array . . . . . . . . . . . . . . . . . . . . . . 16 73 7.7 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 7.8 Panel . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 8. Template Registry . . . . . . . . . . . . . . . . . . . . . 17 76 9. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 12.1 Normative References . . . . . . . . . . . . . . . . . . 18 81 12.2 Informative References . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 83 Intellectual Property and Copyright Statements . . . . . . . 20 85 1. Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC-2119 [4]. 91 2. TODO Items 93 Note - the issue of switching from presenter mode to Q and A mode 94 (etc.) is essentially one of floor control? Need much more on how 95 MPCP and floor control work. 97 Note - using panel for now - may later replace with media neutral 98 term such as placement 100 3. Introduction 102 This work tries to solve the problem of how a conference participant 103 should manipulate the media flow in a conference server. It defines 104 a protocol between the centralized conference server and the end 105 user's software that manipulates the conference. This protocol needs 106 to be rich enough for a conference server to express what information 107 it wants, yet simple enough to allow the client to render a useful 108 user interface. This work takes into account that real conference 109 servers have constraints on what media flows are possible and that 110 UIs have buttons, knobs, etc. that users manipulate. The goal is for 111 a conferencing end point made by one vendor to work with conference 112 servers or conference systems made by other vendors. 114 Someone wishing to create a conference uses CPCP (or some other 115 means) to create a conference and obtain a Conference URI. The 116 conference creator can query the server to find out its media 117 capabilities, information such as the set of templates that a server 118 supports. A template defines a type of conferencing service that a 119 conference server can provide. It includes what media streams can 120 flow in and out of the conference, the roles that are possible in the 121 conference, and most importantly, what controls a client can 122 manipulate on the conference to affect the media mix. A set of 123 standardized templates that a server may support is defined, and in 124 addition, conference servers that support the flow graphs work in 125 TODO REF can dynamically define new templates. Note that templates 126 contain media specific information, so to know which templates are 127 supported is also to know what media types are supported. Each 128 template lists a number of parameters that must be set to initialize 129 the conference and can have limits imposed by the conference server. 130 Parameters are typically maximum values that are hardware or software 131 (or policy) hard limits that constrain what is possible in a 132 conference. Parameters can only be set when the conference is 133 instantiated and can not be changed after that. For things that are 134 changed as the conference progresses, controls are used. The point 135 of the parameters in the templates is simply to reduce the number of 136 templates needed. 138 The conference creator can then choose a template, populate the 139 parameter values and upload using CPCP to the server. If the chosen 140 parameter values are acceptable to the server, the update is accepted 141 and the media policy created. If not, an error message indicating 142 the failure is returned. 144 The simplest template will have just a single role: Participant. By 145 default, each participant will join a conference as a Participant. 146 More interesting templates will have multiple roles. For example, a 147 template might have two roles: Lecturer and Participant. A template 148 role definition will indicate if there can be more than one 149 participant having that role. For this example, there can be only 150 one Lecturer but many Participants. 152 The conference creator can assign roles to participants. This can be 153 done in advance of the conference or dynamically during the 154 conference. For example, the conference creator can assign the role 155 of Lecturer in advance, if it is known. When this participant joins 156 the conference, they will be automatically assigned the role of 157 Lecturer. This is Conference Policy not Media Policy but it does 158 relate to the templates. The conference package TODO REF includes 159 the Role of each participant in the conference. 161 Once a conference starts, a participant can find out the media policy 162 template. They can also download the set of controls for each role 163 they may assume during the conference. This template may also have 164 controls that allow a participant to control their view of/input to 165 the conference. These controls may be rendered to the participant, 166 and any changes to the controls result in commands being sent to the 167 conference server. A template may define different controls for 168 different roles. For example, a Participant may have only a very 169 small set of controls, a Lecturer a larger set, and the Floor Holder 170 an even larger set. If a participant's role changes during a 171 conference, their set of controls may change, and the user interface 172 needs to be updated accordingly. 174 An advanced conference server may support the definition of custom 175 templates using flow graphs. If so, the conference policy will 176 indicate this capability. If it is supported, a conference creator 177 may upload a flow graph using CPCP. This flow graph will contain 178 enough information for the conference server to create a custom 179 template: it will contain stream level media mixing information and 180 information about parameters, roles, controls, and support for floor 181 control. If the server can process the flow graph and support the 182 mixing defined by the template, the server returns a success 183 response. If it is not able, it returns an error indicating how the 184 flow graph might be fixed. A custom template created using flow 185 graphs will be identical to the set of standardized templates - it 186 will just have a different name, roles, parameters, controls, etc. 187 The same methods that allow a participant to render an unknown 188 standardized template will be used to render a custom template. 190 Once a conference begins, the template and parameters are fixed and 191 MAY NOT be manipulated during the conference. As a result, flow 192 graphs can only be uploaded prior to the start of the conference, 193 although they could be downloaded by a participant during a 194 conference using CPCP. In general, however, flow graphs will only be 195 used by the creator of the conference prior to the start of the 196 conference. 198 A conference client can request the conference object from the focus. 199 This allows the client to discover what the current media policy is 200 and what controls it can manipulate. The client can then send an 201 update to the focus to change the controls to manipulate media policy 202 for various participants. 204 The conference has a set of physical streams that get contributed to 205 the conference and a set of streams that are sent to the client. The 206 streams coming into the conference feed into an input stream group, 207 and the streams coming out of a conference come from an output stream 208 group. 210 A template may define various logical stream lists. For example, one 211 video stream may contain video of the active presenter, and another 212 video stream may have the presentation that the presenter is showing. 213 Media from a participant is contributed to one of the input stream 214 groups. Various controls, such as gain, may be attached to each 215 physical input stream, to logical stream groups, or to a top-level 216 conference or sidebar. 218 Each conference also has output stream groups that represent media 219 being sent to the client. Output streams to a client are named and 220 may have complex controls that affect which streams are selected to 221 contribute to the result. Output streams may be formed using 222 multiple input component streams. This is typically done for video 223 when the output is some composited form of the input component 224 streams, but it can also be done for audio, e.g. when selecting 225 multiple mono audio streams and defining how they are composited into 226 a stereo stream. 228 4. Non Problems 230 There are several topics that are completely internal to the 231 conference systems and are out of scope of this work. These include: 232 how the focus manipulates the conference server 233 how one describes what a conference server is capable of doing; 234 and 235 managing resource allocation and how busy a given DSP is, and 236 checking whether more work can be allocated to a media processor. 238 5. Terminology 240 5.1 Templates 242 TODO - one template instantiated per conference. Changing a template 243 is close to stopping a conference and starting a new one. 245 A template defines a model for the reception, manipulation and 246 transmission of streams. A template provides enough information that 247 the client can intelligently render a useful GUI to the end user to 248 manipulate the model. There is a registry of well known templates, 249 but a conference server can define new ones. A convener can find all 250 the templates a conference server supports and select one to use when 251 creating the conference. 253 Templates contain a list of logical stream, input and output stream, 254 roles for participants, and controls for the conference. 256 A template for a very basic audio conference, for example, may 257 indicate that there is one audio stream for each participant, and one 258 output stream group named "main". Each participant in the stream has 259 a single binary control called "Mute". There is only one Role that 260 can be used, called "participant". 262 5.2 Controls 264 Controls are variables in a conference object that participants may 265 manipulate to control the media streams of the conference. The 266 Control has information about what type of inputs it accepts that 267 help the client render a user interface. Conferences can have 268 controls, participants in a conference can have controls, and streams 269 in a conference can have controls. A control has a name, a value, 270 and constraints on its value. The controls that are available are 271 defined in the template. 273 A control can be defined as being part of a role. In that case, all 274 participants who assume that role have an instance of the control. A 275 control may also be defined as part of an input stream group, in 276 which case all contributors of that stream will have an instance of 277 the control; or an output stream, in which case each output stream 278 will have an instance of the control. There can be global controls 279 that change values for the whole conference. 281 A control can be inside the template, participant, or stream group. 282 The control will apply to the appropriate context. By including 283 stream definitions in multiple roles that have the same name, 284 different controls can be provided to different roles affecting 285 streams contributed or sunk from multiple roles. For example, a 286 moderator may be given a set of input volume controls controlling a 287 mix, and every participant can be given an output master mix control 288 for the output stream sent to him. 290 5.3 Parameters 292 TODO - need better name for Parameters. Perhaps Instantiation Values 294 Parameters are variables in the template that are set when the 295 conference is created. The point of a Parameter is simply to reduce 296 the number of templates required. For example, in the audio 297 conference, whether or not sidebars are supported might be a 298 parameter. The template can indicate the valid range for parameters. 299 Parameters can also be used for an application instantiating a 300 conference to limit what capabilities it will use. 302 Parameters are variables that modify the function of the template. 303 They are fixed when the conference object is instantiated and can not 304 be changed after that. Parameters allow a single template definition 305 to describe a range of possible conference server capabilities. 307 Parameters have a name, a type, a value and, optionally, a min and 308 max value. 310 The parameters in the templates customize a generic template for a 311 specific conference. Parameters have name, type, value, and 312 optionally min/max. Parameters are defined in the template 313 description. Only conveners can set template parameters. 315 One typical template parameter is "max-sidebars". When the CS 316 generates the template for the client, it can customize the min and 317 max value of this parameter to match what it is capable of, which 318 might range from zero or one to infinite. When the client 319 instantiates the template and creates the conference, it can specify 320 the value that has been requested. The value typically represents 321 the limits the conference server is capable of. Resource 322 availability may limit the actual value that can be achieved. 324 Parameter names are strings. 326 Parameter Types: 327 Integer 328 Real 329 Enumeration 331 Values of course are constrained to the type. Min and Max, if 332 defined, also constrain the the value. 334 TODO - need to be able to make the limits of controls be parameters. 336 5.4 Roles 338 Participants in a conference can take on multiple different Roles 339 that will change what controls they may manipulate and which media 340 streams they have access to. The template defines what Roles are 341 available for the client. Manipulation of Roles is not directly part 342 of MPCP, but the various Roles that are possible are found in the 343 template. Some common roles include: 344 Participant 345 Presenter 346 Moderator 347 Observer 349 OPEN ISSUE - decide if we want Role so a single participant can 350 simultaneously have multiple roles 352 Roles are defined as part of Conference Policy but are used here so 353 that the Media Policy can define separate streams and controls 354 depending on role. Roles are defined by in the template. Some 355 templates may allow a participant to take on more than one role at a 356 time. Each template must define a role named "Participant", which is 357 the default role. "Moderator" is a typical role, but templates do 358 not intrinsically define or require such roles. A given user will 359 only be able to access parts of the template that are not inside a 360 Role or are inside a Role that the this user is a member of. 362 Templates define all the Roles that a participant can take and 363 (optionally) the max number of participants of each role. Each role 364 is defined in a role element. A Role element includes a name and 365 optionally a "max-participants" value. Role elements may also 366 contain stream elements, which define per-participant-in-role 367 streams. The first stream list of a given media type inside a Role 368 is the default location for that type of media. 370 5.5 Streams 372 Streams correspond to a given flow of media. They are named and can 373 be selected by controls. The conference package is used to 374 understand the relationships between users or participants, dialog or 375 session, and streams. 377 The physical streams are the actual media streams sent and/or 378 received by or on behalf of conference participants. Media streams 379 are typically established when conference participants join a 380 conference and are described by the SDP media lines in the offer/ 381 answer exchange between the participants and the focus, or the 382 analogous exchange in other protocols (ex: H.245 logical channel 383 establishment). Each stream is described by a media type, direction 384 and at least one identifier. Initially media types considered 385 include audio, video or text. (Other media types can also be 386 considered in the future.) The direction "in" corresponds to streams 387 originating from the conference participants to the conference, and 388 "out" for streams originating from the conference and terminating at 389 the conference participants. A stream-id is an integer assigned by 390 the focus to each physical input and output stream. This integer is 391 unique to all streams in a specific conference (and all its sub- 392 conferences). 394 Logical streams are names that are defined in the template and can be 395 used like other streams but correspond to some virtual stream that 396 the conference is creating. Logical streams often change dynamically 397 and potentially very quickly during the lifetime of a conference. 398 For example, one logical set is the set of input video streams 399 corresponding to the current speaker or speakers. Logical stream 400 lists are discussed in more detail in the following section. 402 Streams have types. These correspond to the major MIME types of the 403 media the stream carries. 405 Audio Streams originate as participant contributions (dir is "in") 406 that are mixed using some kind of algorithm. Controls commonly 407 available on audio streams include input or output faders (volume 408 controls), stereo balance, and mute. 409 Video Streams originate as participant contributions (dir is "in"), 410 which are combined with some kind of algorithm. Intermediate 411 streams may be created, which are subsequently combined with other 412 streams to yield streams that are sent to participants (dir is 413 "out"). Controls commonly available on video streams might 414 include selectors for choosing a tiling format, selectors that 415 choose which input stream is rendered on an output tile, and video 416 freeze and blank. 418 Text Streams originate as participant contributions (dir is "in") 419 (Instant Messages). Messages from all participants are combined 420 using some algorithm. Intermediate streams may be created, which 421 are subsequently combined with other text streams to yield streams 422 that are sent to participants (dir is "out"). 424 The stream id correlates the stream with a particular RTP session or 425 media session for non RTP based media. The client can learn the 426 correlation of stream ID to the particular media streams it is 427 sending by TBD (TODO could be subscribing to the conference package). 429 A stream-id is an integer assigned by the focus to each physical 430 input and output stream. For RTP media, this corresponds to a single 431 RTP session. This integer is unique to all streams in a specific 432 conference (and all its sub-conferences). 434 6. Examples 436 6.1 Simple Audio Example 438 The examples in this section will all be moved to XML, but to help 439 make them easier to understand and focus on the semantics instead of 440 the syntax, they are currently just some text with indentation 441 representing containment. 443 The client selects the basic audio template that looks like: 445 Template BasicAudio 446 PhysicalStream direction=input type=audio name=main-audio-in 447 control type=bool name=mute label="Mute" 449 PhysicalStream direction=output type=audio name=main-audio-out 450 control type=real name=gain label="Volume" 452 This templates defines that this conference has one input stream 453 group called main-audio and one output stream group called main- 454 audio. There is a single control, called mute, for each physical 455 input stream, and a gain for each output stream. 457 After Alice and Bob have joined, the conference server informs Bob 458 that the current state of the conference object is as shown in the 459 xml below. 461 Conference BasicAudio 462 PhysicalStream name=main-audio-in stream-id=1 463 control bool mute=false 465 PhysicalStream name=main-audio-out stream-id=3 466 control bool mute=false 468 PhysicalStream name=main-oudio-out stream-id=2 469 control real gain=0.0 471 PhysicalStream name=main-audio-out stream-id=4 472 control real gain=0.0 474 There are two participants, Alice and Bob, who both contribute input 475 streams and receive output streams, and neither is muted. 477 A key part of this is that Bob's client may have known about this 478 basic audio template and what the semantics of the "mute" control 479 implied. The client may have connected this up with a button of the 480 client's that was labeled mute. On the other hand, Bob's client may 481 not have known anything about this template and simply rendered a 482 button on the screen and labeled it "mute" with no idea what this 483 would do. A third client may not have been able to deal with the 484 control at all and may have just ignored it. Clearly the user 485 interface can be better if the client understands the semantics of 486 what the template means, but the user interface is still functional 487 when the client does not. 489 6.2 Simple Audio Video Example 491 A more complex video example is given below. 493 Template basicAudioVideo 494 LogicalStream type=video name=activeSpeaker-video 495 LogicalStream type=video name=presenter-video 496 LogicalStream type=video name=presentation-video 498 Floor name=presenter-floor 500 Control type=bool name=eCan label="Echo Cancelation" 502 Role name=listener 503 PhysicalStream direction=output type=audio name=main-audio-out 504 PhysicalStream direction=output type=video name=main-video-out 506 Role name=participant 507 PhysicalStream direction=input type=audio name=main-audio-in 508 Control type=bool name=mute label="Mute" 509 PhysicalStream direction-input type=video name=main-video-in 510 Control type=choice name=video-mute 511 choices="normal,blank,freeze" 512 PhysicalStream direction-input type=video name=presentation 513 Control type=choice name=video-mute 514 choices=" normal, blank, freeze" 516 PhysicalStream direction=output type=audio name=main-audio-out 517 Control type=real name=gain label="Volume" 519 PhysicalStream direction=output type=video name=main-video-out 521 Control name=main-laoyout type=layout choices=1x1,2x2,1x2, 523 Sidebar 524 Control name=mainConfVolume type=real 525 PhysicalStream direction=input type=audio name=side-audio-in 526 control type=bool name=mute label="Mute" 527 PhysicalStream direction=output type=audio name=side-audio-out 528 control type=real name=gain label="Volume" 530 Role name=moderator 531 controllArray index=main-audio 532 control type=bool name=mute label="Mute" 534 This template has some logical streams that can be used for selecting 535 in the layout. It defines a control called eCan that applies to the 536 whole conference. It defines a Listener role that can only receive 537 input and a Participant role. There is also a moderator role that 538 has everything a participant has along with an additional set of 539 controls to mute any of the contributors to the main-audio. The 540 participants share a single layout control that defines the video 541 layout. The conference supports sidebars but they can only have 542 audio media. 544 The instantiated value of the conference object for this might look 545 like 547 ConferenceObject type=basicAudioVideo name=conf1234 548 Role Participant 549 PhysicalStream name=main-audio-in stream-id=22 550 Control name=mute value=false 551 PhysicalStream name=main-video-in stream-id=23 552 Control name=video-mute value=normal 553 PhysicalStream name=main-audio-out stream-id=24 554 Control name=gain value=0 555 PhysicalStream name=main-video-out stream-id=25 557 PhysicalStream name=main-audio-in stream-id=32 558 Control name=mute value=false 559 PhysicalStream name=main-video-in stream-id=33 560 Control name=video-mute value=normal 561 PhysicalStream name=main-audio-out stream-id=34 562 Control name=gain value=0 563 PhysicalStream name=main-video-out stream-id=35 565 PhysicalStream name=main-audio-in stream-id=42 566 Control name=mute value=false 567 PhysicalStream name=main-video-in stream-id=43 568 Control name=video-mute value=normal 569 PhysicalStream name=main-audio-out stream-id=44 570 Control name=gain value=0 571 PhysicalStream name=main-video-out stream-id=45 573 Control name=main-layout value="3x1+16" 574 Pannel input=presenter-video postion=1 selectionQ=0.8 exGrp=1 575 Pannel input=presentation postion=2 selectionQ=1.0 exGrp=1 576 Pannel input=active-speaker postion=3 selectionQ=0.9 exGrp=1 577 Pannel input=main-video-in postion=4 selectionQ=0.5 exGrp=2 579 In the example above three participants have joined. All the video 580 participants are watching the same video composition, which has the 581 presenter in position 1, the presentation in position 2, the active 582 speaker in position 3; followed by all the video from participants 583 contributed to the main input group. The streams that are in the 584 positions after the first three are not in the same exclusivity group 585 as the first three, so streams could repeat even if they were being 586 shown in the first three positions. The active speaker position 3 is 587 in the same exclusion group as the presenter in position 1, so if the 588 primary active speaker was the presenter, this would not be shown in 589 position 3 and instead the previous active speaker would be shown. 591 7. Types of Controls 593 Controls need to collect information of several different types. It 594 should be possible to provide default values, a name for the control 595 and text it displays, help text, control if a value is required, and 596 control of whether or not the value is editable. It should be 597 possible to express constraints on the form an input can take by 598 specifying a minimum or maximum for types where that makes sense, or 599 specifying a regular expression that must be satisfied. For numeric 600 values in a constrained range, it should be possible to provide an 601 increment value used by the control. For strings it should be 602 possible to indicate that they should not be displayed when they are 603 entered for things like passwords. These controls are necessary to 604 make it possible to internationalize any text that is displayed to 605 the user. 607 There are control types for: 608 Strings 609 Multi-line Strings 610 Integer 611 Real 612 Boolean 613 Date 614 Time 615 Date Time 616 URI 617 Select Single 618 Select Multiple 619 Select Stream - TODO ADD THIS 620 Layout - video layout object 621 Panel - a portion of a Layout 623 If an unknown control is encountered, it should be treated as a 624 string type. The