4573
PROPOSED STANDARD
MIME Type Registration for RTP Payload Format for H.224
Authors: R. Even, A. Lochbaum
Date: July 2006
Area: rai
Working Group: avt
Stream: IETF
Abstract
In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. [STANDARDS-TRACK]
RFC 4573
PROPOSED STANDARD
Network Working Group R. Even
Request for Comments: 4573 A. Lochbaum
Category: Standard Track Polycom
July 2006
<span class="h1">MIME Type Registration for RTP Payload Format for H.224</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In conversational video applications, far-end camera control protocol
is used by participants to control the remote camera. The protocol
that is commonly used is ITU H.281 over H.224. The document
registers the H224 media type. It defines the syntax and the
semantics of the Session Description Protocol (SDP) parameters needed
to support far-end camera control protocol using H.224.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Far-End Camera Control Protocol .................................<a href="#page-2">2</a>
<a href="#section-4">4</a>. IANA Considerations .............................................<a href="#page-2">2</a>
<a href="#section-4.1">4.1</a>. Media Type Registration ....................................<a href="#page-2">2</a>
<a href="#section-5">5</a>. SDP Parameters ..................................................<a href="#page-4">4</a>
<a href="#section-5.1">5.1</a>. Usage with the SDP Offer Answer Model ......................<a href="#page-4">4</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-5">5</a>
<a href="#section-7">7</a>. References ......................................................<a href="#page-5">5</a>
<a href="#section-7.1">7.1</a>. Normative References .......................................<a href="#page-5">5</a>
<a href="#section-7.2">7.2</a>. Informative References .....................................<a href="#page-6">6</a>
<span class="grey">Even & Lochbaum Standard Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4573">RFC 4573</a> FECC July 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The document registers the H224 media type, which may be used by
systems that use SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>].
This media type is used for supporting the simple far-end camera
control protocol on SDP-based systems. The media type helps
signaling gateways between H.323 [<a href="#ref-ITU.H323" title=""Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service"">ITU.H323</a>] and SDP-based systems to
use far-end camera control, end to end, without any protocol
translation in the middle.
The document defines the H224 media type since the RTP packets in
H.323 annex Q [<a href="#ref-ITU.H323" title=""Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service"">ITU.H323</a>] carry H.224 frames [<a href="#ref-ITU.H224" title=""A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels."">ITU.H224</a>]. The far-end
camera control protocol (FECC) is internal to the H.224 frame and is
identified by the client ID field of the H.224 packet.
The document will define the SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] parameters needed to
support the above far-end camera control protocol in systems that use
SDP.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 <a href="./rfc2119">RFC2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] and
indicate requirement levels for compliant RTP implementations.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Far-End Camera Control Protocol</span>
This simple protocol is based on ITU-T H.281[ITU.281] frames carried
in ITU-T H.224 packets 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 for packet-switch networks is described in H.323,
annex Q.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Media Type Registration</span>
This section describes the media types and names associated with this
payload format. The registration uses the templates defined in <a href="./rfc4288">RFC</a>
<a href="./rfc4288">4288</a> [<a href="./rfc4288" title=""Media Type Specifications and Registration Procedures"">RFC4288</a>]. It follows <a href="./rfc3555">RFC 3555</a> [<a href="./rfc3555" title=""MIME Type Registration of RTP Payload Formats"">RFC3555</a>].
<span class="grey">Even & Lochbaum Standard Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4573">RFC 4573</a> FECC July 2006</span>
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Registration of MIME Media Type application/h224</span>
MIME media type name: application
MIME subtype name: H224
Required parameters: None
Optional parameters: None
Encoding considerations:
This media type is framed (see H.323, Annex Q [<a href="#ref-ITU.H323" title=""Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service"">ITU.H323</a>]) and
contains binary data; see <a href="./rfc4288#section-4.8">Section 4.8 of [RFC4288]</a>
Security considerations: See <a href="./rfc4573#section-6">Section 6 of RFC 4573</a>.
Interoperability considerations:
Terminals sending simple far-end camera control commands should
use this MIME type. Receivers who cannot support the protocol
will reject the channel.
Published specification: <a href="./rfc4573">RFC 4573</a>
Applications that use this media type:
Video conferencing applications.
Additional information: None
Person and email address to contact for further information:
Roni Even: [email protected]
Intended usage: COMMON
Restrictions on usage:
This media type depends on RTP framing and thus is only defined
for transfer via RTP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. Transport within other framing
protocols is not defined at this time.
Author: Roni Even
Change controller:
IETF Audio/Video Transport working group, delegated from the IESG.
<span class="grey">Even & Lochbaum Standard Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4573">RFC 4573</a> FECC July 2006</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. SDP Parameters</span>
The 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 SHALL be any applicable RTP profile (for example <a href="./rfc3551">RFC</a>
<a href="./rfc3551">3551</a> [<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</a>]), 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 default clock rate in the "a=rtpmap" line MUST be 4800.
The recommended maximum bandwidth for this protocol is 6.4 kbit/sec.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Usage with the SDP Offer Answer Model</span>
When offering FECC using SDP in an Offer/Answer model [<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>], the
following considerations are necessary.
Far-end camera control communication is 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 is dependent on the functionality of both sides.
The offerer offers a sendonly channel if its camera cannot 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's camera can be remotely
controlled and/or it intends to use H.224 capabilities negotiation,
the offerer offers a sendrecv channel.
The answerer behavior is as follows:
If it receives an offer with sendonly, it answers with a recvonly if
it supports far-end camera control; otherwise, it ignores/rejects the
offer.
If it receives an offer with sendrecv and its camera can be remotely
controlled, or it intends to use H.224 capabilities negotiation, it
answers with a sendrecv option. If its camera cannot be remotely
controlled, it can answer with a sendonly attribute. The answerer
may also reject the offer if he does not support FECC or does not
intend to use FECC at the moment.
<span class="grey">Even & Lochbaum Standard Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4573">RFC 4573</a> FECC July 2006</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
H.224 payload format, defined in H.323, annex Q defines packet
structure based on RTP using the RTP header structure from <a href="./rfc3550">RFC 3550</a>.
Those packets are subject to the security considerations discussed in
the RTP specification [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. This implies that confidentiality
of the media streams is achieved by encryption. Secure Realtime
Transport Protocol (SRTP) [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>] may be used to provide both
encryption and integrity protection of RTP flow.
A potential denial-of-service threat exists for data that causes
application behavior like camera movement. The attacker can inject
pathological datagrams into the stream that cause the receiver to
change the camera position. Therefore, the usage of data origin
authentication and data integrity protection of at least the H.323
annex Q packet is RECOMMENDED; for example, with SRTP.
Note that the appropriate mechanism to ensure confidentiality and
integrity of H.323 annex Q packets and their payloads is very
dependent on the application and on the transport and signaling
protocols employed. Thus, although SRTP is given as an example
above, other possible choices exist.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-ITU.281">ITU.281</a>] International Telecommunications Union, "A far end camera
control protocol for videoconferences using H.224", ITU- T
Recommendation H.281, November 1994.
[<a id="ref-ITU.H224">ITU.H224</a>] 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.
[<a id="ref-ITU.H323">ITU.H323</a>] 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.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3264">RFC3264</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", <a href="./rfc3264">RFC 3264</a>, June
2002.
<span class="grey">Even & Lochbaum Standard Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4573">RFC 4573</a> FECC July 2006</span>
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-RFC4566">RFC4566</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC3551">RFC3551</a>] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, <a href="./rfc3551">RFC 3551</a>,
July 2003.
[<a id="ref-RFC3555">RFC3555</a>] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", <a href="./rfc3555">RFC 3555</a>, July 2003.
[<a id="ref-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, March 2004.
[<a id="ref-RFC4288">RFC4288</a>] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", <a href="https://www.rfc-editor.org/bcp/bcp13">BCP 13</a>, <a href="./rfc4288">RFC 4288</a>, December 2005.
Authors' Addresses
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva 49130
Israel
EMail: [email protected]
Andrew Lochbaum
Polycom
6500 River Place Blvd, Building 6
Austin, TX 78730
USA
EMail: [email protected]
<span class="grey">Even & Lochbaum Standard Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4573">RFC 4573</a> FECC July 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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
[email protected].
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Even & Lochbaum Standard Track [Page 7]
Annotations
Select text to annotate