XCON R. Even Internet-Draft Polycom Expires: March 5, 2006 September 2005 People and Content video streams draft-even-xcon-pnc-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the procedures for using more than one video channel in SIP based systems enabling the other endpoints to understand the content of each channel. The document describe how to label individual channels with a "role". The "role" indicates the requirements for processing the channel and the role of the channel content in the SIP call. The procedure address multipoint and point to point scenarios. Even Expires March 5, 2006 [Page 1] Internet-Draft PNC September 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Dual Stream framework . . . . . . . . . . . . . . . . . . . . 5 3.1. Live role procedures . . . . . . . . . . . . . . . . . . . 5 3.2. Presentation role procedures . . . . . . . . . . . . . . . 5 4. Offer answer flow . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Live role using the content alt attribute . . . . . . . . 7 4.2. Presentation role with floor control . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Even Expires March 5, 2006 [Page 2] Internet-Draft PNC September 2005 1. Introduction The document describes the procedures for using more than one video channel during the conference. The first video channel is used to transmit video from the main camera. The second video channel may have a role described using the content attribute described in draft-ietf-mmusic-sdp-media-content-00[I-D.hautakorpi-mmusic-sdp- media-content]. Floor control may be used based on BFCP[I-D.ietf- xcon-bfcp] The procedures described in the document can be used for multipoint or point to point scenarios and are interoperable with the procedures described in ITU H.239[ITU.H239] recommendation. Even Expires March 5, 2006 [Page 3] Internet-Draft PNC September 2005 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 RFC2119 [RFC2119] and indicate requirement levels for compliant RTP implementations. Even Expires March 5, 2006 [Page 4] Internet-Draft PNC September 2005 3. Dual Stream framework H.239[ITU.H239] is the ITU standard for implementing "People + Content" functionality in H.323 and H.320 systems. H.239 specifies mechanisms for adding additional media channels to conferences, and how to control presentation video during a multipoint conference involving H.320/H.323 based signaling systems. H.239 includes the concept of roles, a notion that spells out the purpose of the additional video stream and how the streams should be presented to and processed by endpoints and MCUs. Under H.239, video streams are given a role of 'Live', meaning that the video stream is processed as a normal, bidirectional stream, or 'Presentation', meaning that the stream is defined as a presentation to be distributed to all endpoints. H.239 also makes it possible for users to hand-off the role of presenter between endpoints during the meeting using a floor control mechanism. 3.1. Live role procedures The "Live" role indicates that the second video channel shall be distributed, managed, and presented using the traditional means. The "Live" role is signalled using the alt content attribute from draft-ietf-mmusic-sdp-media-content-00[I-D.hautakorpi-mmusic-sdp- media-content]. The "Live" role is appropriate for live video of meeting participants. The "Live" video channel supplements the main video channel - it should carry a stream which is less important to display at end-user systems than the Presentation channel, main channel or channels without role labels. "Live" video is two-way transmission; multiple devices may transmit "Live" video simultaneously. MCUs that support roles and process "Live" video streams distribute all live video in accordance with manufacturer-defined conference policies. MCUs should distribute a device's "Live" video stream to all participants who are also receiving the other video stream from the device. 3.2. Presentation role procedures The "Presentation" role is used to indicate that the video channel contains a presentation which is intended to be seen by all conference participants. Transmission on the Presentation channel shall be managed by a floor control mechanism using BFCP[I-D.ietf- xcon-bfcp], in order to provide the one-way transmission. Generally, the Presentation channel when it is in use should carry the stream which is most important to display at end-user systems. The "presentation" channel is described using the slides content Even Expires March 5, 2006 [Page 5] Internet-Draft PNC September 2005 attribute from draft-ietf-mmusic-sdp-media-content-00[I-D.hautakorpi- mmusic-sdp-media-content] For the "Presentation" role, MCUs shall distribute the presentation video to all devices in the conference which support the "Presentation" role and its associated video mode. It is optional to send the presentation video to the sender. The MCU shall also manage the presentation token in a multipoint call (grants the token). The MCU shall be the floor control server for the "Presentation" channel token. Even Expires March 5, 2006 [Page 6] Internet-Draft PNC September 2005 4. Offer answer flow 4.1. Live role using the content alt attribute The following is an example of an offer of two video streams. The first is the main camera from the room and the second in a view of all the room using a second camera. v=0 o=Alice 292742730 29277831 IN IP4 131.163.72.4 s=Two video streams from the room c=IN IP4 131.164.74.2 t=0 0 m=video 52886 RTP/AVP 31 a=rtpmap:31 H261/9000 a=content:main label:10 m=video 53334 RTP/AVP 31 a=rtpmap:31 H261/9000 a=content:alt a=label:11 4.2. Presentation role with floor control In this scenario there are two video streams. The first is the main conference video, the second is a presentation. The right to send the presentation is controlled by a floor token. One of the users or the MCU may initiate the floor control channel. In the case of multipoint the MCU shall be the floor control server. The following is an example of an offer sent by a client to a MCU based on ietf-mmusic-sdp-bfcp[I-D.ietf-mmusic-sdp-bfcp]. The 'crypto' attribute is used to generate a shared secret between the client and the floor control server. Even Expires March 5, 2006 [Page 7] Internet-Draft PNC September 2005 m=application 9 TCP/BFCP * a=setup:active a=connection:new a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA== a=floorctrl:c-only m=audio 25000 RTP/AVP 0 a=label:10 m=video 35000 RTP/AVP 31 a=content:main a=label:11 m=video 35100 RTP/AVP 31 a=content:slides a=label:12 The following is the answer returned by the MCU. The MCU assign a floor only to the presentation channel. m=application 20000 TCP/BFCP * a=setup:passive a=connection:new a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA== a=nonce:5736 a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 m-stream:12 Even Expires March 5, 2006 [Page 8] Internet-Draft PNC September 2005 m=audio 20000 RTP/AVP 0 a=label:10 m=video 30000 RTP/AVP 31 a=content:main a=label:11 m=video 35100 RTP/AVP 31 a=content:slides a=label:12 The endpoint will initiate the floor control connection to the MCU. When the endpoint wants to start sending presentation it will send a floor request as described in draft-ietf-xcon-bfcp[I-D.ietf-xcon-bfcp]. When the endpoint receives a floor request status granted, the endpoint can start sending the presentation. The endpoint shall release the floor when done. Even Expires March 5, 2006 [Page 9] Internet-Draft PNC September 2005 5. IANA Considerations None Even Expires March 5, 2006 [Page 10] Internet-Draft PNC September 2005 6. Security Considerations Will be added Even Expires March 5, 2006 [Page 11] Internet-Draft PNC September 2005 7. References 7.1. Normative References [I-D.hautakorpi-mmusic-sdp-media-content] Camarillo, G. and J. Hautakorpi, "The SDP (Session Description Protocol) Content Attribute", draft-hautakorpi-mmusic-sdp-media-content-01.txt (work in progress), July 2005. [I-D.ietf-mmusic-sdp-bfcp] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-ietf-mmusic-sdp-bfcp-02 (work in progress), July 2005. [I-D.ietf-xcon-bfcp] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", draft-ietf-xcon-bfcp-05 (work in progress), July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [ITU.H239] International Telecommunications Union, "Role management and additional media channels", ITU-T Recommendation H.239, July 2003. Even Expires March 5, 2006 [Page 12] Internet-Draft PNC September 2005 Author's Address Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel Email: roni.even@polycom.co.il Even Expires March 5, 2006 [Page 13] Internet-Draft PNC September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Even Expires March 5, 2006 [Page 14]