XCON R. Even Internet-Draft Polycom Intended status: Best Current March 1, 2007 Practice Expires: September 2, 2007 People and Content video streams draft-even-xcon-pnc-02.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 September 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Even Expires September 2, 2007 [Page 1] Internet-Draft PNC March 2007 Abstract This document describes the procedures for using more than one video channel in SIP based systems enabling the other endpoints to understand the semantics 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. 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 3.2.1. Floor management policy . . . . . . . . . . . . . . . 6 3.2.2. Floor management for audio and video presentation . . 6 4. Offer answer flow . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Live role using the content alt attribute . . . . . . . . 8 4.2. Presentation role with floor control . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Even Expires September 2, 2007 [Page 2] Internet-Draft PNC March 2007 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 has a role as described using the content attribute described in draft-ietf-mmusic-sdp-media-content- 01[I-D.draft-ietf-mmusic-sdp-media-content]. Floor control is 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 September 2, 2007 [Page 3] Internet-Draft PNC March 2007 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 September 2, 2007 [Page 4] Internet-Draft PNC March 2007 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 assigns application semantics to the additional video stream explaining how the streams should be presented to and processed by endpoints and MCUs. Under H.239, video streams are given either 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 similar policies used on the main video stream. The "Live" role is signaled using the "alt" content attribute from draft-ietf-mmusic-sdp-media-content- 01[I-D.draft-ietf-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 their application policies that define media distribution policies. The recommended policy is for the MCUs to distribute a device's "Live" video stream to all participants who are also receiving the other video stream from the device. Floor control may be used on the "main" and "alt" stream as a group. 3.2. Presentation role procedures The H.239 "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 Even Expires September 2, 2007 [Page 5] Internet-Draft PNC March 2007 transmission. Generally, the Presentation channel when 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 attribute from draft-ietf-mmusic-sdp-media-content- 01[I-D.draft-ietf-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. An endpoint that receives the presentation SHALL not transmit video if it does not own the floor. 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. 3.2.1. Floor management policy The floor control sever according to H.239 makes automatic decisions, there is no floor chair. There is one floor used in this application. In a multipoint conference, H.239 does not mandate a specific policy. A RECOMMENDED policy for multipoint conference is for the floor control server to grant the floor if it is not assigned. If the floor is assigned the floor control server will send a FloorRequestStatus with state revoke to the current floor owner and wait for FloorRelease message from the current owner before granting the floor to the requesting participant. In a point to point call, one of the parties is also the floor control server. The other party may request the floor and the request will be granted if the party with the floor control server will not need it. 3.2.2. Floor management for audio and video presentation The floor control server application can manage the video presentation and the main audio as a group controlled by one floor. In this case the MCU will treat the video stream as described in 3.2 and the audio stream will always be in the mix even if it is currently not one of the highest speaker. The floor control server will indicate the streams controlled by the floor in the floor id attribute by listing both labels in the m-stream parameter as in the following example. v=0 o=Laura 289083124 289083124 IN IP4 one.example.com Even Expires September 2, 2007 [Page 6] Internet-Draft PNC March 2007 t=0 0 c=IN IP4 192.0.2.1 m=audio 30000 RTP/AVP 0 a=content:main a=label:11 m=video 30002 RTP/AVP 31 a=content:main a=label:12 m=audio 30004 RTP/AVP 0 a=content:alt a=label:13 m=application 20000 TCP/BFCP * a=setup:passive a=connection:new a=floorid:1 m-stream:11 12 a=floor-control: s-only a=confid:4321 a=userid:1234 Even Expires September 2, 2007 [Page 7] Internet-Draft PNC March 2007 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 is a view of all the room using a second camera. v=0 o=Alice 292742730 29277831 IN IP4 192.0.2.3 s=Two video streams from the room c=IN IP4 192.0.2.3 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]. m=application 9 TCP/BFCP * Even Expires September 2, 2007 [Page 8] Internet-Draft PNC March 2007 a=setup:active a=connection:new a=fingerprint:SHA-1 \ 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 a=floor-control: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=fingerprint: SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=nonce:5736 a=floor-control:s-only a=confid:4321 a=userid:1234 Even Expires September 2, 2007 [Page 9] Internet-Draft PNC March 2007 a=floorid:1 m-stream:12 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 September 2, 2007 [Page 10] Internet-Draft PNC March 2007 5. IANA Considerations None Even Expires September 2, 2007 [Page 11] Internet-Draft PNC March 2007 6. Security Considerations Will be added Even Expires September 2, 2007 [Page 12] Internet-Draft PNC March 2007 7. References 7.1. Normative References [I-D.draft-ietf-mmusic-sdp-media-content] Camarillo, G. and J. Hautakorpi, "The SDP (Session Description Protocol) Content Attribute", draft-ietf-mmusic-sdp-media-content-01.txt (work in progress), February 2006. [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 September 2, 2007 [Page 13] Internet-Draft PNC March 2007 Author's Address Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel Email: roni.even@polycom.co.il Even Expires September 2, 2007 [Page 14] Internet-Draft PNC March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Even Expires September 2, 2007 [Page 15]