idnits 2.17.1 draft-wing-avt-rtp-noop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 96: '... MUST use the same sequence number s...' RFC 2119 keyword, line 103: '... MAY be used. In accordance with cu...' RFC 2119 keyword, line 140: '...31: Reserved, and all bits MUST be 0....' RFC 2119 keyword, line 142: '...al padding bytes MAY be appended up to...' RFC 2119 keyword, line 143: '... 2.6). These bytes MUST contain all 0...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * if listening on a multicast IP address, the receiver MUST not send an immediate RTCP report, and the receiver MUST follow the normal RTCP transmission rules [RFC3550, sections 6.2 and 6.3]. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 92, but not defined -- Looks like a reference, but probably isn't: '1' on line 219 == Missing Reference: 'SRTP' is mentioned on line 242, but not defined == Unused Reference: 'RFC3407' is defined on line 288, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Flemming Andreasen 2 MMUSIC Working Group David Oran 3 INTERNET-DRAFT Dan Wing 4 Expires: August 2004 Cisco Systems 5 February, 2004 7 RTP No-Op Payload Format 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines an no-op payload format for the Real-time 38 Transport Protocol (RTP), and a mechanism to request an immediate 39 RTCP report. This can be used to verify RTP connectivity and to 40 keep Network Address Translator (NAT) bindings and Firewall pinholes 41 open. 43 TABLE OF CONTENTS 45 1. Introduction.....................................................2 46 1.1 Notational Conventions............................................2 47 2. RTP Payload Format for No-Op.......................................3 48 2.2 Registration......................................................3 49 2.3 Use of RTP Header Fields..........................................3 50 2.4 Payload Format....................................................3 51 2.5 Sender Operation..................................................4 52 2.6 Mixer, Translator Operation.......................................4 53 2.7 Receiver Operation................................................4 54 2.8 Indication of No-OP Capability using SDP..........................5 55 3. MIME Registration..................................................5 56 3.1. audio/no-op......................................................5 57 4. Security Considerations............................................6 58 5. Acknowledgements...................................................6 59 6. Authors' Addresses.................................................6 60 7. Normative References...............................................6 61 8. Informative References.............................................6 62 Intellectual Property Statement.......................................7 63 Full Copyright Statement..............................................7 64 Acknowledgement.......................................................8 66 1. Introduction 68 This memo defines a new RTP payload format called "no-op". This 69 payload behaves like a normal RTP payload, except that it isn't 70 played by the receiver. 72 This new payload format is useful for: 74 * bearer continuity testing, such as at the beginning of a call; 76 * keepalives to keep NAT bindings open when RTP media traffic is 77 not otherwise being transmitted; 79 For testing the RTP path, an RTP sender may transmit several No-Op 80 payload packets with the Request Immediate RTCP bit set to 0, 81 followed by one No-Op payload packet with the Request Immediate RTCP 82 bit set to 1. This would cause the RTP receiver to send an RTCP 83 report indicating the quality of the RTP path. The RTP sender could 84 then decide to continue with call setup, abort the session, or 85 perform some other action. 87 1.1 Notational Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. RTP Payload Format for No-Op 95 The no-op payload format is carried as part of the RTP stream, and 96 MUST use the same sequence number space, SSRC, and timestamp base as 97 the regular media. 99 2.2 Registration 101 The RTP payload format is designated as "no-op" and the MIME type as 102 "audio/no-op". The default clock rate is 8000 Hz, but other rates 103 MAY be used. In accordance with current practice, this payload 104 format does not have a static payload type number, but uses a RTP 105 payload type number established dynamically and out-of-band. 107 2.3 Use of RTP Header Fields 109 Timestamp: The RTP timestamp reflects the measurement point 110 for the current packet. The receiver calculates 111 jitter for RTCP receiver reports based on all 112 packets with a given timestamp. Note: The jitter 113 value should primarily be used as a means for 114 comparing the reception quality between two users 115 or two time-periods, not as an absolute measure. 117 Marker bit: The RTP marker bit has no special significance for 118 this payload type. 120 2.4 Payload Format 122 The payload format is shown in Figure 1. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 |R| reserved | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | padding (OPTIONAL) | 130 | .... | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 The payload contains at least 4 bytes. The first 32 bits are 134 defined as follows: 136 bit 0: "R", "Request immediate RTCP", is used to request 137 transmission of an immediate RTCP report (see section 138 2.7). 140 bits 1-31: Reserved, and all bits MUST be 0. 142 Additional padding bytes MAY be appended up to the negotiated ptime 143 value in SDP (see section 2.6). These bytes MUST contain all 0 144 bits. Padding may be useful to generate RTP packets that are the 145 same size as another payload (such as a normal voice payload). 147 2.5 Sender Operation 149 A source MAY send normal RTP audio and the no-op payload format for 150 the same time instants (but with different sequence numbers of 151 course). This might be done in conjunction with this payload 152 format's "Request Immediate RTCP" opcode. 154 2.6 Mixer, Translator Operation 156 An RTP mixer or unicast-to-unicast RTP translator SHOULD forward RTP 157 No-Op payload packets normally. A unicast-to-multicast RTP 158 translator SHOULD replicate RTP No-Op payload packets normally. 160 A multicast-to-unicast RTP translator SHOULD NOT replicate an RTP 161 No-Op packet with the Request Immediate RTCP bit set, because the 162 receivers won't be able to prevent flooding of the multicast RTP 163 sender. 165 2.7 Receiver Operation 167 Upon receipt of an RTP packet with the No-Op payload format and the 168 Send Immediate RTCP Report bit set to 0, the receiver performs 169 normal RTP receive operations on it -- incrementing the RTP receive 170 counter, calculating jitter, and so on. The receiver then discards 171 the packet -- it is not used to play out data. 173 Upon receipt of an RTP packet with the No-Op payload format and the 174 Send Immediate RTCP Report bit set to 1, the receiver performs the 175 steps above and: 177 * if listening on a multicast IP address, the receiver MUST not 178 send an immediate RTCP report, and the receiver MUST follow the 179 normal RTCP transmission rules [RFC3550, sections 6.2 and 6.3]. 181 * if listening on a unicast IP address and sending RTP traffic, 182 the receiver prepares to send an RTCP sender report, and 184 * if listening on a unicast IP address and receiving RTP traffic, 185 the receiver prepares to send an RTCP receiver report. 187 In all cases, before actually sending its RTCP report, the RTCP 188 bandwidth limits and randomization interval MUST be observed 189 [RFC3550, sections 6.2 and 6.3], most especially when multiple SSRCs 190 are in the same session. 192 2.8 Indication of No-OP Capability using SDP 194 Senders and receivers may indicate support for the No-Op payload 195 format, for example, by using the Session Description Protocol 196 ([SDP]). 198 If successful completion of RTP No-Op is required before completing 199 call establishment -- such as to verify the existence or quality of 200 the bearer path -- No-Op preconditions can be used [Andreasen]. 202 The default packetization interval for this payload type is 20ms 203 (ptime:20) but alternate values can be advertised in SDP using the 204 ptime attribute value [SDP]. 206 3. MIME Registration 208 3.1. audio/no-op 210 MIME media type name: audio 212 MIME subtype name: no-op 214 Required parameters: none 216 Optional parameters: none 218 Encoding considerations: This type is only defined for 219 transfer via RTP [1]. 221 Security considerations: See the "Security Considerations" 222 section in this document. 224 Interoperability considerations: none 226 Published specification: This document. 228 Applications which use this media: The "no-op" audio subtype 229 is used to maintain network state or verify network 230 connectivity, when a more traditional RTP payload type 231 cannot be used. 233 Additional information: 235 1. Magic number(s): N/A 237 2. File extension(s): N/A 239 3. Macintosh file type code: N/A 240 4. Security Considerations 242 Without security of the RTP stream (via SRTP [SRTP], IPsec, or other 243 means), it is possible for an attacker to spoof RTP packets, 244 including this new packet type. As this new RTP payload type 245 includes a method to request immediate transmission of RTCP, this 246 could be used to cause endpoints to flood the network with RTCP 247 reports. Thus, the RTCP transmissions MUST NOT exceed the bandwidth 248 recommendations described in section 6.3 of [RFC3550]. 250 5. Acknowledgements 252 Thanks to Henning Schulzrinne for suggesting using RTCP as a 253 feedback mechanism. 255 6. Authors' Addresses 257 Flemming Andreasen 258 Cisco Systems, Inc. 259 499 Thornall Street, 8th Floor 260 Edison, NJ 08837 USA 262 EMail: fandreas@cisco.com 264 David Oran 265 Cisco Systems, Inc. 266 7 Ladyslipper Lane 267 Acton, MA 01720 USA 269 EMail: oran@cisco.com 271 Dan Wing 272 Cisco Systems, Inc. 273 170 West Tasman Drive 274 San Jose, CA 95134 USA 276 EMail: dwing@cisco.com 278 7. Normative References 280 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 281 "RTP: A Transport Protocol for Real-Time Applications", 282 http://www.ietf.org/rfc/rfc3550.txt. 284 8. Informative References 286 [Andreasen] F. Andreasen, "No-Op Preconditions", Work In Progress. 288 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 289 Capability Declaration", October 2002, 290 http://www.ietf.org/rfc/rfc3407.txt 292 [SDP] M. Handley and V. Jacobson, "SDP: Session Description 293 Protocol", April 1998, http://www.ietf.org/rfc/rfc2327.txt. 295 Intellectual Property Statement 297 The IETF takes no position regarding the validity or scope of any 298 intellectual property or other rights that might be claimed to 299 pertain to the implementation or use of the technology described in 300 this document or the extent to which any license under such rights 301 might or might not be available; neither does it represent that it 302 has made any effort to identify any such rights. Information on the 303 IETF's procedures with respect to rights in standards-track and 304 standards-related documentation can be found in BCP-11. Copies of 305 claims of rights made available for publication and any assurances 306 of licenses to be made available, or the result of an attempt made 307 to obtain a general license or permission for the use of such 308 proprietary rights by implementors or users of this specification 309 can be obtained from the IETF Secretariat. 311 The IETF invites any interested party to bring to its attention any 312 copyrights, patents or patent applications, or other proprietary 313 rights which may cover technology that may be required to practice 314 this standard. Please address the information to the IETF Executive 315 Director. 317 Full Copyright Statement 319 Copyright(C) The Internet Society 2004. All Rights Reserved. 321 This document and translations of it may be copied and furnished to 322 others, and derivative works that comment on or otherwise explain it 323 or assist in its implementation may be prepared, copied, published 324 and distributed, in whole or in part, without restriction of any 325 kind, provided that the above copyright notice and this paragraph 326 are included on all such copies and derivative works. However, this 327 document itself may not be modified in any way, such as by removing 328 the copyright notice or references to the Internet Society or other 329 Internet organizations, except as needed for the purpose of 330 developing Internet standards in which case the procedures for 331 copyrights defined in the Internet Standards process must be 332 followed, or as required to translate it into languages other than 333 English. 335 The limited permissions granted above are perpetual and will not be 336 revoked by the Internet Society or its successors or assigns. 338 This document and the information contained herein is provided on an 339 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 340 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 341 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 342 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 343 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 345 Acknowledgement 347 Funding for the RFC Editor function is currently provided by the 348 Internet Society.