AVT R. Even Internet-Draft Polycom Expires: March 2, 2005 September 2004 Far End Camera Control Payload Type draft-even-avt-h224-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document defines the syntax and the semantics of SDP parameters needed to support far end camera control protocol. In conversional video applications far end camera control protocol is used by participants to control the remote camera. The common used protocol is ITU H.281 over H.224. Even Expires March 2, 2005 [Page 1] Internet-Draft FECC September 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Far-end camera control protocol . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4.1 Registration of MIME media type application/h224 . . . . . 6 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1 Usage with the SDP Offer Answer Model . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Even Expires March 2, 2005 [Page 2] Internet-Draft FECC September 2004 1. Introduction The ITU-T recommendation H.281 [ITU.281] specifies a protocol for far end camera control. This protocol is carried in H.320 systems using H.224 [ITU.H224] H.323 annex Q specifies how to carry H.281/H.224 frames using RTP packets. The document will define the SDP[RFC2327]parameters needed to support the above far end camera control protocol in systems that use SDP Even Expires March 2, 2005 [Page 3] Internet-Draft FECC September 2004 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 2, 2005 [Page 4] Internet-Draft FECC September 2004 3. Far-end camera control protocol This protocol is based on ITU-T H.281 running over ITU-T H.224 in an RTP/UDP channel. H.323 annex Q specifies how to build the RTP packets from the H.224 packets. Using far end camera control protocol in point to point calls and multipoint calls is described in H.281 and H.323 annex Q Even Expires March 2, 2005 [Page 5] Internet-Draft FECC September 2004 4. IANA Considerations This section describes the MIME types and names associated with this payload format. The section registers the MIME types, as per RFC2048[RFC2048] 4.1 Registration of MIME media type application/h224 MIME media type name: application MIME subtype name: H224 Required parameters: None Optional parameters: None Encoding considerations: This type is only defined for transfer via RTP [RFC3550] Security considerations: See Section 6 Interoperability considerations: Terminals that will like to send far end camera control command should use this MIME type, receivers who can not support the protocol will reject the channel. Published specification: RFC yyy Applications which use this media type: Video conferencing applications. Additional information: none Person and email address to contact for further information : Roni Even: roni.even@polycom.co.il Intended usage: COMMON Author/Change controller: Roni Even Even Expires March 2, 2005 [Page 6] Internet-Draft FECC September 2004 5. SDP Parameters The MIME media type application/h224 string is mapped to fields in the Session Description Protocol (SDP) as follows: o The media name in the "m=" line of SDP MUST be application. The transport SHOULD be RTP and the payload type is dynamic. o The encoding name in the "a=rtpmap" line of SDP MUST be h224 (the MIME subtype). o The clock rate in the "a=rtpmap" line MUST be 0. The recommended maximum bandwidth for this protocol is 6.4 kbit/sec. 5.1 Usage with the SDP Offer Answer Model When offering FECC using SDP in an Offer/Answer model[RFC3264] the following considerations are necessary. H.281 Far end camera control communication are uni-directional. H.224 is bi-directional and can be used to learn the capabilities of the remote video end point e.g how many cameras it has. The offer answer exchange will be dependent on the functionality of both side. The offerer will offer a sendonly channel if its camera can not be remotely controlled and if the offerer does not intend to use H.224 to learn the capabilities of the remote video endpoints. In all other cases, when the offerer camera can be remotely controlled and/or it intends to use H.224 capabilities negotiation, the offerer will offer a sendrecv channel. The answerer behavior will be as follows: If it receives an offer with sendonly it will answer with a recvonly if it supports far end camera control, otherwise it will ignore reject the offer. If it receives an offer with sendrecv and its camera can be remotely controlled it will answer with a sendrecv option. If its camera cannot be remotely control it will reject the offer but may later try to remotely control the offerer's camera using this procedure. Even Expires March 2, 2005 [Page 7] Internet-Draft FECC September 2004 6. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550]. This implies that confidentiality of the media streams is achieved by encryption. A potential denial-of-service threat exists. The attacker can inject pathological datagrams into the stream which may cause the receiver to move the camera randomly. The usage of authentication of at least the RTP packet is RECOMMENDED As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. 7 Normative References [ITU.281] International Telecommunications Union, "A far end camera control protocol for videoconferences using H.224", ITU-T Recommendation H.281, November 1994. [ITU.H224] International Telecommunications Union, "A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels.", ITU-T Recommendation H.224, February 2000. [ITU.H323] International Telecommunications Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", ITU-T Recommendation H.323, July 2003. [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June Even Expires March 2, 2005 [Page 8] Internet-Draft FECC September 2004 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Author's Address Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel EMail: roni.even@polycom.co.il Even Expires March 2, 2005 [Page 9] Internet-Draft FECC September 2004 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 (2004). 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 2, 2005 [Page 10]