idnits 2.17.1 draft-ietf-avt-rtp-no-op-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 23, 2007) is 6272 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT F. Andreasen 3 Internet-Draft D. Oran 4 Intended status: Standards Track D. Wing 5 Expires: August 27, 2007 Cisco Systems, Inc. 6 February 23, 2007 8 A No-Op Payload Format for RTP 9 draft-ietf-avt-rtp-no-op-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 27, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines an no-op payload format for the Real-time 43 Transport Protocol (RTP). This packet is not played out by 44 receivers. It can be useful as a way to keep Network Address 45 Translator (NAT) bindings and Firewall pinholes open. Other uses are 46 discussed in the document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 52 3. RTP Payload Format for No-Op . . . . . . . . . . . . . . . . . 4 53 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Use of RTP Header Fields . . . . . . . . . . . . . . . . . 4 55 3.3. Payload Format . . . . . . . . . . . . . . . . . . . . . . 4 56 3.4. Sender Operation . . . . . . . . . . . . . . . . . . . . . 5 57 3.5. Mixer, Translator Operation . . . . . . . . . . . . . . . 5 58 3.6. Receiver Operation . . . . . . . . . . . . . . . . . . . . 5 59 3.7. Indication of No-OP Capability using SDP . . . . . . . . . 5 60 4. Example SDP Offer/Answer . . . . . . . . . . . . . . . . . . . 6 61 5. MIME Registration . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. audio/no-op . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. video/no-op . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3. text/no-op . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 9.2. Informational References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 Intellectual Property and Copyright Statements . . . . . . . . . . 11 74 1. Introduction 76 This memo defines a new RTP payload format called "no-op". This 77 payload behaves like a normal RTP payload, except the RTP packet is 78 not used to play out media. 80 This new payload format is useful for: 82 o facilitating media session reception quality assessment, such as 83 at the beginning of a session; 85 o keepalives to keep NAT bindings and/or firewall pinholes open when 86 RTP media traffic is not otherwise being transmitted. 88 o measurement-based admission control by probing available 89 bandwidth, and 91 o synthetic load generation for performance testing and other 92 minimally-intrusive instrumentation. 94 When an endpoint has a media stream marked as 'recvonly' or 95 'inactive' the endpoint is not supposed to send any media (i.e., RTP 96 packets). However, to keep a NAT binding alive, the endpoint will 97 need to periodically send packets over the RTP and RTCP ports. RTP 98 No-Op is ideally suited to this. In comparison, if one participant 99 in an audio multicast conference has a 'recvonly' or 'inactive' media 100 stream yet occasionally sends comfort noise packets in order to keep 101 its NAT binding open, these comfort noise packets are interpreted as 102 audio packets by receivers and mixers which can cause undesirable 103 behavior -- such as selection of the primary speaker or the playout 104 of comfort noise when no audio should be played. 106 Unlike Comfort noise [RFC3389], which is specific to voice RTP 107 streams, RTP No-Op is applicable to any kind of RTP stream including 108 video, audio, realtime text, or any other media types that would 109 benefit from the capabilities listed above. This gives RTP No-Op an 110 advantage as a NAT keepalive mechanism. Certain functions and RTP 111 payload types can use RTP No-Op without re-inventing their own 112 payload-specific NAT keepalive mechanism -- such as video muting, 113 Clearmode [RFC4040], and text [RFC4103]. 115 Some audio codecs have their own 'silence' packets. However, some 116 codecs only send such silence packets if the noise floor changes; 117 G.729b [G729B] is an example of such a codec. RTP No-Op allows the 118 RTP stack itself, rather than the codec, to send periodic packets as 119 a keepalive mechanism. 121 2. Conventions Used in this Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. RTP Payload Format for No-Op 129 3.1. Registration 131 The RTP payload format is designated as "no-op" and the MIME types 132 are "audio/no-op", "video/no-op", and "text/no-op". The default 133 clock rate is 8000 Hz, but other rates MAY be used. In accordance 134 with current practice, this payload format does not have a static 135 payload type number, but uses a RTP payload type number established 136 dynamically out-of-band, e.g. through SDP [RFC4566]. 138 3.2. Use of RTP Header Fields 140 Timestamp: The RTP timestamp reflects the measurement point for the 141 current packet. The receiver uses this timestamp to calculate 142 jitter for RTCP sender and receiver reports per normal RTP 143 procedures. Note: The jitter value should primarily be used as a 144 means for comparing the reception quality between two users or two 145 time-periods, not as an absolute measure. 147 Marker bit: The RTP marker bit has no special significance for this 148 payload type. 150 3.3. Payload Format 152 The payload format is shown below. 154 0 1 2 3 155 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | reserved | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | padding (OPTIONAL) | 160 | .... | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1: Payload Format 165 The payload contains at least 4 bytes, the first 32 bits are reserved 166 for future use. These bits SHOULD be set to 0. Receivers MUST 167 ignore the value of these bits. 169 Additional padding bytes MAY be appended up to the ptime or maxptime 170 value in SDP (see Section 3.7). These bytes MUST be ignored. 171 Padding may be useful to generate RTP packets that are the same size 172 as a normal media payload. 174 3.4. Sender Operation 176 As discussed in the introduction, endpoints must occasionally send a 177 packet to their RTP and RTCP peer to keep NAT and firewall bindings 178 active, even if the media stream is marked 'recvonly' or 'inactive'. 179 No matter if the media stream is marked 'recvonly', 'sendrecv', 180 'sendonly', or 'inactive', if approximately 20 seconds elapse with no 181 packets transmitted from the RTP port (either RTP packets or non-RTP 182 packets (e.g., STUN [I-D.ietf-behave-rfc3489bis] packets), then an 183 RTP No-Op packet SHOULD be sent. 185 3.5. Mixer, Translator Operation 187 An RTP mixer or unicast-to-unicast RTP translator SHOULD forward RTP 188 No-Op payload packets normally; if the input stream is made up of RTP 189 No-Op packets only, a corresponding RTP No-Op packet SHOULD be 190 generated. If the input stream consists of other packets than No-Op, 191 then the No-Op packets SHOULD simply be discarded. A unicast-to- 192 multicast RTP translator SHOULD replicate RTP No-Op payload packets 193 normally. 195 3.6. Receiver Operation 197 Upon receipt of an RTP packet with the No-Op payload format the 198 receiver performs normal RTP receive operations on it -- incrementing 199 the RTP receive counter, calculating jitter, and so on. The receiver 200 then discards the packet -- it is not used to play out media. 202 3.7. Indication of No-OP Capability using SDP 204 Senders and receivers may indicate support for the No-Op payload 205 format, for example, by using the Session Description Protocol 206 [RFC4566]. 208 The default packetization interval for this payload type is 20ms but 209 alternate values can be advertised in SDP using the ptime or maxptime 210 attributes [RFC4566]. 212 4. Example SDP Offer/Answer 214 Offer: 216 v=0 217 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 218 s=- 219 c=IN IP4 host.atlanta.example.com 220 t=0 0 221 m=audio 49170 RTP/AVP 0 96 222 a=rtpmap:0 PCMU/8000 223 a=rtpmap:96 no-op/8000 224 m=video 41372 RTP/AVP 31 96 225 a=rtpmap:31 H261/90000 226 a=rtpmap:96 no-op/90000 228 Answer: 230 v=0 231 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 232 s=- 233 c=IN IP4 host.biloxi.example.com 234 t=0 0 235 m=audio 59174 RTP/AVP 0 96 236 a=rtpmap:0 PCMU/8000 237 a=rtpmap:96 no-op/8000 238 m=video 59170 RTP/AVP 32 96 239 a=rtpmap:31 H261/90000 240 a=rtpmap:96 no-op/90000 242 5. MIME Registration 244 This section registers MIME types for audio/no-op, video/no-op, and 245 text/no-op. 247 5.1. audio/no-op 249 MIME media type name: audio 251 MIME subtype name: no-op 253 Required parameters: none 255 Optional parameters: none 257 Encoding considerations: none 258 Security considerations: See Section 6, "Security Considerations", in 259 this document. 261 Interoperability considerations: none 263 Published specification: This document. 265 Applications which use this media: The "no-op" application subtype is 266 used to maintain network state or verify network connectivity, when a 267 more traditional RTP payload type cannot be used. 269 Additional information: 271 1. Magic number(s): N/A 273 2. File extension(s): N/A 275 3. Macintosh file type code: N/A 277 5.2. video/no-op 279 MIME media type name: video 281 MIME subtype name: no-op 283 Required parameters: none 285 Optional parameters: none 287 Encoding considerations: none 289 Security considerations: See Section 6, "Security Considerations", in 290 this document. 292 Interoperability considerations: none 294 Published specification: This document. 296 Applications which use this media: The "no-op" application subtype is 297 used to maintain network state or verify network connectivity, when a 298 more traditional RTP payload type cannot be used. 300 Additional information: 302 1. Magic number(s): N/A 304 2. File extension(s): N/A 305 3. Macintosh file type code: N/A 307 5.3. text/no-op 309 MIME media type name: text 311 MIME subtype name: no-op 313 Required parameters: none 315 Optional parameters: none 317 Encoding considerations: none 319 Security considerations: See Section 6, "Security Considerations", in 320 this document. 322 Interoperability considerations: none 324 Published specification: This document. 326 Applications which use this media: The "no-op" application subtype is 327 used to maintain network state or verify network connectivity, when a 328 more traditional RTP payload type cannot be used. 330 Additional information: 332 1. Magic number(s): N/A 334 2. File extension(s): N/A 336 3. Macintosh file type code: N/A 338 6. Security Considerations 340 There are no additional security considerations for this new RTP 341 payload format; the RTP security considerations from RTP [RFC3550] 342 apply. 344 7. IANA Considerations 346 IANA is requested to make MIME type registrations as specified above 347 in Section 5 349 8. Acknowledgments 350 9. References 352 9.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 358 Jacobson, "RTP: A Transport Protocol for Real-Time 359 Applications", STD 64, RFC 3550, July 2003. 361 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 362 Description Protocol", RFC 4566, July 2006. 364 9.2. Informational References 366 [I-D.ietf-behave-rfc3489bis] 367 Rosenberg, J., "Simple Traversal Underneath Network 368 Address Translators (NAT) (STUN)", 369 draft-ietf-behave-rfc3489bis-05 (work in progress), 370 October 2006. 372 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 373 Comfort Noise (CN)", RFC 3389, September 2002. 375 [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s 376 Transparent Call", RFC 4040, April 2005. 378 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 379 Conversation", RFC 4103, June 2005. 381 [G729B] International Telecommunications Union, "G.729 Annex B", 382 November 1999, 383 . 385 Authors' Addresses 387 Flemming Andreasen 388 Cisco Systems, Inc. 389 499 Thornall Street, 8th Floor 390 Edison, NJ 08837 391 USA 393 Email: fandreas@cisco.com 394 David Oran 395 Cisco Systems, Inc. 396 7 Ladyslipper Lane 397 Acton, MA 01720 398 USA 400 Email: oran@cisco.com 402 Dan Wing 403 Cisco Systems, Inc. 404 170 West Tasman Drive 405 San Jose, CA 95134 406 USA 408 Email: dwing@cisco.com 410 Full Copyright Statement 412 Copyright (C) The IETF Trust (2007). 414 This document is subject to the rights, licenses and restrictions 415 contained in BCP 78, and except as set forth therein, the authors 416 retain all their rights. 418 This document and the information contained herein are provided on an 419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 421 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 422 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 423 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 426 Intellectual Property 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; nor does it represent that it has 433 made any independent effort to identify any such rights. Information 434 on the procedures with respect to rights in RFC documents can be 435 found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org. 450 Acknowledgment 452 Funding for the RFC Editor function is provided by the IETF 453 Administrative Support Activity (IASA).