idnits 2.17.1 draft-romano-dcon-recording-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2012) is 4150 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: 'RFC2234' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 958, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 5567 == Outdated reference: A later version (-13) exists of draft-ietf-mediactrl-call-flows-10 ** Downref: Normative reference to an Informational draft: draft-ietf-mediactrl-call-flows (ref. 'I-D.ietf-mediactrl-call-flows') ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 3920 (Obsoleted by RFC 6120) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH A. Amirante 3 Internet-Draft University of Napoli 4 Expires: June 17, 2013 T. Castaldi 5 L. Miniero 6 Meetecho 7 S P. Romano 8 University of Napoli 9 December 14, 2012 11 Session Recording for Conferences using SMIL 12 draft-romano-dcon-recording-07 14 Abstract 16 This document deals with session recording, specifically for what 17 concerns recording of multimedia conferences, both centralized and 18 distributed. Each involved media is recorded separately, and is then 19 properly tagged. A SMIL [W3C.CR-SMIL3-20080115] metadata is used to 20 put all the separate recordings together and handle their 21 synchronization, as well as the possibly asynchronous opening and 22 closure of media within the context of a conference. This SMIL 23 metadata can subsequently be used by an interested user by means of a 24 compliant player in order to passively receive a playout of the whole 25 multimedia conference session. The motivation for this document 26 comes from our experience with our conferencing framework, Meetecho, 27 for which we implemented a recording functionality. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 17, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Recording . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Audio/Video . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.2. Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.4. Whiteboard . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. SMIL Head . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5.2. SMIL Body . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5.2.1. Audio/Video . . . . . . . . . . . . . . . . . . . . . 16 75 5.2.2. Chat . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 5.2.3. Slides . . . . . . . . . . . . . . . . . . . . . . . . 18 77 5.2.4. Whiteboard . . . . . . . . . . . . . . . . . . . . . . 19 78 6. Playout . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 84 1. Introduction 86 This document deals with session recording, specifically for what 87 concerns recording of multimedia conferences, both centralized and 88 distributed. Each involved media is recorded separately, and is then 89 properly tagged. Such a functionality is often required in many 90 conferencing systems, and is of great interest to the XCON [RFC5239] 91 Working Group. The motivation for this document comes from our 92 experience with our conferencing framework, Meetecho, for which we 93 implemented a recording functionality. Meetecho is a standards-based 94 conferencing framework, and so we tried our best to implement 95 recording in a standard fashion as well. 97 In the approach presented in this document, a SMIL 98 [W3C.CR-SMIL3-20080115] metadata is used to put all the separate 99 recordings together and handle their synchronization, as well as the 100 possibly asynchronous opening and closure of media within the context 101 of a conference. This SMIL metadata can subsequently be used by an 102 interested user by means of a compliant player in order to passively 103 receive a playout of the whole multimedia conference session. 105 The document presents the approach by sequentially describing the 106 several required steps. So, in Section 4 the recording step is 107 presented, with an overview of how each involved media might be 108 recorded and stored for future use. As it will be explained in the 109 following sections, existing approaches might be exploited to achieve 110 this steps (e.g. MEDIACTRL [RFC5567]. Then, in Section 5 the 111 tagging process is described, by showing how each media can be 112 addressed in a SMIL metadata file, with specific focus upon the 113 timing and inter-media synchronization aspects. Finally, Section 6 114 is devoted to describing how a potential player for the recorded 115 session can be implemented and what it is supposed to achieve. 117 2. Conventions 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 121 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 122 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 123 levels for compliant implementations. 125 3. Terminology 127 TBD. 129 4. Recording 131 When a multimedia conference is realized over the Internet, several 132 media might be involved at the same time. Besides, these media might 133 come and go asynchronously during the lifetime of the same 134 conference. This makes it quite clear that, in case such a 135 conference needs to be recorded in order to allow a subsequent, 136 possibly offline, playout, these media need to be recorded in a 137 format that is aware of all the timing-related aspects. A typical 138 example is a videoconference with slide sharing. While audio and 139 video have a life of their own, slides changes might be triggered at 140 a completely different pace. Besides, the start of a slideshow might 141 occur much later than the start of the audio/video session. All 142 these requirements must be taken into account when dealing with 143 session recording in a conference. Besides, it's important that all 144 the individual recordings be taken in a standard fashion, in order to 145 achieve the maximum compatibility among different solutions and avoid 146 any proprietary mechanism or approach that could prevent a successful 147 playout later on. 149 In this document, we present our approach towards media recording in 150 a conference. Specifically, we will deal with the recording of the 151 following media: 153 o audio and video streams (in Section 4.1); 154 o text chats (in Section 4.2); 155 o slide presentations (in Section 4.3); 156 o whiteboards (in Section 4.4). 158 Additional media that might be involved in a conference (e.g. desktop 159 or application sharing) are not presented in this document, and their 160 description is left to future extensions. 162 4.1. Audio/Video 164 In a conferencing system compliant with [RFC5239], audio and video 165 streams contributed by participants are carried in RTP channels 166 [RFC3550]. These RTP channels may or may not be secured (e.g by 167 means of SRTP/ZRTP). Whether or not these channels are secured, 168 anyway, is not an issue in this case. In fact, as it is usually the 169 case, all the participants terminate their media streams at a central 170 point (a mixer entity), with whom they would have a secured 171 connection. This means that the mixer would get access to the 172 unencrypted payloads, and would be able to mix and/or store them 173 accordingly. 175 From an high level topology point of view, this is how a recorder for 176 audio and video streams could be envisaged: 178 SIP +------------+ SIP 179 /----------| XCON AS |-------- 180 / +------------+ \ 181 / |MEDIACTRL \ 182 / | \ 183 +-----+ +-----+ +-----+ 184 | | RTP | | RTP | | 185 |UA-A +<------------>+Mixer+<------------>+UA-B | 186 | | | | | | 187 +-----+ +-++--+ +-----+ 188 | | 189 RTP UA-A | | RTP UA-B (Rx+Tx) 190 (Rx+Tx) V V 191 +----------+ 192 | | 193 | Recorder | 194 | | 195 +----------+ 197 Figure 1: Audio/Video Recorder 199 [Editors' Note: this is a slightly modified version of the 200 topology proposed on the DISPATCH mailing list, 201 http://www.ietf.org/mail-archive/web/dispatch/current/ 202 msg00256.html 203 where the Application Server has been specialized in an XCON-aware 204 AS, and the AS<->Mixer protocol is the Media Control Channel 205 Framework protocol (CFW) specified in [RFC6230].] 207 That said, actually recording audio and video streams in a conference 208 may be accomplished in several ways. Two different approaches might 209 be highlighted: 211 1. recording each contribution from/to each participant in a 212 separate file (Figure 2); 213 2. recording the overall mix (one for audio and one from video, or 214 more if several mixes for the same media type are available) in a 215 dedicated file (Figure 3). 217 +-------+ 218 | UAC-C | 219 +-------+ 220 " 221 C (RTP) " 222 " 223 " 224 v 225 +-------+ A (RTP) +----------+ B (RTP) +-------+ 226 | UAC-A |===================>| Recorder |<===================| UAC-B | 227 +-------+ +----------+ +-------+ 228 * 229 * 230 * 231 ****> A.gsm, A.h263 232 ****> B.g711, B.h264 233 ****> C.amr 235 Figure 2: Recording individual streams 237 +-------+ 238 | UAC-C | 239 +-------+ 240 " 241 C (RTP) " 242 " 243 " 244 v 245 +-------+ A (RTP) +----------+ B (RTP) +-------+ 246 | UAC-A |===================>| Recorder |<===================| UAC-B | 247 +-------+ +----------+ +-------+ 248 * 249 * 250 * 251 ****> (A+B+C).wav, (A+B+C).h263 253 Figure 3: Recording mixed streams 255 Of the two, the second is probably more feasable. In fact, the first 256 would require a potentially vast amount of separate recordings which 257 would need to be subsequently muxed and correlated to each other. 258 Besides, within the context of a multimedia conference, most of the 259 times the streams are already mixed for all the participants, and so 260 recording the mix directly would be a clear advantage. Such an 261 approach, of course, assumes that all the streams pass through a 262 central point where the mixing occurs: it is the case depicted in 263 Figure 1. The recording would take place in that point. Such 264 central point, the mixer (which in this case would also act as the 265 recorder, or a frontend to it), might be a MEDIACTRL-based [RFC5567] 266 Media Server. Considering the similar nature of audio and video 267 (both being RTP based and mixed by probably the same entity) they are 268 analysed in the same section of this document. The same applies to 269 tagging and playout as well. It is important to note that in case 270 any policy is involved (e.g. moderation by means of the BFCP 271 [RFC4582]) the mixer would take it into account when recording. In 272 fact, the same policies applied to the actual conference with respect 273 to the delivery of audio and video to the participants needs to be 274 enforced for the recording as well. 276 In a more general way, if the mixer does not support a direct 277 recording of the mixes it prepares, recording a mix can be achieved 278 by attaching the recorder entity (whatever it is) as a passive 279 participant to the conference. This would allow the recorder to 280 receive all the involved audio and video streams already properly 281 mixed, with policies already taken into consideration. This approach 282 is depicted in Figure 4. 284 +-------+ 285 | UAC | 286 | C | 287 +-------+ 288 " ^ 289 C (RTP) " " 290 " " 291 " " A+B (RTP) 292 v " 293 +-------+ A (RTP) +--------+ A+C (RTP) +-------+ 294 | UAC |===================>| Media |===================>| UAC | 295 | A |<===================| Server |<===================| B | 296 +-------+ B+C (RTP) +--------+ B (RTP) +-------+ 297 " 298 " 299 " A+B+C (RTP) 300 " 301 v 302 +----------+ 303 | Recorder | 304 +----------+ 305 * 306 ****> (A+B+C).wav, (A+B+C).h263 308 Figure 4: Recorder as a passive participant 310 Whether or not the mixer is MEDIACTRL-based, it's quite likely that 311 the AS handling the multimedia conference business logic has some 312 control on the mixing involved. This means it can request the 313 recording of each available audio and/or video mix in a conference, 314 if only by adding the passive participant as mentioned above. 315 Besides, events occurring at the media level or business logic in the 316 AS itself allow the AS to take note of timing information for each of 317 the recorded media. For instance, the AS may take note of when the 318 video mixing started, in order to properly tag the video recording in 319 the tagging phase. Both the recordings and the timing events list 320 would subsequently be used in order to prepare the metadata 321 information of the audio and video in the overall session recording 322 description. Such a phase is described in Section 5.2.1. 324 In a MEDIACTRL Media Server, such a functionality might be 325 accomplished by means of the Mixer Control Package 326 [I-D.ietf-mediactrl-mixer-control-package]. At the end of the 327 conference, URLs to the actual recordings would be made available for 328 the AS to use. The AS might then subsequently access those 329 recordings according to its business logic, e.g. to store them 330 somewhere else (the MS storage might be temporary) or to implement an 331 offline transcoding and/or mixing of all the recordings in order to 332 obtain a single file representative of the whole audio/video 333 participation in the conference. Practical examples of these 334 scenarios are presented in [I-D.ietf-mediactrl-call-flows]. 336 Of course, if the recording of a mix is not possible or desired, one 337 could still fallback to the first approach, that is individually 338 recording all the incoming contributions. It is the case, for 339 instance, of conferencing systems which don't implement video mixing, 340 but just rely instead on a switching/forwarding of the potentially 341 several video streams to each participant. This functionality can 342 also be achieved by means of the same control package previously 343 introduced, since it allows for the recording of both mixes and 344 individual connections. Once the conference ends, the AS can then 345 decide what to do with the recordings, e.g. mixing them all together 346 offline (thus obtaining an overall mix) or leave them as they are. 347 The tagging process would the subsequently take the decision into 348 account, and address the resulting media accordingly. 350 4.2. Chat 352 What has been said about audio and video partially applies to text 353 chats as well. In fact, just as for audio and video a central mixer 354 is usually involved, for instant messaging most of the times the 355 contributions by all participants pass through a central node from 356 where they are forwarded to the other participants. It is the case, 357 for instance, of XMPP [RFC3920] and MSRP [RFC4975] based text 358 conferences. If so, recording of the text part of a conference is 359 not hard to achieve either. The AS just needs to implement some form 360 of logging, in order to store all the messages flowing through the 361 text conference central node, together with information on the 362 senders of these messages and timing-related information. Of course, 363 the AS may not directly be the text conference mixer: the same 364 considerations apply, however, in the sense that the remote mixer 365 must be able to implement the aforementioned logging, and must be 366 able to receive related instructions from the controlling AS. 367 Besides, considering the possible protocol-agnostic nature of the 368 conferencing system (as envisaged in [RFC5239]), several different 369 instant messaging protocols may be involved in the same conference. 370 Just as the conferencing system would act as a protocol gateway 371 during the lifetime of the conference (i.e. provide MSRP users with 372 the text coming from XMPP participants and viceversa), all the 373 contributions coming from the different instant messaging protocols 374 would need to be recorded in the same log, and in the same format, to 375 avoid ambiguity later on. 377 An example of a recorder for instant messaging is presented in 378 Figure 5. 380 +-------+ 381 | UAC-C | 382 +-------+ 383 ^ 384 C (MSRP) " '10.11.24 Hi!' 385 " 386 " 387 v 388 +-------+ A (XMPP) +----------+ B (IRC) +-------+ 389 | UAC-A |<==================>| Recorder |<==================>| UAC-B | 390 +-------+ '10.11.26 Hey C' +----------+ '10.11.30 Hey man' +-------+ 391 * 392 * 393 * [..] 394 ****> 10.11.24 Hi! 395 ****> 10.11.26 Hey C 396 ****> 10.11.30 Hey man 397 [..] 399 Figure 5: Recording a text conference 401 The same considerations already mentioned about optional policies 402 involved apply to text conferences as well: i.e., if a UAC is not 403 allowed to contribute text to the chat, this contribution is excluded 404 both from the mix the other participants receive and from the ongoing 405 recording. 407 Considerations about the format of the recording are left to 408 Section 5.2.2. Until then, we just assume the AS has a way to record 409 text conferences somehow in a format it is familiar with. This 410 format would subsequently be converted to another, standard, format 411 that a player would be able to access. 413 4.3. Slides 415 Another media typically available in a multimedia conference over the 416 internet is the slides presentation. In fact, slides, whatever 417 format they're in, are still the most common way of presenting 418 something within a collaboration framework. The problem is that, 419 most of the times, these slides are deployed in a proprietary way 420 (e.g. Microsoft Powerpoint and the like). This means that, besides 421 the recording aspect of the issue, the delivery itself of such a 422 slides can be problematic when considered in a standards based 423 conferencing framework. 425 Considering that no standard way of implementing such a functionality 426 is commonly available yet, we assume that a conferencing framework 427 makes such slides available to the participants in a conference as a 428 slideshow, that is, a series of static images whose appearance might 429 be dictated by a dedicated protocol. For instance, a presenter may 430 trigger the change of a slide by means of an instant messaging 431 protocol, providing each authorized participant with an URL from 432 where to get the current slide with optional metadata to describe its 433 content. 435 An example is presented in Figure 6. The presenter has previously 436 uploaded its presentation converted in a proprietary format. The 437 presentation has been converted to images and a description of the 438 new format has been sent back to the presenter (e.g. an XML 439 metadata). At this point, the presenter makes use of XMPP to inform 440 the other participants about the current slide, by providing an HTTP 441 URL to the related image. 443 +-----------+ 444 | Presenter | 445 +-----------+ 446 " 447 (XMPP) " Current presentation: f44gf 448 " Current slide number: 4 449 " URL: http://example.com/f44gf/4.jpg 450 " 451 v 452 +-------+ (XMPP) +----------+ (XMPP) +-------+ 453 | UAC-A |<===================| ConfServ |===================>| UAC-B | 454 +-------+ +----------+ +-------+ 455 | | 456 | HTTP GET (http://example.com/f44gf/4.jpg) | 457 v HTTP GET (http://example.com/f44gf/4.jpg) | 458 v 460 Figure 6: Presentation sharing via XMPP 462 From this assumption, the recording of each slide presentation would 463 be relatively trivial to achieve. In fact, the AS would just need to 464 have access to the set of images (with the optional metadata 465 involved) of each presentation, and to the additional information 466 related to presenters and to when each slide was triggered. For 467 instance, the AS may take note of the fact that slide 4 from 468 presentation "f44gf" of the example above has been presented by UAC 469 "spromano" from the second 56 of the conference to the second 302. 470 Properly recording all those events would allow for a subsequent 471 tagging, thus allowing for the integration of this medium in the 472 whole session recording description together with the other media 473 involved. This phase will be described in Section 5.2.3. 475 4.4. Whiteboard 477 To conclude the overview on the analysed media, we consider a further 478 medium which is quite commonly deployed in multimedia conferences: 479 the shared whiteboard. There are several ways of implementing such a 480 functionality. While some standard solutions exist, they are rarely 481 used within the context of commercial conferencing application, which 482 usually prefer to implement it in a proprietary fashion. 484 Without delving into a discussion on this aspect, suffices it to say 485 that for a successful recording of a whiteboard session most of the 486 times it is enough to just record the individual contributions of 487 each involved participant (together with the usual timing-related 488 information). In fact, this would allow for a subsequent replay of 489 the whiteboard session in an easy way. Unlike audio and video, 490 whiteboarding usually is a very lightweight media, and so recording 491 the individual contributions rather than the resulting mix (as we 492 suggested in Section 4.1) is advisable. These contributions may 493 subsequently be mixed together in order to obtain a standard 494 recording (e.g. a series of images, animations, or even a low 495 framerate video). An example of recording for this medium is 496 presented in Figure 7. 498 +-------+ 499 | UAC-C | 500 +-------+ 501 " 502 C (XMPP) " 10.11.20: line 503 " 504 " 505 v 506 +-------+ A (XMPP) +-----------+ B (XMPP) +-------+ 507 | UAC-A |===================>| WB server |<===================| UAC-B | 508 +-------+ 10.10.56: circle +-----------+ 10.12.30: text +-------+ 509 * 510 * 511 * 512 ****> 10.10.56: circle (A) 513 ****> 10.11.20: line (C) 514 ****> 10.12.30: text (B) 516 Figure 7: Recording a whiteboard session 518 The recording process may be enriched by the population of a parallel 519 event list. For instance, optimizations might include event as the 520 creation of a new whiteboard, the clearing of an existing whiteboard 521 or the adding of a background image that replaced the previously 522 existing content. Such event would be precious in a subsequent 523 playout of the recorded steps, since they would allow for a more 524 lightweight replication in case seeking is involved. For instance, 525 if 70 drawings have been done, but at second 560 of the conference 526 the whiteboard has been cleared and since then only 5 drawings have 527 been added, a viewer seeking to second 561 would just need the 528 clear+5 drawings to be replicated. Anyway, further discussion upon 529 the tagging process of this media is presented in Section 5.2.4. 531 5. Tagging 533 Once the different media have been recorded and stored, and their 534 timing related somehow, this information needs to be properly tagged 535 in order to allow intra-media and inter-media synchronization in case 536 a playout is invoked. Besides, it would be desirable to make use of 537 standard means for achieving such a functionality. For these 538 reasons, we chose to make use of the Synchronized Multimedia 539 Integration Language [W3C.CR-SMIL3-20080115], which fulfills all the 540 aforementioned requirements, besides being a well-established W3C 541 standard. In fact, timing information is very easy to address using 542 this specification, and VCR-like controls (start, pause, stop, 543 rewind, fast forward, seek and the like) are all easily deploayble in 544 a player using the format. 546 The SMIL specification provides means to address different media by 547 using custom tags (e.g. audio, img, textstream and so on), and for 548 each of these media the related tempification can be easily 549 described. The following subsections will describe how a SMIL 550 metadata could be prepared in order to map with the media recorded as 551 described in Section 4. 553 Specifically, considering how a SMIL file is assumed to be 554 constructed, the head will be described in Section 5.1, while the 555 body (with different focus for each media) will be presented in 556 Section 5.2. 558 5.1. SMIL Head 560 As specified in [W3C.CR-SMIL3-20080115], a SMIL file is composed of 561 two separate sections: a head and a body. The head, among all the 562 needed information, also includes details about the allowed layouts 563 for a multimedia presentation. Considering the amount of media that 564 might have been involved in a single conference, properly 565 constructing such a section definitely makes much sense. In fact, 566 all the involved media need to be placed in order not to prevent 567 access to other concurrent media within the context of the same 568 recording. 570 For instance, this is how a series of different media might be placed 571 in a layout according to different screen resolutions: 573 574 575 576 577 578 579 581 583 585 587 588 589 590 591 593 595 597 599 601 602 603 [..] 605 That said, it's important that this section of the SMIL file be 606 constructed properly. In fact, the layout description also contains 607 explicit region identifiers, which are referred to when describing 608 media in the body section. 610 TBD. (?) 612 5.2. SMIL Body 614 The SMIL head section described previously is very important for what 615 concerns presentation-related settings, but does not contain any 616 timing-related information. Such information, in fact, belongs to a 617 separate section in the SMIL file, the so called body. This body 618 contains the information on all the involved media in the recorded 619 session, and for each media timing information are provided. This 620 timing information includes not only when each media appears and when 621 it goes away, but also details on the media lifetime as well. By 622 correlating the timing information for each media, a SMIL reader can 623 infer inter-media synchronization and present the recorded session as 624 it was conceived to appear. 626 Besides, the involved media can be grouped in the body in order to 627 implement sequential and/or parallel playback involving a subset of 628 the available media. This is made possible by making use of the 629 and elements. The element in particular is of 630 great interest to this document, since in a multimedia conference 631 many media are presented to participants at the same time. 633 That said, it is important to be able to separately address each 634 involved medium. To do so, SMIL makes use of well specified 635 elements. For instance, a