idnits 2.17.1 draft-taylor-mmusic-multev-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 202. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 208. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4733, but the abstract doesn't seem to directly say this. It does mention RFC4733 though, so this could be OK. 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4733, updated by this document, for RFC5378 checks: 2002-05-29) -- 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 4, 2007) is 6315 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 146 == Unused Reference: '2' is defined on line 156, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multiparty Multimedia Session T. Taylor 3 Control (mmusic) Nortel 4 Internet-Draft January 4, 2007 5 Updates: 4733 (if approved) 6 Intended status: Standards Track 7 Expires: July 8, 2007 9 Signalling the Ability To Understand Packing of Multiple Telephony 10 Events Into One RTP Packet 11 draft-taylor-mmusic-multev-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 8, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2007). 42 Abstract 44 Section 2.5.1.5 of RFC 4733 specifies how an implementation of the 45 telephony-event payload type can pack multiple short-duration event 46 reports into one RTP packet. Because this capability was added to 47 RFC 4733 in a fashion which is not backward compatible with RFC 2833, 48 it is desirable that a sender have the means to determine whether the 49 receiver understands such packets. This memo specifies a new SDP 50 attribute, a=multev, to indicate that capability. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Proposed New SDP Attribute a=multev . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 Intellectual Property and Copyright Statements . . . . . . . . . . 10 63 1. Terminology 65 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 66 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 67 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. 69 2. Introduction 71 RFC 4733, recently published, has replaced RFC 2833. The latter is 72 best known as the preferred mechanism for in-band transmission of 73 DTMF, but also had other applications including the transmission of 74 data modem signals over RTP. Section 2.5.1.5 of RFC 4733 introduced 75 a new capability to optimize the usage of the telephone-event payload 76 to carry a series of short-duration events such as those found in 77 data modem signalling. This new capability allows the sender to pack 78 multiple event reports into a single RTP packet, provided that they 79 occur consecutively without a pause between them. 81 Unfortunately, packets containing multiple event reports cannot be 82 processed properly by implementations of RFC 2833. At best, an RFC 83 2833 receiver would handle the first event in the packet 84 successfully, but would ignore the remaining events in the packet. 85 At worst, the RFC 2833 receiver would identify the packet as 86 malformed and discard it. In either case, meaningful information 87 would fail to be transmitted. 89 As a result, it is desirable for an RFC 4733 implementation to know 90 in advance whether its peer acting as receiver has the capability to 91 process multiple event reports in a single RTP packet. 93 3. Proposed New SDP Attribute a=multev 95 To meet the need just described, this memo introduces the 97 a=multev 99 SDP attribute. If this attribute is present in a session 100 description, it indicates that the originator of the session 101 description can properly decode RTP packets containing multiple event 102 reports as specified by RFC 4733 sections 2.5.1.5 and 2.5.2.4. 104 The a=multev attribute MAY be present at either the session level or 105 media level. At the session level, this attribute indicates that the 106 capability to decode multiple event reports in one RTP packet is 107 applicable to any media stream within the session which carries the 108 audio/telephone-event payload type. At the media level, the a=multev 109 attribute indicates the capability of decoding multiple event reports 110 in an RTP packet for this particular stream (which typically will be 111 limited to a specific set of events.) If the attribute is present at 112 both levels, the media-level occurrences serve as hints as to the 113 particular streams in which packing of multiple events is expected. 115 An implementation of RFC 4733 MAY choose always to report just one 116 event per RTP packet, to guarantee backward compatibility. In the 117 alternative, an implementation of RFC 4733 that also supports the 118 present memo MUST NOT encode multiple events into one RTP packet 119 unless it has determined that its peer is able to decode those events 120 properly. The receipt of a session description containing the 121 a=multev attribute is one means of making such a determination. If 122 this attribute is present only at the media level, the sender MUST 123 NOT encode multiple events into one RTP packet for media streams 124 other than those identified by the presence of the attribute. 126 4. Security Considerations 128 The a=multev attribute introduces no new security threats, with the 129 possible exception that a man-in-the-middle attacker could insert the 130 attribute into messages containing SDP where it was absent. This 131 would constitute a rather weak denial of service threat, since the 132 SDP receiver might not choose to use the event packing capability 133 even though the SDP sender seemingly signalled willingness to accept 134 packed events. Since since such an attacker is in a position to 135 introduce much more effective attacks, there is little point to 136 taking special measures to protect against this one. In general, 137 this points to a requirement to provide message integrity for 138 signalling. 140 5. IANA Considerations 142 This document registers an additional SDP attribute "multev" as 143 defined in this document, within the registry for "att-field (both 144 session and media level)". 146 multev [RFCXXXX] 148 NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by 149 the RFC number assigned to this document. 151 6. Normative References 153 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 154 Levels", BCP 14, RFC 2119, March 1997. 156 [2] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, 157 Telephony Tones, and Telephony Signals", RFC 4733, 158 December 2006. 160 Author's Address 162 Tom Taylor 163 Nortel 164 1852 Lorraine Ave 165 Ottawa, Ontario K1H 6Z8 166 CA 168 Email: taylor@nortel.com 170 Full Copyright Statement 172 Copyright (C) The Internet Society (2007). 174 This document is subject to the rights, licenses and restrictions 175 contained in BCP 78, and except as set forth therein, the authors 176 retain all their rights. 178 This document and the information contained herein are provided on an 179 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 180 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 181 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 182 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 183 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 184 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 186 Intellectual Property 188 The IETF takes no position regarding the validity or scope of any 189 Intellectual Property Rights or other rights that might be claimed to 190 pertain to the implementation or use of the technology described in 191 this document or the extent to which any license under such rights 192 might or might not be available; nor does it represent that it has 193 made any independent effort to identify any such rights. Information 194 on the procedures with respect to rights in RFC documents can be 195 found in BCP 78 and BCP 79. 197 Copies of IPR disclosures made to the IETF Secretariat and any 198 assurances of licenses to be made available, or the result of an 199 attempt made to obtain a general license or permission for the use of 200 such proprietary rights by implementers or users of this 201 specification can be obtained from the IETF on-line IPR repository at 202 http://www.ietf.org/ipr. 204 The IETF invites any interested party to bring to its attention any 205 copyrights, patents or patent applications, or other proprietary 206 rights that may cover technology that may be required to implement 207 this standard. Please address the information to the IETF at 208 ietf-ipr@ietf.org. 210 Acknowledgment 212 Funding for the RFC Editor function is provided by the IETF 213 Administrative Support Activity (IASA).