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
• 1.2. Multimedia Recording and Layout
• 1.3. Recording Session
• 2. Requirements for Web Conference Recording
• 3. IANA Considerations
• 4. Security Considerations
• 5. Informative References
• Authors' Addresses

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   |
    +----------------+--------+---------+---------+