idnits 2.17.1 draft-ietf-mmusic-sdpng-trans-03.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 the list of Shadow Directories. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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. RFC 2119 keyword, line 340: '... SDPng contents MAY be identified by ...' RFC 2119 keyword, line 342: '... but this is NOT RECOMMENDED. Instead,...' RFC 2119 keyword, line 346: '...is available and SHOULD be used to dif...' RFC 2119 keyword, line 354: '... It is RECOMMENDED that impleme...' RFC 2119 keyword, line 364: '..., session announcements SHOULD be made...' (10 more instances...) 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 (February 2003) is 7731 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) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-11 == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-05 ** Obsolete normative reference: RFC 3388 (ref. '4') (Obsoleted by RFC 5888) -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-04 == Outdated reference: A later version (-02) exists of draft-camarillo-mmusic-alt-00 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-05) exists of draft-ietf-mmusic-sdp4nat-02 == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-06 ** Obsolete normative reference: RFC 3266 (ref. '12') (Obsoleted by RFC 4566) == Outdated reference: A later version (-07) exists of draft-ietf-sip-manyfolks-resource-03 == Outdated reference: A later version (-01) exists of draft-camarillo-mmusic-source-sink-00 -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-srcfilter-02 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Ott/C. Perkins 2 Expires: August 2003 TZI/ISI 3 February 2003 5 SDPng Transition 6 draft-ietf-mmusic-sdpng-trans-03.txt 8 Status of this memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 Distribution of this document is unlimited. 31 This document is a product of the Multiparty Multimedia Session 32 Control (MMUSIC) working group of the Internet Engineering Task 33 Force. Comments are solicited and should be addressed to the working 34 group's mailing list at mmusic@ietf.org and/or the authors. 36 Abstract 38 The Session Description Protocol (SDP) is today widely used in the 39 Internet to announce as well as negotiate multimedia sessions and 40 exchange capabilities. Having originally been designed for session 41 announcements only, as opposed to announcements and capabilities 42 negotiation announcements, native SDP lacks numerous features to be 43 applicable in many session scenarios. Numerous extensions have been 44 developed to circumvent SDP's shortcomings -- but they have also 45 repeatedly shown its inherent limitations. A successor protocol -- 46 termed "SDPng" for the time being -- is developed to address the 47 aforementioned needs of Internet applications in a more structured 48 manner. With the huge installed base of SDP-based applications, a 49 migration path needs to be developed to move from SDP to SDPng over 50 time. This document outlines how this migration can be achieved: in 51 general as well as for the various IETF control protocols that 52 potentially make use of SDP and SDPng. 54 1. Introduction 56 SDP is now widely used within the Internet community to describe 57 media sessions and, in a limited fashion, system capabilities 58 relating to (multi)media sessions, for a variety of application 59 scenarios: session announcements, interactive session setup, 60 capability assessment and remote control of media streams. All but 61 the first of these are rather different from what SDP was originally 62 designed for -- but all of them share the idea of setting up and 63 configuring media streams. Over time, its wide range of uses has 64 revealed numerous shortcomings -- most of which stem from the fact 65 that SDP has been used for lack of a better alternative and its 66 semantics have been re-interpreted to make it fit the respective 67 scenarios' needs. In many cases, workrounds (typically called 68 "extensions") for those shortcomings could be found which are often 69 rather cumbersome. While this practice has extended SDP's lifetime 70 and provided at least a suitable basis for numerous applications, in 71 parallel, a successor protocol -- currently referred to as "SDPng" 72 -- has been developed. 74 It is worthwhile noting that the aforementioned applications' 75 needs are sufficiently similar for a single description protocol 76 to take care of them if it was designed for this purpose from 77 the beginning. As a lesson learned from SDP, any further 78 expansion in scope should be avoided where no clear fit can be 79 seen -- and specific (different) solutions should be developed 80 instead. 82 The design of SDPng takes into account the requirements arising from 83 the above application scenarios and puts particular emphasis on 84 protocol extensibility and modularization of extensions, at the same 85 time keeping the core description format simple. SDPng uses a 86 different (more expressive) syntax than SDP does and hence is not 87 backward compatible at the syntax level. Nevertheless, the concepts 88 of SDPng take into account the migration issues from SDP to SDPng by 89 providing straightforward mappings between the two formats where 90 possible and try to maximize compatibility from a semantics 91 perspective. 93 The current revisions of SDP and SDPng are documented in 95 o draft-ietf-mmusic-sdp-new-11.txt [1] and 97 o draft-ietf-mmusic-sdpng-05.txt [2]. 99 For SDP, a number of additional features are defined in the following 100 documents that need to be taken into account: 102 o the offer/answer scheme of interpreting and matching media 103 session descriptions to negotiate media sessions to be used in 104 call or conference in a single round-trip (RFC 3264 [6]); 106 o full support for IPv6 as network layer protocol (RFC 3266 [12]); 108 o SDP extensions to allow selecting ATM virtual circuits as 109 additional network protocol and specifying ATM-specific 110 parameters (RFC 3108 [3]); 112 o a general extension to deal with connection-oriented transport 113 protocols such as TCP [8]; 115 o an extension to support SCTP as media transport protocol in 116 addition to UDP and TCP [7]; 118 o an SDP extension to explicitly specify RTCP port number to 119 enable the necessary expressiveness for NAT traversal [10]; 121 o a mechanism (media identification, "mid") for naming and 122 grouping ("group") SDP media lines according to one or more 123 criteria, e.g. for the purpose of lip-synchronization or for 124 identifying media sessions carrying the same content (RFC 3388 125 [4], [9]); 127 o the capability to indicate which media sessions shall be mapped 128 into the same resource reservation context [13]; 130 o an extension to allow expression of simultanous capabilities 131 across media sessions and formats (RFC 3407 [5]) 133 o attributes for passing parameters of a keying protocol (such as 134 MIKEY) as part of a session description [11]; 136 o support for conveying cryptographic parameters as part of a 137 session description [15]; 139 o a mechanism to explicitly specify the sources allowed to provide 140 input to media sessions [16]; and 142 o a simple language to provide instructions to media mixers on 143 which incoming media streams shall be combined to produce which 144 outgoing ones (and possibly how they shall be combined) [14]. 146 This document outlines a migration path from SDP to SDPng, starting 147 from a short overview of the current application scenarios. In the 148 next step, we highlight which design decisions taken for SDPng should 149 simplify a smooth migration and describe how mappings between the two 150 description formats can be performed at an abstract level. We then 151 address procedural issues for integrating SDP and SDPng into the 152 various protocols relying on those media description formats. 153 Finally, we summarize work items on the agenda for SDPng. 155 2. Application Scenarios 157 The following session control protocols that make use of SDP have 158 been standardized in the IETF so far: 160 1. SDP was originally developed to announce (Mbone-based) 161 multimedia sessions via session directories using the Session 162 Announcement Protocol (SAP) -- but other mechanisms for 163 disseminating the session descriptions (such as HTTP, SMTP, 164 NNTP, etc.) are conceivable as well. 166 The major property of this application scenario is that the 167 creator of the session description defines a (set of) fixed 168 choice(s) for all media types in a conference and the conference 169 partipants have no way to influence these. If they support at 170 least one of the codecs for a particular media type they can 171 participate in this media session, otherwise they cannot. There 172 is no interaction between sender(s) and receiver(s) to negotiate 173 the media stream codecs and parameters. 175 This scenario is referred to as "announcement". 177 2. Another use of SDP is in conjunction with the Real-Time 178 Streaming Protocol (RTSP). In RTSP, SDP is used to convey 179 descriptions of a media stream interactively requested to be 180 played from a server (or recorded by a server). SDP itself is 181 not used for capability negotiation, not even for the addresses 182 to be used; those are negotiated within RTSP and may override 183 the addresses specified as part of SDP. 185 This scenario is referred to as "retrieval". 187 3. With SIP, SDP is used to propose media stream configurations and 188 choose out of these (i.e. enable a subset of these). By 189 proposing and accepting media stream configurations, endpoints 190 use SDP to implicitly describe their capabilities and carry out 191 a negotiation procedure on the media streams to use. 193 In the context of SIP, specific meanings (including required 194 extensions) have been defined for use of SDP with unicast 195 addresses, for connection-oriented transports, and for certain 196 media level attributes (such as the direction attribute send- 197 only, receive-only, and inactive). 199 Numerous extensions have been proposed to extend SDP to better 200 suit SIP's needs. Besides a description of the offer/answer 201 model, these extensions particularly include the ability to 202 describe simultaneous capabilites and to group media stream 203 semantically. 205 This scenario is referred to as "offer/answer". 207 4. SDP is used to convey the capability descriptions of a MEGACO 208 media gateway (MG) to its media gateway controller (MGC) as well 209 as for the MGC to instruct the MG where to send media streams to 210 and from where to receive media streams, including codec and 211 parameter choice. 213 For this purpose, SDP has been modified/extended to some degree 214 to fit the MEGACO needs. 216 This scenario is referred to as "gateway control". 218 It should noted that the original SDP concept already provided an 219 extension mechanism to cover other network types than IPv4 and IPv6; 220 however, specific extensions have only been defined recently for ATM 221 and are now under discussion for TDM. Extensions to other transport 222 (including radio interfaces or next generation wireless networks) as 223 well as to new types of session descriptions (e.g. electronic program 224 guides) are conceivable. 226 3. Mapping SDP to SDPng 228 On a transition path from SDP to SDPng, allowing for a somewhat 229 straightforward mapping of (parts of) one description format onto the 230 other is of crucial importance. SDPng has been designed in a way that 231 allows many of the session description features of SDP to be easily 232 mapped onto the SDPng format and vice versa -- except that SDPng is 233 more expressive than SDP, and hence information loss is not unlikely 234 to occur when doing the reverse mapping. The final mapping rules 235 between SDP and SDPng to be drawn up shall ensure that mapping 236 SDP to SDPng and then back to SDP will produce an SDP that is 237 functionally identical to the one originally fed into the mapping 238 process. Note that the use of a number of SDP extensions (FID, 239 SIMCAP) may be implied in this mapping process, depending on the use 240 of SDP. The mapping rules will ensure that no information loss will 241 occur when translating from SDP to SDPng. 243 The SDPng design uses a structure of four sections: definitions, 244 potential or actual configurations, constraints and session 245 attributes. Of these, the "Configurations" and "Session 246 Attributes" sections map well onto the current SDP. The 247 "Definitions" and "Constraints" sections provide additional 248 structure which is not directly expressible in SDP. 250 o At the media description level, the Potential and Actual 251 Configurations specified in the "Configurations" section maps 252 well to SDP media descriptions ("m=", possibly "c=", and 253 associated attributes ("a=") lines). 255 o At the session description level, the SDP session parameters are 256 largely reflected in the "Session Attributes" section of 257 SDPng. The attributes proven suitable for session announcements 258 have been used as the basis when defining SDPng. 260 In SDPng, media descriptions are explicitly tagged with identifiers 261 and thus are easily referenced for semantically grouping media 262 streams (e.g. to describe alternative audio in different languages, 263 media streams to be synchronized, or media streams to carry the same 264 information simultaneously but with different encodings) -- as has 265 been defined for SDP in a limited fashion by the "fid" attribute 266 set. SDPng allows even to more formally describe the syntax of 267 individual or compound media streams in the "Session Attributes" 268 section. Furthermore, SDPng supports a superset of additional 269 constraints that may be realized by the "simcap" extensions for SDP 270 in the "Constraints" section. 272 Additional address families such as ATM or TDM bearers, next 273 generation wireless network bearers, DVB channels, etc. can be 274 incorporated into SDPng by defining the appropriate extensions for 275 the SDPng transports. 277 Similarly, new codecs can be added by just defining new codec 278 specifications or defining entire new classes of applications to be 279 described as new content types ("codec") to be carried in a media 280 session (including e.g. text, fax, slide presentations, shared 281 editors, etc). If necessary, sophisticated parameter structures can 282 be supported (even though the authors believe that simplicity is key 283 to interoperability here). This is similar to, but more structured 284 than, the definition of new codec attributes in MIME registrations 285 for SDP. 287 It is expected that the MIME namespace for codecs will be mapped 288 into the SDPng namespace, and a consistent mapping from SDP 289 "a=fmtp:" attributes to SDPng codec parameters will be 290 defined. 292 By means of its conceptual differentiation into Potential and Actual 293 Configurations, SDPng supports both indicating a system's 294 capabilities (without specifying transport addresses) separately from 295 the instantiation of a particular media stream as well as conveying 296 capability descriptions and instantiation proposals at the same time 297 -- thereby providing a good fit for all the above session control 298 scenarios: the "announcement" and "retrieval" scenarios will just 299 use rather fixed Actual Configurations. The "offer/answer" model 300 will use use Actual Configuration but use them to negotiate media 301 strams in a two-way handshake but may in addition use Potential 302 Configurations to indicate capabilities that shall not be used 303 immediately. The "gateway control" scenario will use both: 304 Potential Configurations to describe an MG's capabilities and Actual 305 Configurations for setting up media sessions at MGs as well as 306 retrieving information about currently active media sessions. This 307 differentiation is not directly expressible in SDP, although various 308 extensions can be used to overload SDP semantics to achieve at least 309 part of this effect. 311 Finally, while the short-term SDPng specification aims at supporting 312 only the widespread offer/answer model for capability negotiation, a 313 future extension will also allow for content-independent negotiation 314 of session parameters by defining collapsing/intersection rules. In 315 particular, SDPng will take the need for multicast-based distributed 316 calculation of joint capabilities into account for those rules (but 317 note that it is NOT intended as a generic format for describing 318 conference state information). Such functionality is not covered by 319 current SDP -- but there is also no perceived urgent demand so that 320 this sophisticated functional component of SDPng is left to a future 321 protocol extension. The base SDPng protocol will provide the 322 necessary flexibility, however. 324 4. Integration with Session Control Protocols 326 This section outlines for each of the session control protocols 327 described above how SDP and SDPng can be used in parallel and 328 indicates how a suitable transition could be achieved. 330 4.1. Session Announcement Protocol (SAP) 332 There are two revisions of SAP specified, version 0 which is 333 implemented in a number of experimental tools, and version 1 which is 334 defined in RFC 2972. 336 SAPv0:SAPv0 does not support a mechanism to identify the content type 337 of a session announcement but implicitly assumes SDP. Proper 338 parsers will note that the contents of the SAPv0 message does 339 not begin with a "v=" line and hence will ignore the entire 340 announcement. SDPng contents MAY be identified by a different 341 character sequence in the beginning of the announcement body, 342 but this is NOT RECOMMENDED. Instead, SAPv1 SHOULD be used, 343 since it contains an explicit payload identifier. 345 SAPv1:In SAPv1, an explicit payload type field (containing a MIME 346 type) is available and SHOULD be used to differentiate between 347 SDP and SDPng contents. Two approaches are conceivable: Either 348 a multipart MIME message is used with two parts containing the 349 same session descriptions -- one expressing it in SDP and the 350 other in SDPng. Alternatively, two separate session 351 announcements may be used (being properly distinguished by the 352 SDP "o=" field and the SDPng equivalent). 354 It is RECOMMENDED that implementations recognize the MIME 355 multipart/alternative type in SAPv1 announcements, allowing for 356 a simple transition to SDPng. 358 It should be noted that current session directory implementations 359 only support SDP. Nevertheless, using the SAP Message Identifier 360 Hash and the source address, they should be able to perform session 361 deletions and modifications properly -- even without understanding 362 the format contained in the SAP message body. 364 For the introduction of SDPng, session announcements SHOULD be made 365 "bi-lingual", i.e. in SDP and SDPng. If a SAP announcer for some 366 reason knows that all its potential audience will support SDPng, the 367 SDP announcement SHOULD be omitted. 369 It should be noted that, for IPv4-based multicast sessions, session 370 directories still may rely on parsing the session specifications to 371 avoid clashes in the multicast address space. Introducing a new 372 session description language will prevent older implementations from 373 continuing this practice successfully -- assuming that only SDPng 374 announcements are used and/or that old implementations do not support 375 MIME multipart/alternative message bodies. This use of SAP is 376 deprecated, however. 378 4.2. Real-Time Streaming Protocol (RTSP) 380 RTSP uses SDP to provide presentation descriptions (with a 381 presentation comprising one or more media sessions), typically 382 communicated from the server to the client for playback, and in the 383 opposite direction for recording. The presentation description may 384 also include initialization data for the various media streams and 385 URLs to be used for controlling the entire presentation as well as 386 the individual media sessions. Transport parameters -- such as IP 387 addresses, port numbers, etc. -- are conveyed as part of RTSP header 388 fields. 390 RTSP uses the Content-Type: header field to indicate the format of 391 the enclosed entity. This provides a straightforward means for 392 distinguishing SDP and SDPng-based presentation descriptions. In 393 addition, the Accept: header SHOULD be used by the client to indicate 394 which content types it supports. If the client specifies both SDP 395 and SDPng as acceptable, the server SHOULD provide only the SDPng- 396 based presentation description. 398 If the client does not indicate a particular Content-Type: the server 399 can, theoretically, use MIME multipart bodies (e.g. 400 "multipart/alternative") to convey both description types 401 simultaneously. However, it is generally not expected that today's 402 RTSP clients and servers will be able handle multipart bodies. 403 Hence, if no hint is provided by the client by means of the Accept: 404 header, the server MUST provide only an SDP description. 406 In general, it would be preferrable to have the servers migrate to 407 always supporting both description formats, thus enabling the clients 408 to choose. The servers SHOULD indicate SDPng support by means of 409 suitable header fields whenever possible. 411 Finally, RTSP makes special provision to interworking with firewalls 412 by including the crucial transport parameters in a separate RTSP 413 header field _in_addition_ to the presentation description. This 414 practice in principle allows to change the presentation description 415 format without having to worry about the operation of firewalls and 416 similar devices. 418 4.3. Session Initiation Protocol (SIP) 420 The use of SDP with SIP follows the offer/anser model and is 421 described in [6]. It is key to the (efficiency of the) offer/answer 422 model that a complete capability exchange and media stream 423 instantiation be carried out in one round-trip -- which is supported 424 by SDP. While SDPng allows to separate capability exchange from 425 media sesssion instantiation, those two pieces are also easily 426 integrated in a single step. 428 SIP also uses a Content-Type: header to indicate the nature of data 429 carried in its message body; and SIP explicitly calls for supporting 430 MIME multipart message bodies. While, again, the use of MIME 431 multipart/alternative would in principle be possible (from a 432 theoretical perspective), issues regarding the actual implementation 433 of multipart/alternative in SIP entities have been raised. As 434 backward compatibility has to be achieved, a different approach is 435 suggested: 437 A SIP UAC MAY use an SDPng message body in a SIP INVITE (or other) 438 message. If the SIP UAS does not support SDPng, it will return a 439 "415 Unsupported Media Type" response to the UAC and indicate 440 acceptable content types in the Accept: header (probably including 441 "application/sdp"). The SIP UAC MUST then retry INVITE (or other) 442 message using the indicated session description language. The SIP 443 UAC SHOULD cache knowledge about which peers did not understand SDPng 444 as session description formats for a limited amount of time (e.g. 445 several days) so that extra round-trips for session setup are only 446 incurred infrequently. Whenever a peer has sent an SDPng description 447 (or it is known from other means that the peer supports SDPng), this 448 information SHOULD also be cached. 450 The SIP Accept: header can be exploited to determine the capability of 451 a peer to understand SDPng in addition to (or instead of) plain SDP. 452 Methods such as OPTIONS MAY be used to determine a peer's support for 453 SDPng. However, a peer's capabilities may not be known when the 454 first message is sent which may introduce an extra round-trip if 455 including SDP and SDPng in the initial INVITE message is not an 456 option. Further approaches to make a UA's support for SDPng known 457 ahead of time should be explored. 459 A number of SDP extensions have been motivated by SIP-based 460 applications and these need to be accommodated in SDPng as well. 461 Features such as "simcap" and "FID" are inherently supported by 462 SDPng; proper definitions for connection-oriented media need to be 463 fully understood and then incorporated. Key management attributes as 464 defined in [11] need to be included (not just for SIP) and so may 465 need to be general mechanisms to signal security capabilities [11] 466 [15] and indicate their optional or mandatory use. The same applies 467 to quality of service parameters [13] (which are largely also 468 motivated by SIP but are also useful with control protocols). 470 Numerous extensions to SDP have been developed for the purpose of 471 supporting certain SIP requirements -- actually most of those listed 472 in section 1. fall into this category. The following paragraphs 473 address how those are handled by and mapped to SDPng. 475 IPv6 is natively supported by SDPng. For other network protocols -- 476 such as ATM and TDM, which have only come up in the context of 477 MEGACO, see below -- similar SDPng packages need to be defined that 478 provide the same information as the corresponding SDP extensions. 480 Support for connection-oriented media in general will be supported in 481 SDPng using a similar parameterization. Support for SCTP will be 482 equivalent to the approach taken for SDP as the parameters are 483 comparable. 485 SDP's explicit RTCP port number parameter (that helps with NAT 486 traversal) is inherently available in the RTP transport specification 487 of SDPng. 489 Media session identification is also provided by the SDPng spec by 490 means of naming attributes in the potential as well as actual 491 configurations. The "Session Attributes" section of SDPng is meant 492 to provide meta-information about the media sessions such as grouping 493 of lip synchronization, indicating streams semantics, etc. This 494 section is also the place to express media "mixing" attributes as 495 discussed in [14]. QoS parameterizations for SDPng are developed 496 separately as package enhancements and are still under discussion. 498 Simultaneous capabilities are dealt with by the Constraints section 499 of SDPng where restrictions across several components as well as 500 within a single component can be expressed. 502 Security parameters have not yet been developed for the SDPng 503 specification. The intention is to define a separate security 504 package (similar to codec and transport definitions). Security 505 parameters may be provided in the definition section for later 506 reference from within the component specification or may be specified 507 inline in a component. 509 Indicating permissible sources for unicast and particularly multicast 510 media sessions is already covered in the basic SDPng transport 511 specification. 513 In summary, most of the newly developed SDP attributes and their 514 usages have either been considered in the SDPng base specification 515 and the transport packagaes or will be added additional attributes or 516 as separate packages. 518 Note that the above discussions are not just applicable to SIP but 519 may be used in a broader scope (e.g. with RTSP or MEGACO). 521 4.4. Media Gateway Control Protocol (MEGACOP) 523 The MEGACO specification already supports two different encodings for 524 capability and media stream descriptions: a text-based variant based 525 upon (a modified) SDP and a binary representation of the same 526 information set. MGCs are required to implement both encodings while 527 MGs have the choice to pick either or both. Differentiation between 528 the protocol encoding variants is done using different port numbers: 529 2944 for the text-based and 2945 for the binary encoding. 531 Unfortunately, within the text-based encoding, there is no means to 532 differentiate several description formats. SDP messages are carried 533 as an "octet string" without any type identifier. Defining a third 534 port number for this further differentiation does not seem to be 535 appropriate, particularly since the message encoding is still a text 536 format. 538 The remaining means for distinction is that an SDP specification 539 would start with a "v=0" line while an SDPng document would begin 540 with a different character sequence. 542 Note that MEGACOP also supports a binary encoding for SDP 543 messages; current practice seems to favor the text encoding for 544 SDP and hence we will not address a binary encoding for SDPng. 546 Within the context of MEGACO, various extensions to SDP have been 547 defined, addressing its use for capability description and also 548 defining support for further network types (presently, ATM and TDM). 549 Capability descriptions are inherently supported by SDPng. To add 550 support for further networks, the respective parameters need to be 551 defined as network-specific SDNng packages. 553 5. SDPng and Middleboxes 555 Middleboxes (e.g. firewalls, NATs, NAPTs) are of significant 556 importance for many deployment scenarios for SDP-based signaling 557 protocols. The SDP description typically carries addressing 558 paramaters for media sessions which may be invalidated by 559 middleboxes: by firewalls because they block packet destined at the 560 respective addresses and by NA(P)Ts because they change the addresses 561 that must actually be used. 563 A number of approaches have been devised to deal with currently 564 deployed and, eventually, future middleboxes: 1) co-locating a proxy 565 for the respective signaling protocol(s) with a middlebox, 2) using 566 extra protocols to determine the presence and the mode of operation 567 of a NA(P)T (which does not work for firewalls), and 3) the 568 definition of a control protocol for middleboxes. While approach 1) 569 is entirely up to the manufacturers of middleboxes, 2) and 3) are 570 subject to IETF standardization in the MIDCOM WG. 572 1) Proxies that are incorporated in middleboxes to parse and (in 573 case of NATs) possibly alter the contents of session 574 descriptions exchanged in the signaling path will need to 575 implement SDPng in the future. For a (potentially long) interim 576 period, both SDP and SDPng need to be supported by such devices. 578 2) If entities involved in the respective signaling path use MIDCOM 579 protocols (such as STUN) to determine the presence of a NAT and 580 its mode of operation, it is up to these entities to include the 581 correct addressing information in the SDP or SDPng session 582 descriptions. NATs continue to operate as before and do not 583 require any changes because of a migration from SDP to SDPng. 585 3) If local signaling servers or other entities use a MIDCOM 586 protocol to configure a firewall or NAT to allow certain media 587 streams to pass through, again, no changes need to be made to 588 MIDCOM-enabled firewalls. The migration from SDP to SDPng is 589 transparent to them; only the involved signaling component need 590 to support -- but they would need to do so anyway. 592 6. Directing the Evolution of SDP 594 With the transition from SDP to SDPng, there is the question of the 595 evolution of SDP, and legacy systems which use it. 597 The SDP specification [1] is stable, and mostly corrects errors in 598 the original specification, with the addition of very few new 599 features. The revision is expected to be published as a proposed 600 standard RFC shortly, obsoleting RFC 2327. 602 A number of extensions to SDP for use in offer/answer scenarios are 603 also available. These include grouping [4] and capability negotiation 604 [5], which have recently been approved as proposed standard RFCs, 605 bringing minimal capability/alternative descriptions to SDP. 607 Related is the SDP offer/answer model for SDP, published as RFC3264 608 [6]. This defines the model used to complete the steps of a 609 negotiation using SDP. A similar mode of operation will be provided 610 for SDPng for baseline operation with SIP (and possibly RTSP). 612 All these are subsumed into SDPng, so there should be no further need 613 for development in these areas; applications with requirements that 614 are not met by these specifications should use SDPng. 616 There have recently been proposals to add quality of service 617 negotiation for SDP and, similarly, we expect other extensions to be 618 proposed over time. Due to the well-known limitations of SDP, we do 619 not believe it appropriate to continue development of more elaborate 620 extensions: for negotiation, for QoS, for security, and for other 621 general-purpose or application-specific needs. 623 The exceptions to this rule are clearly the addition of security 624 features to SDP (which are required for many current SDP deployment 625 scenarios) as well as minor extensions for media session attributes 626 (e.g. indicating the use of joint vs. separate resource reservations 627 as documented in [17]). 629 Overall, new work should be done in the framework of SDPng where 630 applications and their requirements for (new) expressiveness in end- 631 to-end exchanges to negotiate and configure media sessions will 632 hopefully act as a driver for that process. 634 7. IANA Considerations 636 The transition from SDP to SDPng will require IANA to define new 637 parameter registries, which will be created and populated as SDPng 638 evolves. This memo does not, in itself, require any action by IANA. 640 8. Security Considerations 642 Since SDPng performs largely the same role as SDP+extensions, it is 643 not expected that there will be significant new security 644 considerations as a result of the transition. The security 645 considerations section of [2] provides further details. 647 During the transition process it is likely that dual descriptions 648 will be common. There is a potential for inconsistancy between 649 definitions, which may have unintended consequences if one part of 650 the system, for example a middlebox, interprets the SDP format whilst 651 another interprets the SDPng format definition. 653 9. Author's Addresses 655 Joerg Ott 656 Universitaet Bremen 657 MZH 5180 658 Bibliothekstr. 1 659 D-28359 Bremen 660 Germany 661 tel:+49-421-201-7028 662 sip:jo@tzi.org 664 Colin Perkins 665 USC Information Sciences Institute 666 3811 North Fairfax Drive, Suite 200 667 Arlington, VA 22203 668 USA 669 tel:+1-703-812-3705 671 10. References 673 [1] Mark Handley, Van Jacobson, Colin Perkins, "SDP: Session 674 Description Protocol," Internet Draft draft-ietf-mmusic-sdp- 675 new-11.txt, Work in Progress, November 2002. 677 [2] Dirk Kutscher, Joerg Ott, Carsten Bormann, "Session Description 678 and Capability Negotiation", Internet Draft draft-ietf-mmusic- 679 sdpng-05.txt, Work in Progress, July 2002. 681 For SDP, numerous additional documents need to be taken into account: 683 [3] 3108 R. Kumar and M. Mostafa, "Conventions for the use of the 684 Session Description Protocol (SDP) for ATM Bearer Connections," 685 RFC 3108, May 2001. 687 [4] Gonzalo Camarillo, Jan Holler, Goran AP Eriksson, Henning 688 Schulzrinne, "Grouping of media lines in SDP," RFC 3388, 689 December 2002. 691 [5] Flemming Andreasen, "SDP Simple Capability Declaration," RFC 692 3407, October 2002. 694 [6] Jonathan Rosenberg and Henning Schulzrinne, "An Offer/Answer 695 Model with SDP," RFC 3264, June 2002. 697 [7] Robert Fairlie-Cuninghame, "Guidelines for specifying SCTP- 698 based media transport using SDP," Internet Draft draft-fairlie- 699 mmusic-sdp-sctp-00.txt, Work in Progress, May 2001. 701 [8] David Yon, "Connection-Oriented Media Transport in SDP," 702 Internet Draft draft-ietf-mmusic-sdp-comedia-04.txt, Work in 703 Progress, July 2002. 705 [9] Gonzalo Camarillo and Jonathan Rosenberg, "The Alternative 706 Semantics for the Session Description Protocol Grouping 707 Framework," Internet Draft draft-camarillo-mmusic-alt-00.txt, 708 Work in Progress, February 2003. 710 [10] Christian Huitema, "RTCP attribute in SDP," Internet Draft 711 draft-ietf-mmusic-sdp4nat-02.txt, Work in Progress, February 712 2002. 714 [11] Jari Arkko, Elisabetta Carrarra, Fredrik Lindholm, Mats Naslund, 715 and Karl Norrman, "Key Management Extensions for SDP and 716 RTSP," Internet Draft draft-ietf-mmusic-kmgmt-ext-06.txt, Work 717 in Progress, February 2003. 719 [12] Sean Olson, Gonzalo Camarillo, Adam Roach, "Support for IPv6 in 720 Session Description Protocol (SDP)", RFC 3266, June 2002. 722 [13] G. Camarillo (ed), W. Marshall (ed), J. Rosenberg, "Integration 723 of Resource Management and SIP", Internet Draft draft-ietf-sip- 724 manyfolks-resource-03.txt, Work in Progress, November 2001. 726 [14] G. Camarillo, H. Schulzrinne, and E. Burger, "The source and 727 sink attributes for the Session Description Protocol", Internet 728 Draft draft-camarillo-mmusic-source-sink-00.txt, Work in 729 Progress, September 2002. 731 [15] Mark Baugher, "SDP Security Descriptions for Media Streams", 732 Internet Draft draft-baugher-mmusic-sdpmediasec-00.txt, Work in 733 Progress, September 2002. 735 [16] B. Quinn and R. Finlayson, "SDP Source-Filters", Internet 736 Draft draft-ietf-mmusic-sdp-srcfilter-02.txt, Work in Progress, 737 October 2002. 739 [17] G. Camarillo and A. Monrad, "Mapping of Media Streams to 740 Resource Reservation Flows", Internet Draft draft-ietf-mmusic- 741 reservation-flows-01.txt, Work in Progress, October 2002. 743 11. Full Copyright Statement 745 Copyright (C) The Internet Society (2003). All Rights Reserved. 747 This document and translations of it may be copied and furnished to 748 others, and derivative works that comment on or otherwise explain it 749 or assist in its implmentation may be prepared, copied, published and 750 distributed, in whole or in part, without restriction of any kind, 751 provided that the above copyright notice and this paragraph are 752 included on all such copies and derivative works. However, this 753 document itself may not be modified in any way, such as by removing 754 the copyright notice or references to the Internet Society or other 755 Internet organizations, except as needed for the purpose of 756 developing Internet standards in which case the procedures for 757 copyrights defined in the Internet Standards process must be 758 followed, or as required to translate it into languages other than 759 English. 761 The limited permissions granted above are perpetual and will not be 762 revoked by the Internet Society or its successors or assigns. 764 This document and the information contained herein is provided on an 765 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 766 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 767 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 768 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 769 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.