idnits 2.17.1 draft-kyzivat-siprec-webconf-use-case-00.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 16, 2013) is 3997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3261' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-siprec-metadata' is defined on line 238, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-07 == Outdated reference: A later version (-18) exists of draft-ietf-siprec-protocol-09 == Outdated reference: A later version (-22) exists of draft-ietf-siprec-metadata-11 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC P. Kyzivat 3 Internet-Draft M. Yan 4 Intended status: Informational Huawei 5 Expires: November 17, 2013 May 16, 2013 7 Web Conference Recording Use Case 8 draft-kyzivat-siprec-webconf-use-case-00 10 Abstract 12 The current work of SIPREC will soon finish. As its charter defined, 13 SIPREC has covered industries like financial trading floors, contact 14 center and emergency service bureaus. But when talking about 15 products or solutions like data or web conferencing, SIPREC is 16 insufficient to record all aspects of calls with different 17 interactive media channels. This draft tries to show a use case for 18 web conference recording and show how it can work well under SIPREC 19 mechanism. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 17, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Web Conference . . . . . . . . . . . . . . . . . . . . . 2 63 1.2. Multimedia Recording and Layout . . . . . . . . . . . . . 3 64 1.3. Recording Session . . . . . . . . . . . . . . . . . . . . 4 65 2. Requirements for Web Conference Recording . . . . . . . . . . 4 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 5. Informative References . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 1.1. Web Conference 75 In general, a basic video conference has participants with video 76 channels and audio channels with DTMF ability. A more complex 77 multimedia conference would have text, interactive text and 78 presentation graphics [RFC4597]. A web conference, known as a 79 webinar or, for interactive conferences, online workshop, refers to a 80 service that allows conferencing events to be shared with remote 81 locations. It has needs for recording as strong as those for 82 financial trading floors and contact centers. The host and 83 participants, and even nonparticipants, would like to play back the 84 conference recording for further purposes, like editing a conference 85 summary, reviewing conference outlines or replaying the whole 86 conference process. The recording should reconstruct, as much as 87 possible, the web conference including all media types not only audio 88 /video but also IM, data sharing and even presentation information 89 like layout. Such an exhaustive reconstruction could give audiences 90 more information and a better experience. 92 1.2. Multimedia Recording and Layout 94 There is one use case covering the recording of a multi-channel and 95 multimedia session in the existing use case document [RFC6341]. 96 Aside from audio, video and IM, it does not mention other interaction 97 modalities. The limitations of the multi-channel typies leads to 98 poor support for web conference recording. A web conference has 99 various media types, including audio, video, IM, data sharing(desktop 100 /document/application/whiteboard) and polling. SIPREC is already 101 mostly capable of recording any sort of RTP media sessions, including 102 voice, DTMF, video, and text [RFC6341] with SDP negotiation 103 [I-D.ietf-siprec-protocol]. But it is not evident how to support the 104 remaining media. 106 The media streams like desktop/document/application/whiteboard 107 sharing could be managed as still images (snapshots with increments) 108 or as dynamic streams (video streams) to cover details like 109 annotating, direct editing or page turning. The still image could be 110 also treated as the payload in rtp stream. For instance, one 111 snapshot bitmap from desktop could be inserted as an I frame of a 112 recording RTP stream that uses the SIP recording mechanism. So those 113 streams could be recorded via RTP stream. 115 In many cases the conference server controls the layout views of 116 media data, especially for video streams, on the screens of the 117 participants in the conference. In addition, participants or 118 conference host might change the layout for their preferred pane 119 assignment. When participants act the SRC and make the recording for 120 themselves, they might use their own layout for special purpose, like 121 put the IM session into the larger pane temporarily for writing some 122 key details into a summary, or permanently close the less significant 123 participants' video stream outputs to earn a larger pane for slide 124 sharing of a online class training . It would be useful to have 125 information about how that was done for each participant, and the 126 recommended way of doing it for after-the-fact viewers, as part of 127 the recording, so that the playbacks can do a proper rendering. 129 The layout of a web conference is used to decide how to organize the 130 multi-windows, when playing back the recording, considered as a set 131 of predefined video presentations offered by the server [RFC4597]. 132 Take video recording as an example. There are some key crucial 133 factors, like the desired recording resolution or largest active 134 speaker, that affect SRC/SRS decisions about how many video streams 135 (participants) are viewed at once and the layout of these video 136 streams on the screen [RFC4597]. And the data sharing's content 137 [RFC4796] could also effect the layout in a web conference when 138 presenting with video channels together. These layout metadata could 139 be defined by SRC or by config/default setting on SRS. If it is 140 defined by SRC, the metadata could be delivered to SRS at the 141 beginning of the RS, and updated with the increments later. 143 Below is a simple example for the layout of a web conference. A is 144 for participant list, B is for IM, while C is for desktop sharing. 145 And D1, D2, D3 are to support different video windows from each 146 participant. 148 +----------------+----------------------------+ 149 | | | 150 | A | | 151 | | C | 152 +----------------+ | 153 | | | 154 | B +--------+---------+---------+ 155 | | D1 | D2 | D3 | 156 +----------------+--------+---------+---------+ 158 Figure 1: The Layout of A Web Conference 160 1.3. Recording Session 162 One way for a conference focus to record a conference is introduced 163 in [I-D.ietf-siprec-architecture]. This defines how the conference 164 focus works as an SRC to deliver RTP streams and associate recording 165 metadata to SRS. It may choose the recording RTP stream type, 166 separated or mixed. There are more details about how to use SDP, RTP 167 for recording by participant or by media type in 168 [I-D.ietf-siprec-protocol]. The focus may setup different recording 169 sessions for different media streams recorded separately, or one 170 recording session for a mixed media stream created by the SRC, or 171 even multiplexing different media streams in a single RTP recording 172 session[I-D.ietf-siprec-protocol]. 174 But more is needed to support other media streams in a web 175 conference. There is need for a new type of "media stream" for data 176 sharing, distinct from the main video streams, with different m-lines 177 or metadata. Other new "media stream" types are needed for delivery 178 of SIP based IM message and polling message. There is also need of a 179 mechanism for the SRC to bound the number of media streams to be 180 recorded, especially when the participant number in a conference is 181 large. 183 Recording XMPP based IM in CS is out of the scope for this proposal. 184 It may be added later. 186 2. Requirements for Web Conference Recording 187 1. The mechanism MUST support MSRP media stream recording. 189 2. The mechanism MUST support data sharing recording, data sharing 190 including desktop/document/application/whiteboard. 192 3. The mechanism MUST support polling recording. 194 4. The mechanism MUST support record the layout of web conference, 195 if SRC offer the details. The layout details can be adjusted by 196 demand. 198 3. IANA Considerations 200 This document contains no IANA considerations. 202 4. Security Considerations 204 Not explicitly covered in this version. 206 5. Informative References 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 212 A., Peterson, J., Sparks, R., Handley, M., and E. 213 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 214 June 2002. 216 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 217 4597, August 2006. 219 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 220 Protocol (SDP) Content Attribute", RFC 4796, February 221 2007. 223 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 224 Cases and Requirements for SIP-Based Media Recording 225 (SIPREC)", RFC 6341, August 2011. 227 [I-D.ietf-siprec-architecture] 228 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 229 Architecture for Media Recording using the Session 230 Initiation Protocol", draft-ietf-siprec-architecture-07 231 (work in progress), November 2012. 233 [I-D.ietf-siprec-protocol] 234 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 235 Hutton, "Session Recording Protocol", draft-ietf-siprec- 236 protocol-09 (work in progress), December 2012. 238 [I-D.ietf-siprec-metadata] 239 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 240 Protocol (SIP) Recording Metadata", draft-ietf-siprec- 241 metadata-11 (work in progress), January 2013. 243 Authors' Addresses 245 Paul H. Kyzivat 246 Huawei 248 Email: pkyzivat@alum.mit.edu 250 Michael Yan 251 Huawei 253 Email: michael.yan@huawei.com