AVT R. Even
Internet-Draft Polycom
Expires: October 29, 2005 April 27, 2005
MIME type registration for RTP Payload format for H.224
draft-ietf-avt-mime-h224-01.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 October 29, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In conversional 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 SDP
parameters needed to support far end camera control protocol using
H.281.
Even Expires October 29, 2005 [Page 1]
Internet-Draft FECC April 2005
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 October 29, 2005 [Page 2]
Internet-Draft FECC April 2005
1. Introduction
The ITU-T recommendation H.281 [ITU.281] specifies a protocol for far
end camera control (FECC). This protocol is carried in H.320 systems
using H.224 [ITU.H224]. For H.323 systems, H.323 annex Q specifies
how to carry H.224 frames using RTP packets.
The document registers the H224 media type that can be used by
systems that uses SDP[RFC2327].
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 [ITU.H323]and SDP based systems to
use far end camera control, end to end, without having any protocol
translation in the middle.
The document defines H224 media type since the RTP packets in H.323
annex Q, carry H.224 frames. The FECC proocol is internal to H.224
frame and is identified by the client ID field of the H.224 packet.
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 October 29, 2005 [Page 3]
Internet-Draft FECC April 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 October 29, 2005 [Page 4]
Internet-Draft FECC April 2005
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 October 29, 2005 [Page 5]
Internet-Draft FECC April 2005
4. IANA Considerations
This section describes the media types and names associated with this
payload format. The section registers the media 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 sending simple 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:
Roni Even
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
Even Expires October 29, 2005 [Page 6]
Internet-Draft FECC April 2005
5. SDP Parameters
The media 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 is dependent on the functionality of both side.
The offerer offers 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 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 / reject the
offer.
If it receives an offer with sendrecv and its camera can be remotely
controlled it answers with a sendrecv option. If its camera cannot
be remotely control it rejects the offer but may later try to
remotely control the offerer's camera using this procedure.
Even Expires October 29, 2005 [Page 7]
Internet-Draft FECC April 2005
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,
Even Expires October 29, 2005 [Page 8]
Internet-Draft FECC April 2005
June 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 October 29, 2005 [Page 9]
Internet-Draft FECC April 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 October 29, 2005 [Page 10]
