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