idnits 2.17.1 draft-ietf-avt-mime-h224-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 321. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 30, 2006) is 6659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-25 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.281' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.H224' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.H323' -- Obsolete informational reference (is this intentional?): RFC 3555 (Obsoleted by RFC 4855, RFC 4856) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT R. Even 3 Internet-Draft A. Lochbaum 4 Expires: August 3, 2006 Polycom 5 January 30, 2006 7 MIME type registration for RTP Payload format for H.224 8 draft-ietf-avt-mime-h224-05.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 3, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 In conversional video applications far end camera control protocol is 42 used by participants to control the remote camera. The protocol that 43 is commonly used is ITU H.281 over H.224. The document registers the 44 H224 media type. It defines the syntax and the semantics of the SDP 45 parameters needed to support far end camera control protocol using 46 H.224. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Far-end camera control protocol . . . . . . . . . . . . . . . 5 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. Media Type Registration . . . . . . . . . . . . . . . . . 6 55 4.1.1. Registration of MIME media type application/h224 . . . 6 56 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.1. Usage with the SDP Offer Answer Model . . . . . . . . . . 8 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 63 Intellectual Property and Copyright Statements . . . . . . . . . . 13 65 1. Introduction 67 The document registers the H224 media type that may be used by 68 systems that uses SDP [I-D.ietf-mmusic-sdp-new]. 70 This media type is used for supporting the simple far end camera 71 control protocol on SDP based systems. The media type helps 72 signaling gateways between H.323 [ITU.H323] and SDP based systems to 73 use far end camera control, end to end, without having any protocol 74 translation in the middle. 76 The document defines H224 media type since the RTP packets in H.323 77 annex Q [ITU.H323] carry H.224 frames[ITU.H224]. The far end camera 78 control protocol (FECC) is internal to H.224 frame and is identified 79 by the client ID field of the H.224 packet. 81 The document will define the SDP [I-D.ietf-mmusic-sdp-new] parameters 82 needed to support the above far end camera control protocol in 83 systems that use SDP. 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC2119 [RFC2119] and 90 indicate requirement levels for compliant RTP implementations. 92 3. Far-end camera control protocol 94 This simple protocol is based on ITU-T H.281[ITU.281] frames carried 95 in ITU-T H.224 packets in an RTP/UDP channel. H.323 annex Q 96 specifies how to build the RTP packets from the H.224 packets. 98 Using far end camera control protocol in point to point calls and 99 multipoint calls for packet switch networks is described in H.323 100 annex Q 102 4. IANA Considerations 104 4.1. Media Type Registration 106 This section describes the media types and names associated with this 107 payload format. The registration uses the templates defined in 108 RFC4288 [RFC4288]. It follows RFC3555 [RFC3555]. 110 4.1.1. Registration of MIME media type application/h224 112 MIME media type name: application 114 MIME subtype name: H224 116 Required parameters: None 118 Optional parameters: None 120 Encoding considerations: 122 This media type is framed (see H.323 Annex Q [ITU.H323]) and 123 contains binary data, see section 4.8 in [RFC4288] 125 Security considerations: See Section 6 of RFCxxxx 127 Interoperability considerations: 129 Terminals sending simple far end camera control command should use 130 this MIME type, receivers who can not support the protocol will 131 reject the channel. 133 Published specification: RFC xxxx 135 Applications which use this media type: 137 Video conferencing applications. 139 Additional information: none 141 Person and email address to contact for further information : 143 Roni Even: roni.even@polycom.co.il 145 Intended usage: COMMON 147 Restrictions on usage: 149 This media type depends on RTP framing, and hence is only defined 150 for transfer via RTP [RFC3550]. Transport within other framing 151 protocols is not defined at this time. 153 Author: Roni Even 155 Change controller: 157 IETF Audio/Video Transport working group delegated from the IESG. 159 5. SDP Parameters 161 The media media type application/h224 string is mapped to fields in 162 the Session Description Protocol (SDP) as follows: 164 o The media name in the "m=" line of SDP MUST be application. The 165 transport SHALL be any applicable RTP profile (for example RFC 3551 166 [RFC3551]) and the payload type is dynamic. 168 o The encoding name in the "a=rtpmap" line of SDP MUST be h224 (the 169 MIME subtype). 171 o The default clock rate in the "a=rtpmap" line MUST be 4800. 173 The recommended maximum bandwidth for this protocol is 6.4 kbit/sec. 175 5.1. Usage with the SDP Offer Answer Model 177 When offering FECC using SDP in an Offer/Answer model [RFC3264] the 178 following considerations are necessary. 180 Far end camera control communication are uni-directional. H.224 is 181 bi-directional and can be used to learn the capabilities of the 182 remote video end point e.g how many cameras it has. The offer answer 183 exchange is dependent on the functionality of both side. 185 The offerer offers a sendonly channel if its camera can not be 186 remotely controlled and if the offerer does not intend to use H.224 187 to learn the capabilities of the remote video endpoints. 189 In all other cases, when the offerer's camera can be remotely 190 controlled and/or it intends to use H.224 capabilities negotiation, 191 the offerer offers a sendrecv channel. 193 The answerer behavior is as follows: 195 If it receives an offer with sendonly it answers with a recvonly if 196 it supports far end camera control, otherwise it ignores / reject the 197 offer. 199 If it receives an offer with sendrecv and its camera can be remotely 200 controlled or it intendes to use H.224 capabilities negotiation, it 201 answers with a sendrecv option. If its camera cannot be remotely 202 controlled it can answer with a sendonly attribute. The answerer may 203 also reject the offer if he does not support FECC or does not intend 204 to use FECC at the moment. 206 6. Security Considerations 208 H.224 payload format defined in H.323 annex Q defines packets 209 structure based on RTP using the RTP header structure from RFC3550. 210 Those packets are subject to the security considerations discussed in 211 the RTP specification [RFC3550]. This implies that confidentiality 212 of the media streams is achieved by encryption. SRTP [RFC3711] may 213 be used to provide both encryption and integrity protection of RTP 214 flow. 216 A potential denial-of-service threat exists for data that causes 217 application behavior like camera movement. The attacker can inject 218 pathological datagrams into the stream which cause the receiver to 219 change the camera position. Therefore, the usage of data origin 220 authentication and data integrity protection of at least the H.323 221 annex Q packet is RECOMMENDED; for example, with SRTP. 223 Note that the appropriate mechanism to ensure confidentiality and 224 integrity of H.323 annex Q packets and their payloads is very 225 dependent on the application and on the transport and signaling 226 protocols employed. Thus, although SRTP is given as an example 227 above, other possible choices exist. 229 7. References 231 7.1. Normative References 233 [I-D.ietf-mmusic-sdp-new] 234 Handley, M., "SDP: Session Description Protocol", 235 draft-ietf-mmusic-sdp-new-25 (work in progress), 236 July 2005. 238 [ITU.281] International Telecommunications Union, "A far end camera 239 control protocol for videoconferences using H.224", ITU- 240 T Recommendation H.281, November 1994. 242 [ITU.H224] 243 International Telecommunications Union, "A real time 244 control protocol for simplex applications using the H.221 245 LSD/HSD/HLP channels.", ITU-T Recommendation H.224, 246 February 2000. 248 [ITU.H323] 249 International Telecommunications Union, "Visual telephone 250 systems and equipment for local area networks which 251 provide a non-guaranteed quality of service", ITU- 252 T Recommendation H.323, July 2003. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 258 with Session Description Protocol (SDP)", RFC 3264, 259 June 2002. 261 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 262 Jacobson, "RTP: A Transport Protocol for Real-Time 263 Applications", STD 64, RFC 3550, July 2003. 265 7.2. Informative References 267 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 268 Video Conferences with Minimal Control", STD 65, RFC 3551, 269 July 2003. 271 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 272 Payload Formats", RFC 3555, July 2003. 274 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 275 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 276 RFC 3711, March 2004. 278 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 279 Registration Procedures", BCP 13, RFC 4288, December 2005. 281 Authors' Addresses 283 Roni Even 284 Polycom 285 94 Derech Em Hamoshavot 286 Petach Tikva 49130 287 Israel 289 Email: roni.even@polycom.co.il 291 Andrew Lochbaum 292 Polycom 293 6500 River Place Blvd, Building 6 294 Austin, TX 78730 295 USA 297 Email: alochbaum@polycom.com 299 Intellectual Property Statement 301 The IETF takes no position regarding the validity or scope of any 302 Intellectual Property Rights or other rights that might be claimed to 303 pertain to the implementation or use of the technology described in 304 this document or the extent to which any license under such rights 305 might or might not be available; nor does it represent that it has 306 made any independent effort to identify any such rights. Information 307 on the procedures with respect to rights in RFC documents can be 308 found in BCP 78 and BCP 79. 310 Copies of IPR disclosures made to the IETF Secretariat and any 311 assurances of licenses to be made available, or the result of an 312 attempt made to obtain a general license or permission for the use of 313 such proprietary rights by implementers or users of this 314 specification can be obtained from the IETF on-line IPR repository at 315 http://www.ietf.org/ipr. 317 The IETF invites any interested party to bring to its attention any 318 copyrights, patents or patent applications, or other proprietary 319 rights that may cover technology that may be required to implement 320 this standard. Please address the information to the IETF at 321 ietf-ipr@ietf.org. 323 Disclaimer of Validity 325 This document and the information contained herein are provided on an 326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 328 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 329 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 330 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 331 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 333 Copyright Statement 335 Copyright (C) The Internet Society (2006). This document is subject 336 to the rights, licenses and restrictions contained in BCP 78, and 337 except as set forth therein, the authors retain all their rights. 339 Acknowledgment 341 Funding for the RFC Editor function is currently provided by the 342 Internet Society.