idnits 2.17.1 draft-andreasen-mmusic-sdp-simcap-04.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 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 (August 2001) is 8290 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 42 looks like a reference -- Missing reference section? '3' on line 139 looks like a reference -- Missing reference section? '4' on line 336 looks like a reference -- Missing reference section? '5' on line 50 looks like a reference -- Missing reference section? '6' on line 53 looks like a reference -- Missing reference section? '7' on line 54 looks like a reference -- Missing reference section? '8' on line 204 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group F. Andreasen 3 Internet-Draft Cisco Systems 4 Document: draft-andreasen-mmusic-sdp-simcap-04.txt August 2001 5 Category: Informational 7 SDP Simple Capability Negotiation 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Abstract 30 This document defines a set of Session Description Protocol (SDP) 31 attributes that enables SDP to provide a minimal and backwards 32 compatible capability negotiation mechanism. The mechanism can be 33 used as a simple and limited solution to the general capability 34 negotiation problem being addressed by the next generation of SDP, 35 also known as SDPng. 37 2. Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 41 this document are to be interpreted as described in RFC-2119 [2]. 43 3. Introduction 45 The Session Description Protocol (SDP) [3] describes multimedia 46 sessions for the purposes of session announcement, session 47 invitation, and other forms of multimedia session initiation. SDP 48 was not intended to provide capability negotiation, however as the 49 need for this has become increasingly important, work has begun on a 50 "next generation SDP" (SDPng) [4,5] that supports both session 51 description and capability negotiation. SDPng is not anticipated to 52 be backwards compatible with SDP and work on SDPng is currently in 53 the early stages. However, several other protocols, e.g. SIP [6] and 54 MGCP [7], use SDP and are likely to continue doing so for the 55 foreseeable future. Nevertheless, in many cases these signaling 56 protocols have an urgent need for some limited form of capability 57 negotiation. 59 For example, an endpoint may support G.711 audio (over RTP) as well 60 as T.38 fax relay (over UDP or TCP). Unless the endpoint is willing 61 to support two media streams at the same time, this cannot currently 62 be expressed in SDP. Another example involves support for multiple 63 codecs. An endpoint indicates this by including all the codecs in 64 the "m=" line in the session description. However, the endpoint 65 thereby also commits to simultaneous support for each of these 66 codecs. In practice, DSP memory and processing power limitations may 67 not make this feasible. 69 As noted in [4], the problem with SDP is, that media descriptions 70 are used to describe session parameters as well as capabilities 71 without a clear distinction between the two. 73 In this document, we define a minimal and backwards compatible 74 capability negotiation feature in SDP by defining a set of new SDP 75 attributes. It should be noted, that the mechanism is not intended 76 to solve the general capability negotiation problem targeted by 77 SDPng. It is merely intended as a simple and limited solution to the 78 most urgent problems facing current users of SDP. 80 4. Simple Capability Negotiation Attributes 82 The SDP Simple Capability Negotiation (simcap) is defined by a set 83 of SDP attributes. Together, these attributes form a capability set 84 which describes the media capabilities of the endpoint. 86 The capability set MUST begin with a single sequence number followed 87 by one or more capability descriptions listing all media formats the 88 endpoint is currently able and willing to support. A subsequent 89 request to use one of these media formats is however not guaranteed 90 to succeed, e.g. due to limited DSP processing power or bandwidth 91 constraints. Note, that by definition, the capability set MUST 92 include capability descriptions for all the media formats listed in 93 the media lines ("m="). 95 The individual capability descriptions in a capability set may be 96 provided contiguously or they may be scattered throughout the 97 session description. The first capability description however MUST 98 follow immediately after the sequence number. 100 The sequence number is on the form: 102 a=sqn: 104 where is an integer between 0 and 255 (both included). The 105 initial sequence number MUST be 0 (zero) and it MUST be incremented 106 by 1 modulo 256 with each new capability set issued by the endpoint. 107 Receivers however may not necessarily see all capability sets issued 108 and hence MUST NOT reject a capability set due to gaps in sequence 109 numbers. The sequence number MUST either be provided as a session- 110 level or media-level attribute, however there MUST NOT be more than 111 one occurrence of the sequence number in the session description. 113 Each capability description in the capability set is on the form: 115 a=cdsc: 117 where is an integer between 1 and 255 (both included) 118 identifying the capability, and , , and 119 are defined as in the SDP "m=" line. The capability description 120 refers to a send and receive capability by default. When generating 121 a capability set, the capability number MUST start with 1 in the 122 first capability description, and be incremented by the number of 123 capabilities in the for each subsequent capability 124 description. Receivers of a capability set however MUST NOT reject 125 capability descriptions due to gaps in the capability numbers. The 126 capability number provides a convenient handle within the context of 127 the capability set (as referenced by the sequence number) which may 128 be used to reference a particular capability by means outside of 129 this specification. 131 A capability description can include one or more capability 132 parameter lines on the form: 134 a=cpar: 135 a=cparmin: 136 a=cparmax: 138 where is either bandwidth information ("b=") or an 139 attribute ("a=") in its full '=' form (see [3]). A 140 capability parameter line provides additional parameters for the 141 preceding "cdsc" attribute line. Capability parameter lines for a 142 capability description SHOULD immediately follow the "cdsc" line 143 they refer to. Nevertheless, the capability description includes all 144 capability parameter lines until the next capability description 145 ("cdsc") or media ("m=") line in the session description. 147 The "cpar" attribute should normally be used when parameter values 148 are to be specified. A capability description may contain zero, one, 149 or more "cpar" attribute lines describing either the same or 150 different parameters. Describing the same parameter more than once 151 can be used to specify alternatives. 153 Where a minimum numerical value is to be specified, the "cparmin" 154 attribute should be used. There may be zero, one, or more "cparmin" 155 attribute lines in a capability description, however a given 156 parameter MUST NOT be described by a "cparmin" attribute more than 157 once. 159 Where a maximum numerical value is to be specified, the "cparmax" 160 attribute should be used. There may be zero, one, or more "cparmax" 161 attribute lines in a capability description, however a given 162 parameter MUST NOT be described by a "cparmax" attribute more than 163 once. 165 Ranges of numerical values can be expressed by using a "cparmin" and 166 a "cparmax" attribute for a given parameter. It follows from the 167 previous rules, that only a single range can be specified for a 168 given parameter. 170 Capability descriptions may be provided at both the session-level 171 and media-level. A capability description provided at the session- 172 level applies to all the media streams of the indicated media type 173 in the session description. A capability description provided at the 174 media-level only applies to that particular media stream (regardless 175 of media type). If a capability description with media type X is 176 provided at the session-level, and there are no media streams of 177 type X in the session description, then it is undefined which of the 178 media streams the capability description applies to (except if there 179 is only one media stream). It is therefore RECOMMENDED, that such 180 capabilities are provided at the media-level instead. 182 Below we show an example session description using the above simple 183 capability negotiation mechanism: 185 v=0 186 o=- 25678 753849 IN IP4 128.96.41.1 187 s=- 188 c=IN IP4 128.96.41.1 189 t=0 0 190 m=audio 3456 RTP/AVP 18 96 191 a=rtpmap:96 telephone-event 192 a=fmtp:96 0-15,32-35 193 a=sqn: 0 194 a=cdsc: 1 audio RTP/AVP 0 18 96 195 a=cpar: a=fmtp:96 0-16,32-35 196 a=cdsc: 4 image udptl t38 197 a=cdsc: 5 image tcp t38 199 The sender of this session description is currently prepared to send 200 and receive G.729 audio as well as telephone-events 0-15 and 32-35. 201 The sender is furthermore capable of supporting: 202 * PCMU encoding for the audio media stream, 203 * telephone events 0-16 and 32-35, 204 * T.38 fax relay using udp or tcp (see [8]). 206 Note, that the first capability number specified is 1, whereas the 207 next is 4 since three media formats were included in the first 208 capability description. Also note, that the rtpmap for payload type 209 96 was not included in the capability description, as it was already 210 specified for the media ("m=") line. 212 Below, we show another example of the simple capability negotiation 213 mechanism, this time with multiple media streams: 215 v=0 216 o=- 25678 753849 IN IP4 128.96.41.1 217 s=- 218 c=IN IP4 128.96.41.1 219 t=0 0 220 m=audio 3456 RTP/AVP 18 221 a=sqn: 0 222 a=cdsc: 1 audio RTP/AVP 0 18 223 m=video 3458 RTP/AVP 31 224 a=cdsc: 3 video RTP/AVP 31 34 226 The sender of this session description is currently prepared to send 227 and receive G.729 audio and H.261 video. The sender is furthermore 228 capable of supporting: 229 * PCMU encoding for the audio media stream, 230 * H.263 for the video media stream. 232 Note, that the first capability number specified is 1, whereas the 233 next is 3 since two media formats were included in the first 234 capability description. Also note, that the sequence number applies 235 to the entire capability set, i.e. both audio and video, and hence 236 is only supplied once. Finally, note that the media formats 18 and 237 31 are listed in both the media lines and the capability set as 238 required. The above session description could equally well have been 239 supplied as follows: 241 v=0 242 o=- 25678 753849 IN IP4 128.96.41.1 243 s=- 244 c=IN IP4 128.96.41.1 245 t=0 0 246 a=sqn: 0 247 a=cdsc: 1 audio RTP/AVP 0 18 248 a=cdsc: 3 video RTP/AVP 31 34 249 m=audio 3456 RTP/AVP 18 250 m=video 3458 RTP/AVP 31 252 i.e., with the capability set provided at the session-level. 254 5. Security Considerations 256 The addition of the simple capability negotiation attributes to SDP 257 is not believed to cause security issues beyond those discussed in 258 RFC 2327. 260 6. IANA Considerations 262 This document defines the following new SDP parameters of type "att- 263 field" (attribute names): 265 Attribute name: sqn 266 Long form name: Sequence number. 267 Type of attribute: Session-level and media-level. 268 Subject to charset: No. 269 Purpose: Capability set numbering. 270 Appropriate values: See Section 4. 272 Attribute name: cdsc 273 Long form name: Capability description. 274 Type of attribute: Session-level and media-level. 275 Subject to charset: No. 276 Purpose: Describe capabilities in a capability set. 277 Appropriate values: See Section 4. 279 Attribute name: cpar 280 Long form name: Capability parameter line. 281 Type of attribute: Session-level and media-level. 282 Subject to charset: No. 283 Purpose: Provide capability description parameters. 284 Appropriate values: See Section 4. 286 Attribute name: cparmin 287 Long form name: Minimum capability parameter line. 288 Type of attribute: Session-level and media-level. 289 Subject to charset: No. 290 Purpose: Provide minimum capability description 291 parameters. 292 Appropriate values: See Section 4. 294 Attribute name: cparmax 295 Long form name: Maximum capability parameter line. 296 Type of attribute: Session-level and media-level. 297 Subject to charset: No. 298 Purpose: Provide maximum capability description 299 parameters. 300 Appropriate values: See Section 4. 302 7. References 304 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 305 9, RFC 2026, October 1996. 307 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 308 Levels", BCP 14, RFC 2119, March 1997 310 3 M. Handley and V. Jacobson, "SDP: session description protocol," 311 Request for Comments (Proposed Standard) 2327, Internet 312 Engineering Task Force, Apr. 1998. 314 4 Kutscher, Ott, Bormann, Curcio, "Requirements for Session 315 Description and Capability Negotiation", Internet-Draft, Internet 316 Engineering Task Force, April 2001. Work in Progress. 318 5 Kutscher, Ott, Borman, "Session Description and Capability 319 Negotiation", Internet-Draft, Internet Engineering Task Force, 320 April 2001. Work in Progress. 322 6 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 323 session initiation protocol," Request for Comments (Proposed 324 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 326 7 Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, 327 "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, 328 October 1999. 330 8 ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment 331 Procedures". 333 8. Acknowledgments 335 This work draws upon the ongoing work on SDPng in the IETF MMUSIC 336 Working Group; in particular [4]. Furthermore this work was inspired 337 by the CableLabs PacketCable project. The author would like to 338 recognize and thank Joerg Ott, who provided many detailed comments 339 and suggestions to improve this specification. Orit Levin and Tom 340 Taylor provided valuable feedback as well. 342 9. Author's Addresses 344 Flemming Andreasen 345 Cisco Systems 346 499 Thornall Street, 8th floor 347 Edison, NJ 348 Email: fandreas@cisco.com 350 Full Copyright Statement 352 Copyright (C) The Internet Society (2001). All Rights Reserved. 354 This document and translations of it may be copied and furnished to 355 others, and derivative works that comment on or otherwise explain it 356 or assist in its implementation may be prepared, copied, published 357 and distributed, in whole or in part, without restriction of any 358 kind, provided that the above copyright notice and this paragraph 359 are included on all such copies and derivative works. However, this 360 document itself may not be modified in any way, such as by removing 361 the copyright notice or references to the Internet Society or other 362 Internet organizations, except as needed for the purpose of 363 developing Internet standards in which case the procedures for 364 copyrights defined in the Internet Standards process must be 365 followed, or as required to translate it into languages other than 366 English. 368 The limited permissions granted above are perpetual and will not be 369 revoked by the Internet Society or its successors or assigns. 371 This document and the information contained herein is provided on an 372 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 373 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 374 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 375 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 376 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Acknowledgement 380 Funding for the RFC editor function is currently provided by the 381 Internet Society.