SIPREC P. Kyzivat
Internet-Draft M. Yan
Intended status: Informational Huawei
Expires: November 17, 2013 May 16, 2013

Web Conference Recording Use Case
draft-kyzivat-siprec-webconf-use-case-00

Abstract

The current work of SIPREC will soon finish. As its charter defined, SIPREC has covered industries like financial trading floors, contact center and emergency service bureaus. But when talking about products or solutions like data or web conferencing, SIPREC is insufficient to record all aspects of calls with different interactive media channels. This draft tries to show a use case for web conference recording and show how it can work well under SIPREC mechanism.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 17, 2013.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

1.1. Web Conference

In general, a basic video conference has participants with video channels and audio channels with DTMF ability. A more complex multimedia conference would have text, interactive text and presentation graphics [RFC4597]. A web conference, known as a webinar or, for interactive conferences, online workshop, refers to a service that allows conferencing events to be shared with remote locations. It has needs for recording as strong as those for financial trading floors and contact centers. The host and participants, and even nonparticipants, would like to play back the conference recording for further purposes, like editing a conference summary, reviewing conference outlines or replaying the whole conference process. The recording should reconstruct, as much as possible, the web conference including all media types not only audio/video but also IM, data sharing and even presentation information like layout. Such an exhaustive reconstruction could give audiences more information and a better experience.

1.2. Multimedia Recording and Layout

There is one use case covering the recording of a multi-channel and multimedia session in the existing use case document [RFC6341]. Aside from audio, video and IM, it does not mention other interaction modalities. The limitations of the multi-channel typies leads to poor support for web conference recording. A web conference has various media types, including audio, video, IM, data sharing(desktop/document/application/whiteboard) and polling. SIPREC is already mostly capable of recording any sort of RTP media sessions, including voice, DTMF, video, and text [RFC6341] with SDP negotiation [I-D.ietf-siprec-protocol]. But it is not evident how to support the remaining media.

The media streams like desktop/document/application/whiteboard sharing could be managed as still images (snapshots with increments) or as dynamic streams (video streams) to cover details like annotating, direct editing or page turning. The still image could be also treated as the payload in rtp stream. For instance, one snapshot bitmap from desktop could be inserted as an I frame of a recording RTP stream that uses the SIP recording mechanism. So those streams could be recorded via RTP stream.

In many cases the conference server controls the layout views of media data, especially for video streams, on the screens of the participants in the conference. In addition, participants or conference host might change the layout for their preferred pane assignment. When participants act the SRC and make the recording for themselves, they might use their own layout for special purpose, like put the IM session into the larger pane temporarily for writing some key details into a summary, or permanently close the less significant participants' video stream outputs to earn a larger pane for slide sharing of a online class training . It would be useful to have information about how that was done for each participant, and the recommended way of doing it for after-the-fact viewers, as part of the recording, so that the playbacks can do a proper rendering.

The layout of a web conference is used to decide how to organize the multi-windows, when playing back the recording, considered as a set of predefined video presentations offered by the server [RFC4597]. Take video recording as an example. There are some key crucial factors, like the desired recording resolution or largest active speaker, that affect SRC/SRS decisions about how many video streams (participants) are viewed at once and the layout of these video streams on the screen [RFC4597]. And the data sharing's content [RFC4796] could also effect the layout in a web conference when presenting with video channels together. These layout metadata could be defined by SRC or by config/default setting on SRS. If it is defined by SRC, the metadata could be delivered to SRS at the beginning of the RS, and updated with the increments later.

Below is a simple example for the layout of a web conference. A is for participant list, B is for IM, while C is for desktop sharing. And D1, D2, D3 are to support different video windows from each participant.

           
    +----------------+----------------------------+
    |                |                            |
    |        A       |                            |
    |                |              C             |
    +----------------+                            |
    |                |                            |
    |        B       +--------+---------+---------+
    |                |   D1   |    D2   |    D3   |
    +----------------+--------+---------+---------+
                     		

Figure 1: The Layout of A Web Conference

1.3. Recording Session

One way for a conference focus to record a conference is introduced in [I-D.ietf-siprec-architecture]. This defines how the conference focus works as an SRC to deliver RTP streams and associate recording metadata to SRS. It may choose the recording RTP stream type, separated or mixed. There are more details about how to use SDP, RTP for recording by participant or by media type in [I-D.ietf-siprec-protocol]. The focus may setup different recording sessions for different media streams recorded separately, or one recording session for a mixed media stream created by the SRC, or even multiplexing different media streams in a single RTP recording session[I-D.ietf-siprec-protocol].

But more is needed to support other media streams in a web conference. There is need for a new type of "media stream" for data sharing, distinct from the main video streams, with different m-lines or metadata. Other new "media stream" types are needed for delivery of SIP based IM message and polling message. There is also need of a mechanism for the SRC to bound the number of media streams to be recorded, especially when the participant number in a conference is large.

Recording XMPP based IM in CS is out of the scope for this proposal. It may be added later.

2. Requirements for Web Conference Recording

  1. The mechanism MUST support MSRP media stream recording.
  2. The mechanism MUST support data sharing recording, data sharing including desktop/document/application/whiteboard.
  3. The mechanism MUST support polling recording.
  4. The mechanism MUST support record the layout of web conference, if SRC offer the details. The layout details can be adjusted by demand.

3. IANA Considerations

This document contains no IANA considerations.

4. Security Considerations

Not explicitly covered in this version.

5. Informative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, February 2007.
[RFC6341] Rehor, K., Portman, L., Hutton, A. and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, August 2011.
[I-D.ietf-siprec-architecture] Hutton, A., Portman, L., Jain, R. and K. Rehor, "An Architecture for Media Recording using the Session Initiation Protocol", Internet-Draft draft-ietf-siprec-architecture-07, November 2012.
[I-D.ietf-siprec-protocol] Portman, L., Lum, H., Eckel, C., Johnston, A. and A. Hutton, "Session Recording Protocol", Internet-Draft draft-ietf-siprec-protocol-09, December 2012.
[I-D.ietf-siprec-metadata] R, R., Ravindran, P. and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", Internet-Draft draft-ietf-siprec-metadata-11, January 2013.

Authors' Addresses

Paul H. Kyzivat Huawei EMail: pkyzivat@alum.mit.edu
Michael Yan Huawei EMail: michael.yan@huawei.com