idnits 2.17.1 draft-ietf-avt-rtp-no-op-04.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 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498. 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 (May 21, 2007) is 6184 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) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-06 == Outdated reference: A later version (-07) exists of draft-ietf-avt-rtp-and-rtcp-mux-05 Summary: 3 errors (**), 0 flaws (~~), 3 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: November 22, 2007 Cisco Systems, Inc. 6 May 21, 2007 8 A No-Op Payload Format for RTP 9 draft-ietf-avt-rtp-no-op-04 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 November 22, 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 . . . . . . . . . . . . . . . . . . . . . . 5 56 3.4. Sender Operation . . . . . . . . . . . . . . . . . . . . . 5 57 3.5. Mixer, Translator Operation . . . . . . . . . . . . . . . 5 58 3.6. Receiver Operation . . . . . . . . . . . . . . . . . . . . 6 59 3.7. Indication of No-OP Capability using SDP . . . . . . . . . 6 60 4. Example SDP Offer/Answer . . . . . . . . . . . . . . . . . . . 6 61 5. Media Type Registration . . . . . . . . . . . . . . . . . . . 7 62 5.1. audio/no-op . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. video/no-op . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.3. text/no-op . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 9.2. Informational References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 Intellectual Property and Copyright Statements . . . . . . . . . . 12 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 Multiplexing RTP and RTCP over the same port 123 [I-D.ietf-avt-rtp-and-rtcp-mux] provides an separate keepalive 124 mechanism which uses the periodic RTCP transmission to keep 125 middleboxes aware of the flow. 127 2. Conventions Used in this Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. RTP Payload Format for No-Op 135 3.1. Registration 137 The RTP payload format is designated as "no-op" and the media types 138 are "audio/no-op", "video/no-op", and "text/no-op". The default 139 clock rate is 8000 Hz, but other rates MAY be used. In accordance 140 with current practice, this payload format does not have a static 141 payload type number, but uses a RTP payload type number established 142 dynamically out-of-band, e.g., through SDP [RFC4566]. 144 3.2. Use of RTP Header Fields 146 Timestamp: The RTP timestamp reflects the measurement point for the 147 current packet. The receiver uses this timestamp to calculate 148 jitter for RTCP sender and receiver reports per normal RTP 149 procedures. Note: The jitter value should primarily be used as a 150 means for comparing the reception quality between two users or two 151 time-periods, not as an absolute measure. 153 Marker bit: The RTP marker bit has no special significance for this 154 payload type. 156 3.3. Payload Format 158 The payload format is shown below. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | padding (OPTIONAL) | 166 | .... | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: Payload Format 171 The payload contains at least 4 bytes, the first 32 bits are reserved 172 for future use. These bits SHOULD be set to 0. Receivers MUST 173 ignore the value of these bits. 175 Additional padding bytes MAY be appended up to the ptime or maxptime 176 value in SDP (see Section 3.7). These bytes MUST be ignored. 177 Padding may be useful to generate RTP packets that are the same size 178 as a normal media payload. 180 3.4. Sender Operation 182 As discussed in the introduction, endpoints must occasionally send a 183 packet to their RTP and RTCP peer to keep NAT and firewall bindings 184 active, even if the media stream is marked 'recvonly' or 'inactive'. 185 No matter if the media stream is marked 'recvonly', 'sendrecv', 186 'sendonly', or 'inactive', if approximately 20 seconds elapse with no 187 packets transmitted from the RTP port (either RTP packets or non-RTP 188 packets (e.g., STUN [I-D.ietf-behave-rfc3489bis] packets), then an 189 RTP No-Op packet SHOULD be sent. 191 3.5. Mixer, Translator Operation 193 An RTP mixer or unicast-to-unicast RTP translator SHOULD forward RTP 194 No-Op payload packets normally; if the input stream is made up of RTP 195 No-Op packets only, a corresponding RTP No-Op packet SHOULD be 196 generated. If the input stream consists of other packets than No-Op, 197 then the No-Op packets SHOULD simply be discarded. A unicast-to- 198 multicast RTP translator SHOULD replicate RTP No-Op payload packets 199 normally. 201 3.6. Receiver Operation 203 Upon receipt of an RTP packet with the No-Op payload format the 204 receiver performs normal RTP receive operations on it -- incrementing 205 the RTP receive counter, calculating jitter, and so on. The receiver 206 then discards the packet -- it is not used to play out media. 208 3.7. Indication of No-OP Capability using SDP 210 Senders and receivers may indicate support for the No-Op payload 211 format, for example, by using the Session Description Protocol 212 [RFC4566]. 214 The default packetization interval for this payload type is 20ms but 215 alternate values can be advertised in SDP using the ptime or maxptime 216 attributes [RFC4566]. 218 4. Example SDP Offer/Answer 220 Offer: 222 v=0 223 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 224 s=- 225 c=IN IP4 host.atlanta.example.com 226 t=0 0 227 m=audio 49170 RTP/AVP 0 96 228 a=rtpmap:0 PCMU/8000 229 a=rtpmap:96 no-op/8000 230 m=video 41372 RTP/AVP 31 96 231 a=rtpmap:31 H261/90000 232 a=rtpmap:96 no-op/90000 234 Answer: 236 v=0 237 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 238 s=- 239 c=IN IP4 host.biloxi.example.com 240 t=0 0 241 m=audio 59174 RTP/AVP 0 96 242 a=rtpmap:0 PCMU/8000 243 a=rtpmap:96 no-op/8000 244 m=video 59170 RTP/AVP 32 96 245 a=rtpmap:31 H261/90000 246 a=rtpmap:96 no-op/90000 248 5. Media Type Registration 250 This section registers media types for audio/no-op, video/no-op, and 251 text/no-op, per [RFC4855]. 253 5.1. audio/no-op 255 Media type name: audio 257 Subtype name: no-op 259 Required parameters: none 261 Optional parameters: none 263 Encoding considerations: This media type is framed and binary; see 264 Section 4.8 in [RFC4288]. 266 Security considerations: See Section 6, "Security Considerations", in 267 this document. 269 Interoperability considerations: none 271 Published specification: This document. 273 Applications which use this media: The "no-op" application subtype is 274 used to maintain network state or verify network connectivity, when a 275 more traditional RTP payload type cannot be used. 277 Additional information: none. 279 Person and email address to contact for further information: Dan Wing 280 . 282 Intended usage: COMMON 284 Restrictions on usage: This media type depends on RTP framing and is 285 only defined for transfer via RTP [RFC3550]. Transfer within other 286 framing protocols is not defined at this time. 288 Author: Flemming Andreasen, David Oran, and Dan Wing 290 Change controller: IETF Audio/Video Transport working group delegated 291 from the IESG. 293 5.2. video/no-op 295 Media type name: video 297 Subtype name: no-op 299 Required parameters: none 301 Optional parameters: none 303 Encoding considerations: This media type is framed and binary; see 304 Section 4.8 in [RFC4288]. 306 Security considerations: See Section 6, "Security Considerations", in 307 this document. 309 Interoperability considerations: none 311 Published specification: This document. 313 Applications which use this media: The "no-op" application subtype is 314 used to maintain network state or verify network connectivity, when a 315 more traditional RTP payload type cannot be used. 317 Additional information: none. 319 Person and email address to contact for further information: Dan Wing 320 . 322 Intended usage: COMMON 324 Restrictions on usage: This media type depends on RTP framing and is 325 only defined for transfer via RTP [RFC3550]. Transfer within other 326 framing protocols is not defined at this time. 328 Author: Flemming Andreasen, David Oran, and Dan Wing 330 Change controller: IETF Audio/Video Transport working group delegated 331 from the IESG. 333 5.3. text/no-op 335 Media type name: audio 337 Subtype name: no-op 339 Required parameters: none 340 Optional parameters: none 342 Encoding considerations: This media type is framed; see Section 4.8 343 in [RFC4288]. 345 Security considerations: See Section 6, "Security Considerations", in 346 this document. 348 Interoperability considerations: none 350 Published specification: This document. 352 Applications which use this media: The "no-op" application subtype is 353 used to maintain network state or verify network connectivity, when a 354 more traditional RTP payload type cannot be used. 356 Additional information: none. 358 Person and email address to contact for further information: Dan Wing 359 . 361 Intended usage: COMMON 363 Restrictions on usage: This media type depends on RTP framing and is 364 only defined for transfer via RTP [RFC3550]. Transfer within other 365 framing protocols is not defined at this time. 367 Author: Flemming Andreasen, David Oran, and Dan Wing 369 Change controller: IETF Audio/Video Transport working group delegated 370 from the IESG. 372 6. Security Considerations 374 There are no additional security considerations for this new RTP 375 payload format; the RTP security considerations from RTP [RFC3550] 376 apply. 378 7. IANA Considerations 380 IANA is requested to make media type registrations as specified above 381 in Section 5 383 8. Acknowledgments 385 The authors thank Bob Biskner and Rajesh Kumar for their 386 contributions to this specification. 388 9. References 390 9.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 396 Jacobson, "RTP: A Transport Protocol for Real-Time 397 Applications", STD 64, RFC 3550, July 2003. 399 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 400 Description Protocol", RFC 4566, July 2006. 402 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 403 Formats", RFC 4855, February 2007. 405 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 406 Registration Procedures", BCP 13, RFC 4288, December 2005. 408 9.2. Informational References 410 [I-D.ietf-behave-rfc3489bis] 411 Rosenberg, J., "Session Traversal Utilities for (NAT) 412 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 413 progress), March 2007. 415 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 416 Comfort Noise (CN)", RFC 3389, September 2002. 418 [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s 419 Transparent Call", RFC 4040, April 2005. 421 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 422 Conversation", RFC 4103, June 2005. 424 [I-D.ietf-avt-rtp-and-rtcp-mux] 425 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 426 Control Packets on a Single Port", 427 draft-ietf-avt-rtp-and-rtcp-mux-05 (work in progress), 428 May 2007. 430 [G729B] International Telecommunications Union, "G.729 Annex B", 431 November 1999, 432 . 434 Authors' Addresses 436 Flemming Andreasen 437 Cisco Systems, Inc. 438 499 Thornall Street, 8th Floor 439 Edison, NJ 08837 440 USA 442 Email: fandreas@cisco.com 444 David Oran 445 Cisco Systems, Inc. 446 7 Ladyslipper Lane 447 Acton, MA 01720 448 USA 450 Email: oran@cisco.com 452 Dan Wing 453 Cisco Systems, Inc. 454 170 West Tasman Drive 455 San Jose, CA 95134 456 USA 458 Email: dwing@cisco.com 460 Full Copyright Statement 462 Copyright (C) The IETF Trust (2007). 464 This document is subject to the rights, licenses and restrictions 465 contained in BCP 78, and except as set forth therein, the authors 466 retain all their rights. 468 This document and the information contained herein are provided on an 469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 471 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 472 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 473 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 476 Intellectual Property 478 The IETF takes no position regarding the validity or scope of any 479 Intellectual Property Rights or other rights that might be claimed to 480 pertain to the implementation or use of the technology described in 481 this document or the extent to which any license under such rights 482 might or might not be available; nor does it represent that it has 483 made any independent effort to identify any such rights. Information 484 on the procedures with respect to rights in RFC documents can be 485 found in BCP 78 and BCP 79. 487 Copies of IPR disclosures made to the IETF Secretariat and any 488 assurances of licenses to be made available, or the result of an 489 attempt made to obtain a general license or permission for the use of 490 such proprietary rights by implementers or users of this 491 specification can be obtained from the IETF on-line IPR repository at 492 http://www.ietf.org/ipr. 494 The IETF invites any interested party to bring to its attention any 495 copyrights, patents or patent applications, or other proprietary 496 rights that may cover technology that may be required to implement 497 this standard. Please address the information to the IETF at 498 ietf-ipr@ietf.org. 500 Acknowledgment 502 Funding for the RFC Editor function is provided by the IETF 503 Administrative Support Activity (IASA).