idnits 2.17.1 draft-wing-avt-rtp-noop-02.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 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 475. ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 9, 2005) is 6926 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) == Unused Reference: '6' is defined on line 399, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566) -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-04 -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '7') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2793 (ref. '11') (Obsoleted by RFC 4103) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 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 Expires: November 10, 2005 D. Wing 5 Cisco Systems, Inc. 6 May 9, 2005 8 A No-op payload format for the Realtime Transport Protocol 9 draft-wing-avt-rtp-noop-02 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 10, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines an no-op payload format for the Real-time 43 Transport Protocol (RTP), and a mechanism to request an immediate 44 RTCP report. This can be used to verify RTP connectivity and to keep 45 Network Address Translator (NAT) bindings and Firewall pinholes open. 47 Requirements Language 48 The key words "MUST", "MUST NOT" "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [1]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. RTP Payload Format for No-Op . . . . . . . . . . . . . . . . . 3 56 2.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2 Use of RTP Header Fields . . . . . . . . . . . . . . . . . 4 58 2.3 Payload Format . . . . . . . . . . . . . . . . . . . . . . 4 59 2.4 Sender Operation . . . . . . . . . . . . . . . . . . . . . 4 60 2.5 Mixer, Translator Operation . . . . . . . . . . . . . . . 5 61 2.6 Receiver Operation . . . . . . . . . . . . . . . . . . . . 5 62 2.7 Indication of No-OP Capability using SDP . . . . . . . . . 6 63 3. Example SDP Offer/Answer . . . . . . . . . . . . . . . . . . . 6 64 4. MIME Registration . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1 audio/no-op . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2 video/no-op . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3 text/no-op . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1 Normative References . . . . . . . . . . . . . . . . . . . 9 73 8.2 Informational References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 75 Intellectual Property and Copyright Statements . . . . . . . . 11 77 1. Introduction 79 This memo defines a new RTP payload format called "no-op". This 80 payload behaves like a normal RTP payload, except that it isn't 81 played by the receiver. It is also explicitly designed to interact 82 constructively with the RTCP feedback profile [5]. 84 This new payload format is useful for: 86 o media session reception quality assessment, such as at the 87 beginning of a session; 88 o keepalives to keep NAT bindings and/or firewall pinholes open when 89 RTP media traffic is not otherwise being transmitted. 91 In addition it has a number of uses whose utility is speculative but 92 for which it is easy pressed into service: 94 o measurement-based admission control by probing available 95 bandwidth, and 96 o synthetic load generation for performance testing and other 97 minimally-intrusive instrumentation. 99 Unlike Comfort noise [9], which is specific to voice RTP streams, RTP 100 No-Op is applicable to any kind of RTP stream including video, audio, 101 realtime text, or any other media type that would benefit from the 102 capabilities listed above. This gives RTP No-Op an advantage as a 103 NAT keepalive mechanism. Certain functions and RTP payload types can 104 use RTP No-Op without re-inventing their own payload-specific NAT 105 keepalive mechanism -- such as video muting, Clearmode [10], and text 106 [11]. 108 Some audio codecs have their own 'silence' packets. However, some 109 codecs only send such 'silence' packets if the noise floor changes; 110 G.729b [12] is an example of such a codec. RTP No-Op allows the RTP 111 stack itself, rather than the codec, to send periodic packets as a 112 keepalive mechanism. 114 2. RTP Payload Format for No-Op 116 2.1 Registration 118 The RTP payload format is designated as "no-op" and the MIME types 119 are "audio/no-op", "video/no-op", and "text/no-op". The default 120 clock rate is 8000 Hz, but other rates MAY be used. In accordance 121 with current practice, this payload format does not have a static 122 payload type number, but uses a RTP payload type number established 123 dynamically out-of-band, e.g. through SDP [3]. 125 2.2 Use of RTP Header Fields 127 Timestamp: The RTP timestamp reflects the measurement point for the 128 current packet. The receiver calculates jitter for RTCP receiver 129 reports based on all packets with a given timestamp. Note: The 130 jitter value should primarily be used as a means for comparing the 131 reception quality between two users or two time-periods, not as an 132 absolute measure. 133 Marker bit: The RTP marker bit has no special significance for this 134 payload type. 136 2.3 Payload Format 138 The payload format is shown below. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |R| reserved | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | padding (OPTIONAL) | 146 | .... | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 The payload contains at least 4 bytes. The first 32 bits are defined 150 as follows: 152 bit 0: "R", "Request immediate RTCP", is used to request 153 invocation of RTCP feedback by timely transmission of an 154 RTCP report (see Section 2.6). 155 bits 1-31: Reserved; contents are ignored. 157 Additional padding bytes MAY be appended up to the negotiated ptime 158 value in SDP (see Section 2.7). These bytes are ignored. Padding 159 may be useful to generate RTP packets that are the same size as a 160 normal media payload. 162 2.4 Sender Operation 164 When an endpoint is in 'recvonly' or 'inactive' the endpoint isn't 165 allowed to send RTP data. However, to keep a NAT binding alive, the 166 endpoint will need to send packets over the RTP port. RTP No-Op is 167 ideally suited to this. In comparison, if one participant in an 168 audio multicast conference is in 'recvonly' or 'inactive', yet 169 occasionally sends RFC3389 comfort noise packets in order to keep its 170 NAT binding open, these comfort noise packets are interpreted as 171 audio packets by receivers and mixers which can cause undesirable 172 behavior -- such as selection of the primary speaker or the playout 173 of comfort noise when no audio should be played. To keep NAT and 174 firewall bindings active, endpoints MUST occasionally send a packet 175 to their RTP peer. The type of RTP packet depends on the negotiated 176 RTP payload: 178 o if both ends support RFC3389 and the negotiated RTP payload is 179 appropriate for RFC3389, an RFC3389 packet SHOULD be transmitted. 180 o if both ends support RTP No-Op and the negotiated RTP payload is 181 inappropriate for RFC3389, RTP No-Op SHOULD be transmitted. 183 2.5 Mixer, Translator Operation 185 An RTP mixer or unicast-to-unicast RTP translator SHOULD forward RTP 186 No-Op payload packets normally. A unicast-to-multicast RTP 187 translator SHOULD replicate RTP No-Op payload packets normally. 189 A multicast-to-unicast RTP translator SHOULD NOT replicate an RTP 190 No-Op packet with the Request Immediate RTCP bit set unless: 192 1. all receivers are known to be operating under the bandwidth 193 limitations rules of [5], and 194 2. the restriction of applicability to "small groups" in [5] is 195 observed 196 Otherwise the sender may be flooded with RTCP reports. 198 2.6 Receiver Operation 200 Upon receipt of an RTP packet with the No-Op payload format and the 201 "Send Immediate RTCP Report" bit set to 0, the receiver performs 202 normal RTP receive operations on it -- incrementing the RTP receive 203 counter, calculating jitter, and so on. The receiver then discards 204 the packet -- it is not used to play out data. 206 Upon receipt of an RTP packet with the No-Op payload format and the 207 "Se""nd Immediate RTCP Report" bit set to 1, the receiver adjusts 208 counters as described above and then also performs the following 209 steps (with reference to the definitions and procedures of the AVPF 210 profile [5]): 212 1. ascertains whether the associated RTP session is operating under 213 the AVPF RTP profile (or one derived from it via combination with 214 another RTP profile). If not the receiver takes no further 215 action on this packet. If so, it continues as follows. 216 2. generates a feedback "Event" which in turn may trigger the 217 generation of a "FB message". 218 3. sends the FB message as an "early RTCP packet" assuming the 219 bandwidth constraints for feedback messages are satisfied. 221 4. Otherwise, takes no further action 223 2.7 Indication of No-OP Capability using SDP 225 Senders and receivers may indicate support for the No-Op payload 226 format, for example, by using the Session Description Protocol SDP 227 [3]. If the payload format is being used for connectivity 228 verification (e.g. in conjunction with [4]) senders and receivers 229 MUST advertise the AVPF profile (or a profile used in combination 230 with it). 232 The default packetization interval for this payload type is 20ms 233 (ptime:20) but alternate values can be advertised in SDP using the 234 ptime attribute value [3]. 236 3. Example SDP Offer/Answer 238 Offer: 239 v=0 240 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 241 s c=IN IP4 host.atlanta.example.com 242 t=0 0 243 m=audio 49170 RTP/AVP 0 33 244 a=rtpmap:0 PCMU/8000 245 a=rtpmap:33 no-op/8000 246 m=video 51372 RTP/AVP 31 36 247 a=rtpmap:31 H261/90000 248 a=rtpmap:36 no-op/90000 250 Answer: 251 v=0 252 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 253 s c=IN IP4 host.biloxi.example.com 254 t=0 0 255 m=audio 49174 RTP/AVP 0 33 256 a=rtpmap:0 PCMU/8000 257 a=rtpmap:33 no-op/8000 258 m=video 49170 RTP/AVP 32 36 259 a=rtpmap:32 MPV/90000 260 a=rtpmap:36 no-op/8000 262 4. MIME Registration 264 This section registers MIME types for audio/no-op, video/no-op, and 265 text/no-op. 267 4.1 audio/no-op 269 MIME media type name: audio 271 MIME subtype name: no-op 273 Required parameters: none 275 Optional parameters: none 277 Encoding considerations: This type is only defined for transfer via 278 RTP [2]. 280 Security considerations: See Section 5, "Security Considerations", in 281 this document. 283 Interoperability considerations: none 285 Published specification: This document. 287 Applications which use this media: The "no-op" application subtype is 288 used to maintain network state or verify network connectivity, when a 289 more traditional RTP payload type cannot be used. 291 Additional information: 293 1. Magic number(s): N/A 294 2. File extension(s): N/A 295 3. Macintosh file type code: N/A 297 4.2 video/no-op 299 MIME media type name: video 301 MIME subtype name: no-op 303 Required parameters: none 305 Optional parameters: none 307 Encoding considerations: This type is only defined for transfer via 308 RTP [2]. 310 Security considerations: See Section 5, "Security Considerations", in 311 this document. 313 Interoperability considerations: none 314 Published specification: This document. 316 Applications which use this media: The "no-op" application subtype is 317 used to maintain network state or verify network connectivity, when a 318 more traditional RTP payload type cannot be used. 320 Additional information: 322 1. Magic number(s): N/A 323 2. File extension(s): N/A 324 3. Macintosh file type code: N/A 326 4.3 text/no-op 328 MIME media type name: text 330 MIME subtype name: no-op 332 Required parameters: none 334 Optional parameters: none 336 Encoding considerations: This type is only defined for transfer via 337 RTP [2]. 339 Security considerations: See Section 5, "Security Considerations", in 340 this document. 342 Interoperability considerations: none 344 Published specification: This document. 346 Applications which use this media: The "no-op" application subtype is 347 used to maintain network state or verify network connectivity, when a 348 more traditional RTP payload type cannot be used. 350 Additional information: 352 1. Magic number(s): N/A 353 2. File extension(s): N/A 354 3. Macintosh file type code: N/A 356 5. Security Considerations 358 Without security of the RTP stream (via SRTP [8], IPsec [7], or other 359 means), it is possible for an attacker to spoof RTP packets, 360 including this new packet type. As this new RTP payload type 361 includes a method to request immediate transmission of RTCP, this 362 could be used to cause endpoints to flood the network with RTCP 363 reports. Thus, the RTCP transmissions MUST NOT exceed the bandwidth 364 recommendations described in section 6.3 of RFC3550 [2]. 366 6. IANA Considerations 368 IANA is requested to make a MIME type registration as specified above 369 in Section 4 371 7. Acknowledgments 373 Thanks to Henning Schulzrinne for suggesting using RTCP as a feedback 374 mechanism. 376 8. References 378 8.1 Normative References 380 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 381 Levels", BCP 14, RFC 2119, March 1997. 383 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 384 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 385 RFC 3550, July 2003. 387 [3] Handley, M. and V. Jacobson, "SDP: Session Description 388 Protocol", RFC 2327, April 1998. 390 [4] Andreasen, F., "Connectivity Preconditions for Session 391 Description Protocol Media Streams", 392 draft-andreasen-mmusic-connectivityprecondition-02 (work in 393 progress), February 2005. 395 [5] Ott, J. and S. Wenger, "Extended RTP Profile for RTCP-based 396 Feedback(RTP/AVPF)", draft-ietf-avt-rtcp-feedback-11 (work in 397 progress), August 2004. 399 [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 400 Methodology for Network Address Translator (NAT) Traversal for 401 Multimedia Session Establishment Protocols", 402 draft-ietf-mmusic-ice-04 (work in progress), February 2005. 404 8.2 Informational References 406 [7] Kent, S. and R. Atkinson, "Security Architecture for the 407 Internet Protocol", RFC 2401, November 1998. 409 [8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 411 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 412 RFC 3711, March 2004. 414 [9] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 415 Comfort Noise (CN)", RFC 3389, September 2002. 417 [10] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent 418 Call", RFC 4040, April 2005. 420 [11] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793, 421 May 2000. 423 [12] International Telecommunications Union, "G.729 Annex B", 424 November 1999, 425 . 427 Authors' Addresses 429 Flemming Andreasen 430 Cisco Systems, Inc. 431 499 Thornall Street, 8th Floor 432 Edison, NJ 08837 433 USA 435 Email: fandreas@cisco.com 437 David Oran 438 Cisco Systems, Inc. 439 7 Ladyslipper Lane 440 Acton, MA 01720 441 USA 443 Email: oran@cisco.com 445 Dan Wing 446 Cisco Systems, Inc. 447 170 West Tasman Drive 448 San Jose, CA 95134 449 USA 451 Email: dwing@cisco.com 453 Intellectual Property Statement 455 The IETF takes no position regarding the validity or scope of any 456 Intellectual Property Rights or other rights that might be claimed to 457 pertain to the implementation or use of the technology described in 458 this document or the extent to which any license under such rights 459 might or might not be available; nor does it represent that it has 460 made any independent effort to identify any such rights. Information 461 on the procedures with respect to rights in RFC documents can be 462 found in BCP 78 and BCP 79. 464 Copies of IPR disclosures made to the IETF Secretariat and any 465 assurances of licenses to be made available, or the result of an 466 attempt made to obtain a general license or permission for the use of 467 such proprietary rights by implementers or users of this 468 specification can be obtained from the IETF on-line IPR repository at 469 http://www.ietf.org/ipr. 471 The IETF invites any interested party to bring to its attention any 472 copyrights, patents or patent applications, or other proprietary 473 rights that may cover technology that may be required to implement 474 this standard. Please address the information to the IETF at 475 ietf-ipr@ietf.org. 477 The IETF has been notified of intellectual property rights claimed in 478 regard to some or all of the specification contained in this 479 document. For more information consult the online list of claimed 480 rights. 482 Disclaimer of Validity 484 This document and the information contained herein are provided on an 485 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 486 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 487 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 488 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 489 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 490 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 492 Copyright Statement 494 Copyright (C) The Internet Society (2005). This document is subject 495 to the rights, licenses and restrictions contained in BCP 78, and 496 except as set forth therein, the authors retain all their rights. 498 Acknowledgment 500 Funding for the RFC Editor function is currently provided by the 501 Internet Society.