idnits 2.17.1 draft-ietf-mmusic-sdpng-req-01.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 current Internet-Drafts. ** 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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance 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 (April 17, 2001) is 8410 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) == Unused Reference: '3' is defined on line 779, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 782, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 786, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 789, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 798, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 809, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 814, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '3') (Obsoleted by RFC 3551) ** Downref: Normative reference to an Informational RFC: RFC 2703 (ref. '6') ** Obsolete normative reference: RFC 2733 (ref. '7') (Obsoleted by RFC 5109) ** Downref: Normative reference to an Informational RFC: RFC 2354 (ref. '8') -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '11') == Outdated reference: A later version (-05) exists of draft-ietf-avt-rtcp-bw-02 ** Obsolete normative reference: RFC 2445 (ref. '14') (Obsoleted by RFC 5545) ** Obsolete normative reference: RFC 2048 (ref. '15') (Obsoleted by RFC 4288, RFC 4289) == Outdated reference: A later version (-01) exists of draft-levin-sip-for-video-00 -- Possible downref: Normative reference to a draft: ref. '16' Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kutscher 3 Internet-Draft Ott 4 Expires: October 16, 2001 Bormann 5 TZI, Universitaet Bremen 6 Curcio 7 Nokia Mobile Phones 8 April 17, 2001 10 Requirements for Session Description and Capability Negotiation 11 draft-ietf-mmusic-sdpng-req-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the entire list of Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 16, 2001. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This document defines some terminology and lists a set of 40 requirements that are relevant for a framework for session 41 description and endpoint capability negotiation in multiparty 42 multimedia conferencing scenarios. 44 This document is a product of the Multiparty Multimedia Session 45 Control (MMUSIC) working group of the Internet Engineering Task 46 Force. Comments are solicited and should be addressed to the working 47 group's mailing list at confctrl@isi.edu and/or the authors. 49 Document Revision 50 $Revision: 2.1 $ 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . 6 57 4. General Requirements . . . . . . . . . . . . . . . . . . 9 58 4.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . 9 60 4.3 Firewall Friendliness . . . . . . . . . . . . . . . . . 9 61 4.4 Authentication, Authorization, Media Keys . . . . . . . 9 62 4.5 Text encoding . . . . . . . . . . . . . . . . . . . . . 10 63 4.6 Session vs. Media Description . . . . . . . . . . . . . 10 64 4.7 Mapping (of a Subset) to SDP . . . . . . . . . . . . . . 10 65 5. Session Description Requirements . . . . . . . . . . . . 11 66 5.1 Media Description . . . . . . . . . . . . . . . . . . . 11 67 5.1.1 Medium Type . . . . . . . . . . . . . . . . . . . . . . 11 68 5.1.2 Media Stream Packetization . . . . . . . . . . . . . . . 11 69 5.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.1.4 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.1.5 Resource Utilization . . . . . . . . . . . . . . . . . . 12 72 5.1.6 Dependencies . . . . . . . . . . . . . . . . . . . . . . 13 73 5.1.7 Other parameters (media-specific) . . . . . . . . . . . 13 74 5.1.7.1 Media Codec Bit Rates . . . . . . . . . . . . . . . . . 13 75 5.1.7.2 Advanced codec modes . . . . . . . . . . . . . . . . . . 13 76 5.1.8 Naming Hierarchy and/or Scoping . . . . . . . . . . . . 13 77 5.1.9 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.1.10 Registrations of Names . . . . . . . . . . . . . . . . . 14 79 5.1.11 Meta-Information . . . . . . . . . . . . . . . . . . . . 14 80 5.1.11.1 Scheduling . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.1.11.2 Optional Meta-Information Packages . . . . . . . . . . . 15 82 6. Requirements for Capability Description and Negotiation 16 83 6.1 Capability Description . . . . . . . . . . . . . . . . . 16 84 6.2 Capability Constraints . . . . . . . . . . . . . . . . . 16 85 6.3 Processing Rules . . . . . . . . . . . . . . . . . . . . 17 86 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . 19 87 8. Remarks . . . . . . . . . . . . . . . . . . . . . . . . 20 88 References . . . . . . . . . . . . . . . . . . . . . . . 21 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . 22 90 Full Copyright Statement . . . . . . . . . . . . . . . . 24 92 1. Introduction 94 Multiparty multimedia conferencing is one application that requires 95 the dynamic interchange of end system capabilities and the 96 negotiation of a parameter set that is appropriate for all sending 97 and receiving end systems in a conference. For some applications, 98 e.g., for loosely coupled conferences, it may be sufficient to 99 simply have session parameters be fixed by the initiator of a 100 conference. In such a scenario no negotiation is required because 101 only those participants with media tools that support the predefined 102 settings can join a media session and/or a conference. 104 This approach is applicable for conferences that are announced some 105 time ahead of the actual start date of the conference. Potential 106 participants can check the availability of media tools in advance 107 and tools like session directories can configure media tools on 108 startup. This procedure however fails to work for conferences 109 initiated spontaneously like Internet phone calls or ad-hoc 110 multiparty conferences. Fixed settings for parameters like media 111 types, their encoding etc. can easily inhibit the initiation of 112 conferences, for example in situations where a caller insists on a 113 fixed audio encoding that is not available at the callee's end 114 system. 116 To allow for spontaneous conferences, the process of defining a 117 conference's parameter set must therefore be performed either at 118 conference start (for closed conferences) or maybe (potentially) 119 even repeatedly every time a new participant joins an active 120 conference. The latter approach may not be appropriate for every 121 type of conference without applying certain policies: For 122 conferences with TV-broadcast or lecture characteristics (one main 123 active source) it is usually not desired to re-negotiate parameters 124 every time a new participant with an exotic configuration joins 125 because it may inconvenience existing participants or even exclude 126 the main source from media sessions. But conferences with equal 127 "rights" for participants that are open for new participants on the 128 other hand would need a different model of dynamic capability 129 negotiation, for example a telephone call that is extended to a 130 3-parties conference at some time during the session. 132 SDP [1] allows to specify multimedia sessions (i.e. conferences, 133 "session" as used here is not to be confused with "RTP session"!) 134 by providing general information about the session as a whole and 135 specifications for all the media streams (RTP sessions and others) 136 to be used to exchange information within the multimedia session. 138 Currently, media descriptions in SDP are used for two purposes: 140 o to describe session parameters for announcements and invitations 141 (the original purpose of SDP) 143 o to describe the capabilities of a system (and possibly provide a 144 choice between a number of alternatives). Note that SDP was not 145 designed to facilitate this. 147 A distinction between these two "sets of semantics" is only made 148 implicitly. 150 In the following we first introduce a model for session description 151 and capability negotiation and define some terms that are later used 152 to express some requirements. Note that this list of requirements is 153 possibly incomplete. The purpose of this document is to initiate the 154 development of a session description and capability negotiation 155 framework. 157 2. Use Cases 159 This is an initial list of use cases: 161 And endpoint is a device attached to an IP network via a fixed or 162 wireless connection (LAN, WLAN, GPRS, IMT-2000, etc.). 164 Case 1: Point-to-point connection 166 Case 2: Point-to-point connection with use of proxy/CPS 168 Case 3: 1-to-n connection (multicast distribution such as a lecture 169 or video streaming or music) 171 Case 4: n-party connection (such as a speech and/or video and/or 172 data call with a variable number of participants over time) 174 3. Terminology 176 Any (computer) system has, at a time, a number of rather fixed 177 hardware as well as software resources. These resources ultimately 178 define the limitations on what can be captured, displayed, rendered, 179 replayed, etc. with this particular device. We term features enabled 180 and restricted by these resources "system capabilities". 182 Example: System capabilities may include: a limitation of the 183 screen resolution for true color by the graphics board; available 184 audio hardware or software may offer only certain media encodings 185 (e.g. G.711 and G.723.1 but not GSM); and CPU processing power 186 and quality of implementation may constrain the possible video 187 encoding algorithms. 189 In multiparty multimedia conferences, participants employ different 190 "components" in conducting the conference. 192 Example: In lecture multicast conferences one component might be 193 the voice transmission for the lecturer, another the transmission 194 of video pictures showing the lecturer and the third the 195 transmission of presentation material. 197 Depending on system capabilities, user preferences and other 198 technical and political constraints, different configurations can be 199 chosen to accomplish the ``deployment'' of these components. 201 Each component can be characterized at least by (a) its intended use 202 (i.e. the function it shall provide) and (b) a one or more possible 203 ways to realize this function. Each way of realizing a particular 204 function is referred to as a "configuration". 206 Example: A conference component's intended use may be to make 207 transparencies of a presentation visible to the audience on the 208 Mbone. This can be achieved either by a video camera capturing 209 the image and transmitting a video stream via some video tool or 210 by loading a copy of the slides into a distributed electronic 211 whiteboard. For each of these cases, additional parameters may 212 exist, variations of which lead to additional configurations (see 213 below). 215 Two configurations are considered different regardless of whether 216 they employ entirely different mechanisms and protocols (as in the 217 previous example) or they choose the same and differ only in a 218 single parameter. 220 Example: In case of video transmission, a JPEG-based still image 221 protocol may be used, H.261 encoded CIF images could be sent as 222 could H.261 encoded QCIF images. All three cases constitute 223 different configurations. Of course there are many more detailed 224 protocol parameters. 226 Each component's configurations are limited by the participating 227 system's capabilities. In addition, the intended use of a component 228 may constrain the possible configurations further to a subset 229 suitable for the particular component's purpose. 231 Example: In a system for highly interactive audio communication 232 the component responsible for audio may decide not to use the 233 available G.723.1 audio codec to avoid the additional latency but 234 only use G.711. This would be reflected in this component only 235 showing configurations based upon G.711. Still, multiple 236 configurations are possible, e.g. depending on the use of A-law 237 or u-Law, packetization and redundancy parameters, etc. 239 In this system model, we distinguish two types of configurations: 241 o potential configurations 242 (a set of any number of configurations per component) indicating 243 a system's functional capabilities as constrained by the intended 244 use of the various components; 246 o actual configurations 247 (exactly one per instance of a component) reflecting the mode of 248 operation of this component's particular instantiation. 250 Example: The potential configuration of the aforementioned video 251 component may indicate support for JPEG, H.261/CIF, and 252 H.261/QCIF. A particular instantiation for a video conference may 253 use the actual configuration of H.261/CIF for exchanging video 254 streams. 256 In summary, the key terms of this model are: 258 o A multimedia session (streaming or conference) consists of one or 259 more conference components for multimedia "interaction". 261 o A component describes a particular type of interaction (e.g. 262 audio conversation, slide presentation) that can be realized by 263 means of different applications (possibly using different 264 protocols). 266 o A configuration is a set of parameters that are required to 267 implement a certain variation (realization) of a certain 268 component. There are actual and potential configurations. 270 * Potential configurations describe possible configurations that 271 are supported by an end system. 273 * An actual configuration is an "instantiation" of one of the 274 potential configurations, i.e. a decision how to realize a 275 certain component. 277 In less abstract words, potential configurations describe what a 278 system can do ("capabilities") and actual configurations describe 279 how a system is configured to operate at a certain point in time 280 (media stream spec). 282 To decide on a certain actual configuration, a negotiation process 283 needs to take place between the involved peers: 285 1. to determine which potential configuration(s) they have in 286 common, and 288 2. to select one of this shared set of common potential 289 configurations to be used for information exchange (e.g. based 290 upon preferences, external constraints, etc.). 292 In SAP [11] based session announcements on the Mbone, for which SDP 293 was originally developed, the negotiation procedure is non-existent. 294 Instead, the announcement contains the media stream description sent 295 out (i.e. the actual configurations) which implicitly describe what 296 a receiver must understand to participate. 298 In point-to-point scenarios, the negotiation procedure is typically 299 carried out implicitly: each party informs the other about what it 300 can receive and the respective sender chooses from this set a 301 configuration that it can transmit. 303 Capability negotiation must not only work for 2-party conferences 304 but is also required for multi-party conferences. Especially for the 305 latter case it is required that the process of determining the 306 subset of allowable potential configurations is deterministic to 307 reduce the number of required round trips before a session can be 308 established. 310 In the following, we elaborate on requirements for an SDPng 311 specification, subdivided into general requirements and requirements 312 for session descriptions, potential and actual configurations as 313 well as negotiation rules. 315 4. General Requirements 317 Note that the order in which these requirements are presented does 318 not imply their relative importance. 320 4.1 Simplicity 322 The SDPng syntax shall be simple to parse and the protocol rules 323 shall be easy to implement. 325 4.2 Extensibility 327 SDPng shall be extensible in a backward compatible fashion. 328 Extensions should be doable without modifying the SDPng 329 specification itself. The spec should preclude two independent 330 extensions from clashing with each other (e.g. in the naming of 331 attributes). 333 Along with extensibility comes the requirement to identify certain 334 extensions as mandatory in a given context while others as optional. 336 It should be possible to define subsets or profiles of the SDPng so 337 that simple implementations understands only minimal parts of SDPng, 338 and are able to interwork with more refined and complex SDPng 339 implementations. 341 4.3 Firewall Friendliness 343 It should be theoretically possible for firewalls (and other network 344 infrastructure elements) to process announcements etc. that contain 345 SDPng content. The concrete procedures have to be defined but if 346 possible the processing of the SDPng content should be doable 347 without interpretation of the textual descriptions. 349 In general, there should not be any problem for a gateway or a proxy 350 server to execute the capability computation, and this operation has 351 not to be limited to the endpoints only. 353 4.4 Authentication, Authorization, Media Keys 355 SDPng should allow independent security attributes for parts of a 356 session description. In particular, signing and/or encrypting parts 357 of a session description should be supported. 359 The originator of the session may authenticate the session 360 description or parts of it, or encrypt it so that only authorized 361 users may access it. 363 In addition to the media encryption keys, the session description 364 should include also authentication keys, or include ways for 365 authorized session participants to derive these keys. 367 In order to support rapid re-keying, the session description should 368 include way to specify multiple encryption contexts and indicate how 369 and when these encryption contexts will be used. For instance, the 370 session description would indicate the current key and destination 371 group, and then that the key will be changed at 20010401Z084000, and 372 the media encoded with the new key will be sent to group 373 243.243.12.8. 375 4.5 Text encoding 377 A concise text representation is desirable in order to enhance 378 portability and allow for simple implementations. At run time, size 379 of encoded packets should be minimized, processing as well. 381 A language that allows specifications to be formally validated is 382 desirable. 384 4.6 Session vs. Media Description 386 In many application scenarios (particularly with SIP and 387 MEGACO/H.248), only media descriptions are needed and there is no 388 need for session description parameters. SDPng should make parameter 389 sets optional where it is conceivable that not all application will 390 need them. 392 4.7 Mapping (of a Subset) to SDP 394 It shall be possible to translate a subset of SDPng into standard 395 SDP session description to enable a certain minimal degree of 396 interoperability between SDP-based and SDPng-based systems. However, 397 as SDPng will provide enhanced functionality compared to SDP, a full 398 mapping to SDP is not possible. 400 Note: Backwards compatibility to the SDP syntax has been discussed 401 and it was found that this is not goal for SDPng, as it is felt that 402 RFC 2327 is too limiting. 404 Since several flavors of SDP have been developed (e.g., the MEGACO 405 WG uses certain non-SDP enhancements) it needs to be discussed which 406 of these flavors need to be considered for some kind of mapping. 408 5. Session Description Requirements 410 For now, we only consider requirements for media (stream) 411 descriptions. 413 5.1 Media Description 415 It must be possible to express the following information with SDPng: 417 5.1.1 Medium Type 419 Payload types and format parameters for audio and video are 420 well-defined and the basic semantics are clear (as defined in 421 RFC1889 [2] and RFC2327 [1]). 423 Format descriptions for text and whiteboard are currently only 424 defined in the context of specific applications, this is probably 425 going to change in the future (not an SDPng work item). 427 Non-standard (in terms of defined as a non-standard payload type) 428 codecs and format parameters can be accomplished by using dynamic 429 payload type mappings. This is a crucial feature of SDP that needs 430 to be preserved for RTP applications. 432 Current SDP only provides a= (a=fmtp) as means to specify codec 433 parameters but actually gives little support on how to do this. 434 Schemes for expressing more sophisticated parameters (e.g. 435 supporting nesting) may be necessary. Nevertheless, it is imperative 436 to keep the overall structure of a codec description manageable. 438 Note that there is a conflict between the desire to be able to use 439 any old SDP and translate it in SDPng and the desire to have a 440 useful structure in the SDPng data. 442 5.1.2 Media Stream Packetization 444 SDPng needs to be able to take care of more sophisticated payload 445 descriptions than simple payload type assignment. Audio/video 446 redundancy coding schemes need to be supported as need other 447 mechanisms for FEC (RFC 2733 [7]) and media stream repair (RFC 2354 448 [8]). Also, layered coding schemes need to be supported. 450 Finally, a separation of the media encoding scheme, the 451 packetization format, and possible repair schemes (and their 452 respective parameters) is required. 454 5.1.3 Transport 456 Since session descriptions are not only used to describe sessions 457 that use IPv4/RTP for media transport it must be possible to specify 458 different transport protocols (and their corresponding mandatory 459 parameters). This means SDPng must support different address formats 460 (IPv4, IPv6, E.164, NSAP, ...), multiplexing schemes (e.g. to 461 identify a channel on a TDM link), and different transport protocol 462 stacks (RTP/UDP/IP, RTP/AAL5/ATM, ...). Potential further parameters 463 and interdependencies for multiplexed transports should be 464 considered. 466 Additionally the requirement for expressing multiple addresses per 467 actual configuration (layered coding support) has emerged, as well 468 as the requirement for expressing multiple addresses per potential 469 configuration (one port per payload type to simplify processing at 470 the receiver). See also Section 6.1 for a requirement to separate 471 alternative configurations and simultaneous media sessions. 473 In multi-unicast-scenarios it must be possible to specify more than 474 one transport address for a single media stream in an actual 475 configuration, i.e. by specifying address lists. 477 In "broadcast"- or "lecture"-like sessions source filters might be 478 needed that allow receivers to verify the source and apply filters 479 in multicast sessions. Similarly, for SSM, the transport address 480 includes an (Sender,Group) pair of IP addresses. 482 The definition of codecs and the definitions of transport parameters 483 should be strictly separated from each other. See also Section 484 5.1.9. 486 5.1.4 QoS 488 QoS-Parameters for different protocol domains (e.g. traffic 489 specification and flow specification or TOS bits for IP QoS) need to 490 be specified. draft-ietf-mmusic-sdp-qos-00.txt [10] has provided a 491 proposal for a syntax that can be used with SDP to describe network 492 and security preconditions that have to be met in order to establish 493 a session. 495 5.1.5 Resource Utilization 497 Capability descriptions should not be based on available resources 498 and resource requirements (in terms of CPU cycles, DSPs, etc.) for 499 the following reasons: 501 o Device manufacturers might not like to let hardware information 502 go out from their devices. 504 o The resource utilization function is not bijective since, for 505 example, to support a certain media, a device A could require a 506 quantity X of resources, while another device B of a different 507 manufacturer could require a quantity Y of resource, where X <> 508 Y. This is an implementation dependent issue, and it is related 509 with how efficiently/inefficiently a manufacturer is able to 510 implement a feature in its device. 512 5.1.6 Dependencies 514 Certain codes may depend on other resources being available (e.g. a 515 G.723.1 audio codec may need a DTMF codec as well while a G.711 516 codec does not). Such interdependencies need to be expressed. 518 5.1.7 Other parameters (media-specific) 520 Extension mechanisms that allow to describe arbitrary other 521 parameters of media codecs and formats are mandatory. It is possibly 522 required to distinguish between mandatory and optional extension 523 parameters. 525 In particular, it must be possible to introduce new (optional) 526 parameters for a payload format and have old implementations still 527 parse the parameters correctly. 529 Some audio/video specific parameters can be defined as suggested in 530 [16]. 532 5.1.7.1 Media Codec Bit Rates 534 There should be the possibility to configure ranges of bit rates 535 (for example 32-64 kbps) or a discrete set of rates (i.e. 24, 32, 536 48, 64, 128, ... kbps). This is to allow an efficient resource 537 allocation and allow as well interworking with systems where only a 538 number of discrete bit rates is available. Resource reservation and 539 QoS configuration mechanisms in general should available as optional 540 packages (see Section 5.1.4). It is conceivable that there be a 541 separation into generic and transport specific QoS packages. 543 5.1.7.2 Advanced codec modes 545 Special advanced codec modes may be announced depending, for 546 example, on the network conditions, to activate special settings in 547 order to preserve good quality of media and to reduce the 548 probability of call dropping. 550 5.1.8 Naming Hierarchy and/or Scoping 552 Parameter names should be constructed in a way to avoid clashes and 553 thereby simplify independent development of e.g. codec parameter 554 descriptions in different groups. 556 5.1.9 Profiles 558 The configuration options for the different aspects of session 559 descriptions (codec definitions, transport parameters etc.) should 560 be defined in different orthogonal profiles ("packages"). Two 561 different types of profiles are required: 563 o A profile can define the data structures and collapsing rules for 564 a specific function, e.g., for transport parameters. Capability 565 and session descriptions can refer to such a profile and define 566 concrete values for the profile parameters. 568 o Instantiations of such profiles, that already contain concrete 569 parameters, say for specific codec definitions, can be referenced 570 by capability and session descriptions in order to allow for 571 combining different aspects to a final description that is 572 synthetic and of lower computational complexity. 574 An open issue is the question whether profiles should be referenced 575 by name, i.e., by creating a well-known registry, or whether 576 profiles should be referenced by address, i.e., by creating the 577 possibility to retrieve them on demand. It is conceivable that a 578 combination of both is useful: Some basic definitions are registered 579 and well known and some other, uncommon definitions can be 580 referenced by URIs. 582 5.1.10 Registrations of Names 584 SDP uses top-level MIME content types [15] for media names. These 585 convention should be adopted in order to avoid the unneccessary 586 creation of a new namespace. 588 SDP also defines a registration procedure that allows to register 589 new names for "media", "proto", "fmt", "bwtype", "nettype", or 590 "addrtype" field names (defined in [1]). If possible, the names that 591 are already defined should be re-used. The definition of SDPng 592 should contain a specification that states the registration 593 procedures for SDPng. 595 5.1.11 Meta-Information 597 5.1.11.1 Scheduling 599 In order to be usable for conference announcements, e.g. by means of 600 SAP [11] it also required to provide a means for expressing 601 scheduling information, i.e. to express the date (or the recurring 602 dates) when a conference is taking place. 604 Two alternatives for implementing scheduling functions are 605 conceivable: 607 o SDP-style (using the SDP model that is implemented as t= and r= 608 lines); and 610 o Using ICalender [14]. 612 5.1.11.2 Optional Meta-Information Packages 614 Location Meta-Information: In case of usage of SAP [11] as content 615 or channel directory, the session description should include the 616 location information, including physical location and the L1/L2 617 addressing information required to access the session. L1/L2 618 info may include things like transmission media used, 619 frequencies, L2 multiplexing information etc. This makes it 620 possible to broadcast session descriptions sent using broadband 621 radio on, e.g., narrowband radio network. The recipients can 622 derive their location from the location sent in the SAP session 623 description, and then decide if and how they can receive the 624 media sessions. 626 Pricing Information: The session description need to specify the 627 pricing information for the session, if participating in the 628 session requires payment. 630 6. Requirements for Capability Description and Negotiation 632 6.1 Capability Description 634 When describing the capabilities of endsystem by providing a list of 635 different potential configurations, it must be possible to 636 distinguish alternatives (different potential configuration) from 637 different simlutaneous sessions of a conference. A clear separation 638 of these two concepts must be made that should also be realized in 639 the description language. 641 6.2 Capability Constraints 643 Capability negotiation is used to gain a session description (an 644 actual configuration) that is compatible with the different end 645 system capabilities and user preferences of the potential 646 participants of a conference. 648 A media capability description is the same as a potential 649 configuration, as it contains a set of allowable configurations for 650 different components that could be used to implement the 651 corresponding component. A capability description should allow 652 specifying a number of interdependencies among capabilities. 653 Traditional SDP only supports alternative capabilities and the 654 specification implicitly assumed that all capabilities could be 655 combined and basically used at the same time (looking at the pure 656 session description, at least). 658 Processing power, hardware, link, or other resources may preclude 659 the simultaneous use of certain configurations and/or limit the 660 number of simultaneous instantiations of one or more configurations. 661 This has led to a need to express in more detail constraints on 662 combinations of configurations including the following constraints: 664 o grouping capabilities (-> capability set); 666 o expressing simultaneous capability sets; 668 o expressing alternative capability sets; and 670 o constraining the number of uses of a certain capability (set). 672 It needs to be carefully investigated how much more sophistication 673 (if any) than simply listing alternatives needs to go into a base 674 specification of SDPng (and which extension mechanisms for certain 675 applications or for future revisions should be allowed). 677 Examples are known where complex capability descriptions are 678 available but are simply not used (at least not at the level of 679 sophistication that would be possible). This strongly calls for 680 keeping requirements on capability constraints rather modest (KISS). 682 The description of capabilities and the specification of capacity 683 limits (maximum numbers of instantiations at a time) should be 684 separated. This allows for greater modularity, since the common 685 descriptions of capabilities can be referenced and imported, while 686 the constraints (that are usually unique for a specific endsystem) 687 can be provided inline and can be applied across singe capability 688 definitions. In order to allow for simple basic implementations, 689 this also allows to treat the constraints as optional sections that 690 do not have to be processed by an implementations. 692 The capabilities should be expressed as limitations on codec 693 support, transport capability restrictions but not implicitely as 694 limitations on machine resources, such as CPU type, clock rates, 695 memory etc., that describe internal limitations in order to infer 696 the supported capabilities. 698 6.3 Processing Rules 700 The processing of potential configurations includes the process of 701 "collapsing" sets of potential configurations offered by 702 participants, i.e. the computation of the intersection of these 703 potential configurations. 705 The processing (i.e. collapsing, forwarding etc.) of different 706 potential configurations in order to find a compatible subset must 707 work without having to know the semantics of the individual 708 parameters. This is a key requirement for extensibility. Endsystems, 709 conference bridges, proxies and gateways are thus only required to 710 understand the basic SDPng semantics of session and capability 711 description in order to compute the supported subset of capablities 712 for a conference. 714 Additionally it must be possible to make use of different 715 negotiation policies in order to reflect different conference types. 716 For example in a lecture-style conference the policy might be to 717 ensure that a capability collapsing process does not yield an actual 718 configuration that excludes the main source (i.e. the lecturer and 719 her end system) from the conference. 721 Preferences may also be considered in the negotiation process. This 722 may need to be considered at the SDPng level (e.g. to express 723 preferences, priorities). 725 Of course, the negotiation of configurations must not only work in 726 peer-to-peer-conference scenarios but also be usable in multi party 727 scenarios. The collapsing rules should work commutatively and 728 associatively, that means if given 3 end systems A,B,C the result 729 for computing the supported configurations should be same when 730 computing (A*B)*C and (B*C)*A (let "*" be the collapsing function). 732 Negotiation of capabilities should take no longer than two or three 733 message exchanges. The description format must enable such 734 efficiency. 736 In order to allow for concise capability specification it will 737 probably be required to group descriptions of, say, codecs and to 738 establish a kind of hierarchy that allows to attach a certain 739 attribute or parameter to a whole group of codecs. 741 It might then also be required to have a naming scheme that allows 742 to name definitions in order to be able to later reference them in 743 subsequent definitions. This is useful in situations where some 744 definition extends a previous definition by just one parameter or in 745 situations where codecs are combined, for example for expressing 746 redundancy or layered codings. Different models of re-use are 747 conceivable. 749 7. Open Issues 751 This section contains a list of items that need further work and/or 752 discussion: 754 It needs to distinguished more precisely between mandatory baseline 755 functionality and optional extensions. 757 8. Remarks 759 Explicitly addressing the issue of capability negotiation when 760 drafting the new session description language generates new sets of 761 requirements, some of which might conflict with other important 762 goals, such as simplicity, conciseness and SDP-compatibility. 764 However, we think that it's worthwhile to sketch a reasonably 765 complete and powerful solution first and then later develop a 766 migration path from today's technology instead of imposing 767 limitations at the outset to minimize the possibly necessary 768 changes. 770 References 772 [1] Handley, M. and V. Jacobsen, "SDP: Session Description 773 Protocol", RFC 2327, April 1998. 775 [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, 776 "RTP: A Transport Protocol for Real-Time Applications", RFC 777 1889, January 1996. 779 [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 780 with Minimal Control", RFC 1890, January 1996. 782 [4] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, 783 M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP 784 Payload for Redundant Audio Data", RFC 2198, September 1997. 786 [5] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 787 2533, March 1999. 789 [6] Klyne, G., "Protocol-independent Content Negotiation 790 Framework", RFC 2703, September 1999. 792 [7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for 793 Generic Forward Error Correction", RFC 2733, December 1999. 795 [8] Perkins, C. and O. Hodson, "Options for Repair of Streaming 796 Media", RFC 2354, June 1998. 798 [9] Camarillo, G., Holler, J. and G. AP Eriksson, "SDP media 799 alignment in SIP", Internet Draft 800 draft-camarillo-sip-sdp-01.txt, November 2000. 802 [10] Rosenberg, J., Schulzrinne, H. and S. Donovan, "Establishing 803 QoS and Security Preconditions for SDP Sessions", Internet 804 Draft draft-ietf-mmusic-sdp-qos-00.txt, June 1999. 806 [11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 807 Protocol", RFC 2974, October 2000. 809 [12] Kumar, R. and M. Mostafa, "Conventions for the use of the 810 Session Description Protocol (SDP) for ATM Bearer 811 Connections", Internet Draft draft-ietf-mmusic-sdp-atm-05.txt, 812 February 2001. 814 [13] Casner, S., "SDP Bandwidth Modifiers for RTCP Bandwidth", 815 Internet Draft draft-ietf-avt-rtcp-bw-02.txt, November 2000. 817 [14] Dawson, F., Stenerson, D., MISSING ORGANIZATION and , 818 "Internet Calendaring and Scheduling Core Object Specification 819 (iCalendar)", RFC 2445, November 1998. 821 [15] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 822 Mail Extensions (MIME) Part Four: Registration Procedures", 823 BCP 13, RFC 2048, November 1996. 825 [16] Levin, O., "SIP Requirements for support of Multimedia and 826 Video", Internet Draft draft-levin-sip-for-video-00.txt, 827 February 2001. 829 Authors' Addresses 831 Dirk Kutscher 832 TZI, Universitaet Bremen 833 Bibliothekstr. 1 834 Bremen 28359 835 Germany 837 Phone: +49.421.218-7595 838 Fax: +49.421.218-7000 839 EMail: dku@tzi.org 841 Joerg Ott 842 TZI, Universitaet Bremen 843 Bibliothekstr. 1 844 Bremen 28359 845 Germany 847 Phone: +49.421.201-7028 848 Fax: +49.421.218-7000 849 EMail: jo@tzi.org 851 Carsten Bormann 852 TZI, Universitaet Bremen 853 Bibliothekstr. 1 854 Bremen 28359 855 Germany 857 Phone: +49.421.218-7024 858 Fax: +49.421.218-7000 859 EMail: cabo@tzi.org 860 Igor Curcio 861 Nokia Mobile Phones 862 P.O. Box 83 (Visiokatu 1) 863 33721 Tampere 864 Finland 866 Phone: +358.3.272.5372 867 Fax: +358.10.505.7662 868 EMail: igor.curcio@nokia.com 870 Full Copyright Statement 872 Copyright (C) The Internet Society (2001). All Rights Reserved. 874 This document and translations of it may be copied and furnished to 875 others, and derivative works that comment on or otherwise explain it 876 or assist in its implmentation may be prepared, copied, published 877 and distributed, in whole or in part, without restriction of any 878 kind, provided that the above copyright notice and this paragraph 879 are included on all such copies and derivative works. However, this 880 document itself may not be modified in any way, such as by removing 881 the copyright notice or references to the Internet Society or other 882 Internet organizations, except as needed for the purpose of 883 developing Internet standards in which case the procedures for 884 copyrights defined in the Internet Standards process must be 885 followed, or as required to translate it into languages other than 886 English. 888 The limited permissions granted above are perpetual and will not be 889 revoked by the Internet Society or its successors or assigns. 891 This document and the information contained herein is provided on an 892 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 893 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 894 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 895 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 896 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 898 Acknowledgement 900 Funding for the RFC editor function is currently provided by the 901 Internet Society.