Network Working Group Hongluan.Liao Internet Draft Zhenyu.Yu Intended status: Standards Track Yiwen.Wang Expires: April 23, 2011 Jin.Peng China Mobile October 19, 2010 A RELOAD Usage for Distributed Conference Media Processing draft-liao-p2psip-dcmp-00 Abstract This document defines a RELOAD Usage for Distributed Conference media processing. It describes a new distributed conference architecture which utilizing clients ability to handling media data. Different clients' ability information is stored in the RELOAD overlay with a new Kind data structure. An optimal media transmission path can be calculated with this information. 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 April 23, 2011. Copyright Notice Copyright (c) 2010 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 liao Expires April 23, 2011 [Page 1] Internet-Draft dcmp October 2010 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 ................................................ 3 2. Terminology ................................................. 3 3. System overview ............................................. 4 3.1. Architecture ........................................... 4 3.2. Entities ............................................... 5 3.2.1. CCS (Conference Control Server) .................... 5 3.2.2. CDB (Conference Database) .......................... 5 3.2.3. MCS (Media Control Server) ......................... 5 3.2.4. UE (User Equipment) ................................ 6 3.3. Kind data structure ..................................... 6 4. Scenario and procedure ....................................... 6 4.1. Create a conference ..................................... 6 4.2. Participate in a conference ............................. 6 4.3. Departure form a conference ............................. 6 4.4. State measurement and reporting ......................... 6 5. Media Process Mechanism ...................................... 6 5.1. Audio Stream Process .................................... 7 5.1.1. Audio Mixer Selection .............................. 7 5.1.2. Audio Mixer Transmission ........................... 7 5.2. Video Stream Process .................................... 7 5.2.1. Video Stream Transmission .......................... 7 5.2.2. Video Stream Dissemination ......................... 7 5.2.3. Video Stream Mixture ............................... 7 5.2.4. Video Stream Mixer Switch .......................... 7 6. Kind Definition ............................................. 7 7. Security Considerations ...................................... 8 8. IANA Considerations ......................................... 8 9. Conclusions ................................................. 8 10. Acknowledgments ............................................ 8 11. References ................................................. 8 11.1. Normative References ................................... 8 11.2. Informative References ................................. 9 Author's Addresses ............................................. 9 liao Expires April 23, 2011 [Page 2] Internet-Draft dcmp October 2010 1. Introduction In traditional video conferencing systems architecture, performance and capacity of single server is limited. It can only support a certain number of online users simultaneously, and the system stability and performance cannot be effectively guaranteed. Large- scale conference systems require multiple servers to work together. Each server provides services for different user groups, and there is audio and video transmission between the different user groups. So the server will have a large number of audio and video data transmissions, this point would be the bottleneck to improve the quality of the audio and video easily. As the network environment improves, more and more people use video conferencing to discuss, exchange and chat. Particular, conference between family members become more popular. The current mode of the video conference would have the following characteristics: o In a single meeting, the number of participants is relatively small, usually about 10 people; o There are a lot of conferences throughout the video conference system. Considering the above scenario, the scheme of traditional video conferencing (Server is responsible for all media processing) requires a very high cost. Therefore, we introduced the Distributed Conference Media Processing. On the basis of traditional software video conferencing, our project makes full use of the user node to assume the task of audio and video processing and transmission to reduce the server bandwidth and hardware resources. At the same time, conference information is stored on the distributed servers group in Reload overlay. 2. Terminology 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]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. The terminology and definitions from the RELOAD base[I-D.ietf-p2psip- base], the peer-to-peer SIP concepts draft[I-D.ietf-p2psip-concepts]. liao Expires April 23, 2011 [Page 3] Internet-Draft dcmp October 2010 MCS: Media Control Server is responsible for media processing and improvement of transmission efficiency according to the information stored in the overlay which is consist of MCS as the basic element. UE: User Equipment can execute the conference operation as a client. CCS: Conference Control Server assigns MCS to the new client joining in the conference. CDB: Conference Database stores and maintains UE, MCS and conference information. 3. System overview 3.1. Architecture This section defines the overall architecture and the main functions of each entity. Figure 1 depicts the network architecture based on Reload overlay which consists of a set of cooperating peers. The main functions of the core network are provided by the overlay in which the peers can efficiently route messages to other peers and efficiently store and retrieve conference information. +-----+ | UE1 |# +-----+ # @ # @ # @ # ******** ******** # * MCS4 *--------* MCS1 * # ******** ******** # | | +-----+ +-----+ +-----+ | Reload | | UE2 |# # # # | CCS |-----| CDB | | | @+-----+ +-----+ +-----+ ******** ******** @ # * MCS3 *--------* MCS2 * @ # ******** ******** # @ # @ # @ # +-----+ # | UE3 | +-----+ Figure 1 Distributed Conference Architecture liao Expires April 23, 2011 [Page 4] Internet-Draft dcmp October 2010 CCS and CDB is the system manager. CCS is responsible for user login, and PMS is a centralized user database. MCS is a media processing server. Each MCS is a peer in the Reload overlay, and conference information is the resources. Each UE is a client in the reload overlay. In addition, UE in different network may be assigned to different MCS to access. Users may be in different places. In the corresponding our servers will be deployed in different networks too, So that it will choose a proximal MCS for the user to be responsible for conference access. 3.2. Entities The following content includes a description of each major functional entity in distributed video conference system, and a brief introduction of each entity's behaviors and interactions with other entities. 3.2.1. CCS (Conference Control Server) According to the scale of UE, there may be many CCS in system. The main functions may include: o Responsibility for authorization and maintaining online information of UE; o Management of participating in a conference. 3.2.2. CDB (Conference Database) There is only one CDB in system. The main functions may include: o Store and maintain conference, MCS, UE information; o Accept request from CCS and return the relative data to MCS; 3.2.3. MCS (Media Control Server) According to the scale of user, there may be many MCS in system. The main functions may include: o Receive audio and video data from user, and transmit it to other UE who send a request. liao Expires April 23, 2011 [Page 5] Internet-Draft dcmp October 2010 o Based on requirement, mix the audio and video streaming or convert BitRate; o Maintain and manage capability and state information of different UE in a conference, and execute distributed algorithm; o Every MCS have only one identity and adopt Reload protocol to look up each other. 3.2.4. UE (User Equipment) UE include computer, mobile telephone, IPTV Set-Top Box, MID, etc. The main functions may include: o Send initialize, join, exit and other operation about a conference to server; o Receive and send audio and video data. 3.3. Kind data structure TODO 4. Scenario and procedure 4.1. Create a conference TODO 4.2. Participate in a conference TODO 4.3. Departure form a conference TODO 4.4. State measurement and reporting TODO 5. Media Process Mechanism This section describes the audio and video stream handling mechanism in the distributed conference. Process of audio stream is separated from the video stream and gained a higher priority than video stream. Therefore, when the video stream handling has a problem, the audio liao Expires April 23, 2011 [Page 6] Internet-Draft dcmp October 2010 stream processing can still goes on and the continuity of the conference will be ensured 5.1. Audio Stream Process 5.1.1. Audio Mixer Selection TODO . 5.1.2. Audio Mixer Transmission TODO 5.2. Video Stream Process Video stream processing is different from the audio stream processing primarily in two aspects. First, the video stream handling requires much more resources than the audio transmission, such as CPU and bandwidth. Second, the client can choose to see any others' video freely, which is more complex than audio stream process. This section will introduce the procedures of video stream processing. 5.2.1. Video Stream Transmission TODO 5.2.2. Video Stream Dissemination TODO 5.2.3. Video Stream Mixture TODO 5.2.4. Video Stream Mixer Switch TODO 6. Kind Definition TODO liao Expires April 23, 2011 [Page 7] Internet-Draft dcmp October 2010 7. Security Considerations TODO: User access authorization and authentication mechanism still need to be studied. 8. IANA Considerations This document does not specify IANA considerations. 9. Conclusions This document describes a method to utilize client ability in distributed conference application, which reduce servers load. Through storing client information in RELOAD overlay, it's easy to find an optimal transmission path. However, the transmission model and method still need to be further studied. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-11 (work in progress), Oct 2010. [3] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "A SIP Usage for RELOAD", draft-ietf- p2psip-sip-05 (work in progress), July 9, 2010. [4] A. Knauf, G. Hege, T C. Schmidt, HAW Hamburg, M. Waehlisch, "A RELOAD Usage for Distributed Conference Control (DisCo)", draft-knauf-p2psip-disco-00, June 28, 2010. liao Expires April 23, 2011 [Page 8] Internet-Draft dcmp October 2010 11.2. Informative References Author's Addresses Hongluan liao China Mobile Communications Corporation Phone: +8610-6600-6688 ext. 3214 Email: liaohongluan@chinamobile.com Zhenyu Yu China Mobile Communications Corporation Phone: +86 10 66006688 Email: buptyzy@139.com Yiwen Wang China Mobile Communications Corporation Phone: +86 10 66006688 Email: ewangbupt@139.com Jin Peng China Mobile Communications Corporation Phone: +8610-6600-6688 ext. 3252 Email: pengjin@chinamobile.com liao Expires April 23, 2011 [Page 9]