idnits 2.17.1 draft-peterson-sipcore-advprop-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4786 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: 'RFC2026' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC3325' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC3863' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC3968' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC5111' is defined on line 461, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar, Inc. 4 Intended status: Standards Track C. Jennings 5 Expires: September 15, 2011 Cisco Systems 6 March 14, 2011 8 The Advertisement/Proposal Model of Session Description 9 draft-peterson-sipcore-advprop-01 11 Abstract 13 In common SIP practice, a two-phase "offer/answer" exchange of 14 session description documents negotiates preferences, capabilities 15 and requested sessions. However, the structure of the session 16 description greatly confuses the disambiguation of these elements and 17 thus the clear characterization of sessions. The current work 18 proposes an alternative to the offer/answer model which leverages 19 pre-association between user agents to recast those two phases into a 20 less ambiguous form: an Advertisement of capabilities and preferences 21 which occurs in non-real-time before a session is ever requested, 22 which is followed during session establishment by a unidirectional 23 and complete Proposal of a session. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 15, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Limitations of the offer/answer model . . . . . . . . . . . . 5 74 4. Overview of the Advertisement/Proposal Model . . . . . . . . . 6 75 5. Benefits of the Advertisement/Proposal Model . . . . . . . . . 8 76 6. The Advertisement . . . . . . . . . . . . . . . . . . . . . . 9 77 7. The Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 11. Informative References . . . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Terminology 86 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 87 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 88 This document additionally uses [RFC5226] language to describe IANA 89 registrations. The terms "watcher" and "presentity" and related 90 presence terms are defined in RFC2778. 92 2. Introduction 94 The Session Description Protocol (SDP) [RFC4566] enjoys widespread 95 use in the Internet for the description of sessions established by 96 protocols such as the Session Initiation Protocol (SIP) [RFC3261]. 97 Most uses of SDP assume an offer/answer model as described in 98 [RFC3264] for interactive session establishment, where one side sends 99 an offer and the other side replies with an answer. However, many 100 important matters relating to the management of media streams in SDP 101 are inherently ambiguous in the offer/answer model. In particular, 102 distinguishing the expression of capabilities from preferences from 103 actual desired media streams has proven extremely difficult for more 104 advanced applications of SDP. Moreover, as the offer and answer 105 reflect only the media sinks of their respective creators, neither 106 offers a complete picture of the session, and the degree to which the 107 answer qualifies the offer admits of similar crippling ambiguities. 108 These core difficulties have motivated numerous proposals to reform 109 SDP, most of which radically increase its syntactical complexity, and 110 thus have found mixed acceptance in the deployment community. 112 Perhaps the root of these problems lies not in SDP itself, however, 113 but in application of SDP to the offer/answer model. SDP 114 significantly predates the codification of the offer/answer model, 115 and while RFC3264 added a great deal of value by formalizing the 116 previously tacit principles of using SDP in SIP, nonetheless those 117 principles themselves have intrinsic limitations. 119 This document therefore proposes a reexamination of the fundamental 120 requirements underlying the use of SDP in session-establishment 121 protocols such as SIP. It recognizes, first of all, the desirability 122 of conveying in a SIP INVITE message a document that describes the 123 proposed session completely, hereafter a Proposal. In order to 124 formulate such a Proposal, however, the originator of a session must 125 have access to the capabilities and preferences of the target. Thus, 126 in an alternative model entities willing to receive a Proposal might 127 promulgate Advertisements to would-be proposers. Advertisements 128 contain all of the information about the advertiser required by 129 proposers to formulate a Proposal, including details such as the IP 130 address and port where they hope to receive media. One way that 131 advertisements might deliver Advertisement to proposers is through 132 presence. 134 Several previous efforts have recognized the need to provide 135 capability and preference information prior to commencing the session 136 establishment process. Notably, the work on expressing user agent 137 capability within presence information [RFC5196] (which in turn 138 builds upon the user agent capabilities work in [RFC3840]) provides 139 one possible framework in which, with some enhancements, an 140 Advertisement might be articulated. Work has also been done in 141 [RFC3407] to express capability information with less ambiguity in 142 SDP; by going down that path, an Advertisement might even be rendered 143 in SDP. Rendering a Proposal in SDP would probably return that 144 format to something like its original purpose. This document, 145 however, proposes no specific syntactical format for Advertisements 146 or Proposals - it merely describes the semantics of these objects as 147 a set of requirements that future format proposals could meet. 149 While the work in this document is most immediately relevant to SIP, 150 and discusses its applicability to SIP throughout, the underlying 151 model may have further applicability to other protocol using session 152 descriptions in a similar manner. 154 3. Limitations of the offer/answer model 156 There are several limitations of the offer/answer model that cause 157 issues with the operation of SIP. Many have been the target of prior 158 work intended to repair the problem by adding additional syntactical 159 structure to SDP. However, these problems arise from the semantics 160 of SDP in the offer/answer context - not only because an offer 161 represents an incomplete picture of the session, and at that a 162 picture filled with conditional elements, but because an answer does 163 not describe a session completely either. 165 In the traditional offer/answer model, in order to maximize the 166 chances of the negotiation process arriving at an acceptable session, 167 an offerer must propose the largest set of session features possible. 168 This includes the various combinations of RTP profiles, transport 169 addresses, security properties and so forth that would be acceptable 170 to the offerer. Disambiguating the semantics of these features - 171 distinguishing, for example, the session features the offerer would 172 like to invoke concurrently as opposed to those offered as 173 alternatives - has required the additional of significant complexity 174 to SDP. Because SDP's underlying syntax is not designed to carry 175 structured or hierarchical data, the resulting documents can be large 176 and confusing. Indeed, the term "offer" no longer seems to fit what 177 that sort of document describes - it is a menu rather than a 178 selection. The resulting negotiation process, in which an answerer 179 evaluates the alternatives described in the offer and arrives at a 180 response, has become complex enough to call into question the wisdom 181 of executing it in real-time, such as during the alerting phase of a 182 telephone call. 184 Architecturally, an offerer moreover cannot anticipate what entity, 185 or entities, their offer will reach, due to the potential in SIP for 186 retargeting and/or forking. The fact that an answer typically 187 arrives in a message confirming session establishment (the 200 OK), 188 yet that it can originate from a surprising source, and make 189 surprising stipulations, is a weakness in offer/answer. The offer/ 190 answer model places all of the onus, and the authority, on the 191 answerer to complete a session within the very broad constraints that 192 can be specified by the offerer. It is unclear why this power is 193 better invested in the answerer than the offerer, but ideally, 194 whichever side develops a finalizes proposal for the session should 195 pass it to the other for approval, rather than assuming it will be 196 acceptable and turning on the session. That somewhat philosophical 197 point is not purely theoretical - it is one of the major drivers for 198 classic problems in SIP such as early media, where due to forking 199 several answerers may unknowingly operate on the same offer at once. 201 The fact that neither an offer nor an answer alone contains a 202 complete picture of the session also compels intermediaries 203 interested in SDP, for example application-layer gateways assisting 204 with NAT traversal, to hear and modify, potentially, both requests 205 and responses (e.g. a 200 carrying SDP) during session establishment. 206 Unlike requests, responses cannot be rejected at the SIP layer, for 207 security reasons or any other reasons, which effectively prevents 208 endpoints from cleanly negotiating away from any unwanted 209 "suggestions" made by intermediaries. 211 Some of this problem space in SDP is addressed by ongoing work of the 212 MMUSIC working group on capability negotiation in SDP. The 213 Advertisement/Proposal model differs from the capneg work in so far 214 as capneg retains the offer/answer model and provides sufficient 215 syntactical equipment in SDP to differentiate the various functions 216 of expressing capability, proposing the properties of a session and 217 confirming those proposals. However, despite their differences the 218 approaches here and in are not mutually exclusive; in order to 219 express Advertisements or Proposals in SDP, something very much like 220 the attributes defined in the capneg work is required. 222 4. Overview of the Advertisement/Proposal Model 224 An Advertisement is a document detailing the parameters of sessions 225 that a user is willing to accept. A user agent who aspires to 226 initiate a session uses an Advertisement as the basis for a Proposal, 227 a complete description of a session, by selecting a common set of 228 desired capabilities from the Advertisement. This Proposal is then 229 carried in a session initiation message such as an INVITE whose 230 recipient will either accept or reject it in its entirety. A 231 recipient who rejects a proposal may search for an Advertisement from 232 the proposer, and in turn make their own Proposal based on it; this 233 counter-Proposal has no necessary relationship with the rejected 234 Proposal. Unlike the offer/answer model, in the Advertisement/ 235 Proposal model a Proposal is a complete description of a session - it 236 does not specify preferences or capabilities, instead it proposes the 237 media types, sources and sinks that shall be used by both endpoints 238 in a session. 240 Advertisements incorporate the session-related capabilities of the 241 user agent(s) they describe, as modified by user policy. A user 242 agent may elect to share a customized Advertisement with a would-be 243 proposer, and thus depending on the proposer, user policy may dictate 244 an Advertisement offer different media types or what have. 245 Advertisements may contain various proposer-specific information that 246 is of use to endpoints prior to setting up a session, including 247 information used in connectivity checks or keying media-layer 248 security. 250 Promulgating Advertisements requires some administrative pre- 251 association between user agents as well as a means of requesting and 252 transmitting the Advertisement itself outside context of a session. 253 The existing availability of presence in many systems that establish 254 multimedia sessions permits the sharing of capability and preference 255 expression, as per the work in RFC5196. Presence establishes a 256 channel for communicating availability or capability information 257 between presence user agents which can also share additional 258 information relevant to a later stage of session establishment. Many 259 presence systems moreover have the capability to supply customized 260 presence data to particular watchers, a desirable quality for the 261 Advertisement/Proposal model. An Advertisement may be shared as a 262 component of an existing presence document, including a Presence 263 Information Data Format (PIDF) document, or any other presence 264 format. Note that the use of presence does not necessarily entail 265 the maintenance of long-term subscriptions, and might rely in some 266 cases on fetch operations conducted immediately prior to session 267 initiation. 269 The Session Description Protocol provides numerous other expressions 270 of capability (for example, the language of speakers in audio 271 sessions) which are not considered here as requirements for 272 adaptation to the Advertisement/Proposal model, though they may be 273 incorporated into applications if desired. 275 5. Benefits of the Advertisement/Proposal Model 277 In addition to addressing some existing problems in common SIP 278 deployments, the use of the advertisement/proposal model also creates 279 opportunities for new features. Most of these new features rely on 280 the availability of the Advertisement prior to the time of session 281 establishment, which allows user agents or applications to consider 282 or act upon this information, in non-real-time. 284 The simplest application of this model is to allow the proposer the 285 opportunity to browse the capabilities of an advertiser prior to 286 making a session initiation attempt. In the traditional offer/answer 287 model, the user must express any preferences to his user agent prior 288 to attempting to initiate a session, and only when the INVITE is 289 received, and one is on the proverbial clock, does the answerer begin 290 the process of determining how the offerer's capabilities and 291 preferences match to its own. While some potential methods in SIP of 292 providing this "browsing" user experience prior to initiating a 293 session have already been specified, as detailed above, those methods 294 might turn out to be either partially redundant with the negotiation 295 of the offer/answer phase or even contradictory to it - the 296 Advertisement/Proposal model makes this user experience part and 297 parcel of the session initiation process. 299 Another example is the use of an Advertisement to predict whether or 300 not connectivity will be possible behind endpoints. Due to various 301 network-layer obstacles (include NATs or firewalls), one SIP user 302 agent may not be capable of forming a media session with another 303 endpoint, despite their ability to rendez-vous successfully at the 304 SIP layer. In an Advertisement, a user agent might express enough 305 information to allow a would-be proposer to perform ICE-style checks 306 prior to initiating a session, and thus to learn whether or not a 307 potential target would be reachable. This information could be 308 rendered to the proposer's user as a sort of presence information, 309 for example ("red" signifying a media session cannot be formed with 310 the target, "green" suggesting that it could). This is just one 311 example of a whole class of information useful during session 312 establishment that could be shared during the Advertisement phase - 313 encryption keys for the bodies of SIP requests are another bit of 314 information that might be difficult to acquire otherwise. 316 Advertisements are also useful in bunches. For a case where a third- 317 party call control system is attempting to figure out how two or more 318 parties could share some sort of common session, acquiring 319 Advertisements from all parties ahead of time greatly facilitates the 320 process of assembling Proposals that would be acceptable to the 321 group. Conducting this process during session establishment itself 322 (by inviting each party serially to a session, for example) could 323 yield far less optimal results. 325 Any application that consumes Advertisement data prior to session 326 establishment in order to make predictions about the session faces a 327 trade-off resulting from the potential for that data to become stale. 328 For an application performing a pre-session connectivity check, for 329 example, changes in both the state of the presentity and the state of 330 the network could render the results of a check stale at any time; 331 however, the application simply can't perform connectivity checks 332 constantly to mitigate this difficulty. Moreover, since that results 333 of that connectivity check are rendered to a human, nor do the checks 334 even need to be performed if applications are aware that no human 335 currently requires them. Setting sensible thresholds for these sorts 336 of pre-session application activities is a subject for future work, 337 as are the scalability concerns arising from a watcher who follows 338 Advertisements from an enormous number of presentities. 340 6. The Advertisement 342 This document articulates the high-level qualities of the 343 Advertisement/Proposal model. Document formats for Advertisements 344 are therefore out of scope; it is possible that even the Session 345 Description Protocol could be adapted to express an Advertisement or 346 Proposal, provided that it can articulate the necessary elements 347 unambiguously. 349 Purely for exemplary purposes, an Advertisement might contain the 350 following elements: 351 o Codecs and payload types supported by the originator of the 352 advertisement 353 o Protocol support (RTP, DCCP, TCP, UDP, HTTP, etc) 354 o IP Addresses and ports where the originator may send and receive 355 media 356 o Layer coding schemes, redundant encoding and forward error 357 correction 358 o Bit-rate limits, frame rates, display capabilities 359 o Security parameters of the session, including any information 360 needed to key media 361 o Content meta-data and information about repositories (for file- 362 transfer sessions) 364 7. The Proposal 366 The Proposal is a document which describes the entire state of the 367 desired session. The construction of the Proposal may be informed by 368 the Advertisement, but the interpretation of the Proposal is 369 unambiguous without the Advertisement. Again, this section merely 370 sketches the high-level properties of a Proposal as an indication of 371 the direction of future work. 373 A Proposal may contain: 374 o A specific five tuple for each media session proposed by its 375 creator 376 o A specific codec, payload type and SSRC for said media where 377 applicable 378 o Codec parameters (bit rates, picture sizes, etc) 380 8. Backward Compatibility 382 The use of the Advertisement/Proposal model integrates nicely with an 383 existing deployed base of offer/anser model compliance, for the 384 simple reason that one cannot send a Proposal without an 385 Advertisement, and any entity that promulgates Advertisements 386 supports Proposals. For deployments where both models are in 387 simultaneous use, baseline mandatory compliance with offer/answer 388 would be required, though when support for Advertisement/Proposal is 389 detected (via the presence of an Advertisement), it could be then 390 invoked when preferred. 392 At a syntactical level, any path to implementing an Advertisement/ 393 Proposal model requires disambiguating Proposals from offers or 394 answers. For Proposals written in SDP, perhaps a separate MIME media 395 type (e.g., "application/sdp-prop") might be defined which could in 396 turn be negotiated in the usual SIP matter, via OPTIONS requests, 415 397 response codes, and so forth. Any new document format for Proposals 398 could of course define a new MIME type and operate in the same 399 fashion. 401 9. Security Considerations 403 The Advertisement/Proposal model assumes the secure distribution of 404 Advertisements from a presentity to one or more watchers with whom 405 the presentity might want to share a session. An Advertisement could 406 impart secrets for keying media security, for example, which are 407 intended only for a particular watcher. The secure distribution of 408 presence documents is therefore essential to this model. 409 Fortunately, this problem is shared with most other sensitive 410 presence data, and thus this document need only point to the existing 411 guidance for securing presence documents in RFC3863. 413 10. IANA Considerations 415 This document contains no considerations for the IANA. 417 11. Informative References 419 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 420 3", BCP 9, RFC 2026, October 1996. 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, March 1997. 425 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 426 A., Peterson, J., Sparks, R., Handley, M., and E. 427 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 428 June 2002. 430 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 431 with Session Description Protocol (SDP)", RFC 3264, 432 June 2002. 434 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 435 Event Notification", RFC 3265, June 2002. 437 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 438 Extensions to the Session Initiation Protocol (SIP) for 439 Asserted Identity within Trusted Networks", RFC 3325, 440 November 2002. 442 [RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple 443 Capability Declaration", RFC 3407, October 2002. 445 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 446 "Indicating User Agent Capabilities in the Session 447 Initiation Protocol (SIP)", RFC 3840, August 2004. 449 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 450 W., and J. Peterson, "Presence Information Data Format 451 (PIDF)", RFC 3863, August 2004. 453 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 454 (IANA) Header Field Parameter Registry for the Session 455 Initiation Protocol (SIP)", BCP 98, RFC 3968, 456 December 2004. 458 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 459 Description Protocol", RFC 4566, July 2006. 461 [RFC5111] Aboba, B. and L. Dondeti, "Experiment in Exploratory Group 462 Formation within the Internet Engineering Task Force 463 (IETF)", RFC 5111, January 2008. 465 [RFC5196] Lonnfors, M. and K. Kiss, "Session Initiation Protocol 466 (SIP) User Agent Capability Extension to Presence 467 Information Data Format (PIDF)", RFC 5196, September 2008. 469 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 470 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 471 May 2008. 473 Authors' Addresses 475 Jon Peterson 476 NeuStar, Inc. 478 Email: jon.peterson@neustar.biz 480 Cullen Jennings 481 Cisco Systems 483 Email: fluffy@cisco.com