| TOC |
|
In common SIP practice, a two-phase "offer/answer" exchange of session description documents negotiates preferences, capabilities and requested sessions. However, the structure of the session description greatly confuses the disambiguation of these elements and thus the clear characterization of sessions. The current work proposes an alternative to the offer/answer model which leverages pre-association between user agents to recast those two phases into a less ambiguous form: an Advertisement of capabilities and preferences which occurs in non-real-time before a session is ever requested, which is followed during session establishment by a unidirectional and complete Proposal of a session.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
1.
Terminology
2.
Introduction
3.
Limitations of the offer/answer model
4.
Overview of the Advertisement/Proposal Model
5.
Benefits of the Advertisement/Proposal Model
6.
The Advertisement
7.
The Proposal
8.
Backward Compatibility
9.
Security Considerations
10.
IANA Considerations
11.
Informative References
§
Authors' Addresses
| TOC |
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.). This document additionally uses [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) language to describe IANA registrations. The terms "watcher" and "presentity" and related presence terms are defined in RFC2778.
| TOC |
The Session Description Protocol (SDP) (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] enjoys widespread use in the Internet for the description of sessions established by protocols such as the Session Initiation Protocol (SIP) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]. Most uses of SDP assume an offer/answer model as described in [RFC3264] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) for interactive session establishment, where one side sends an offer and the other side replies with an answer. However, many important matters relating to the management of media streams in SDP are inherently ambiguous in the offer/answer model. In particular, distinguishing the expression of capabilities from preferences from actual desired media streams has proven extremely difficult for more advanced applications of SDP. Moreover, as the offer and answer reflect only the media sinks of their respective creators, neither offers a complete picture of the session, and the degree to which the answer qualifies the offer admits of similar crippling ambiguities. These core difficulties have motivated numerous proposals to reform SDP, most of which radically increase its syntactical complexity, and thus have found mixed acceptance in the deployment community.
Perhaps the root of these problems lies not in SDP itself, however, but in application of SDP to the offer/answer model. SDP significantly predates the codification of the offer/answer model, and while RFC3264 added a great deal of value by formalizing the previously tacit principles of using SDP in SIP, nonetheless those principles themselves have intrinsic limitations.
This document therefore proposes a reexamination of the fundamental requirements underlying the use of SDP in session-establishment protocols such as SIP. It recognizes, first of all, the desirability of conveying in a SIP INVITE message a document that describes the proposed session completely, hereafter a Proposal. In order to formulate such a Proposal, however, the originator of a session must have access to the capabilities and preferences of the target. Thus, in an alternative model entities willing to receive a Proposal might promulgate Advertisements to would-be proposers. Advertisements contain all of the information about the advertiser required by proposers to formulate a Proposal, including details such as the IP address and port where they hope to receive media. One way that advertisements might deliver Advertisement to proposers is through presence.
Several previous efforts have recognized the need to provide capability and preference information prior to commencing the session establishment process. Notably, the work on expressing user agent capability within presence information [RFC5196] (Lonnfors, M. and K. Kiss, “Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF),” September 2008.) (which in turn builds upon the user agent capabilities work in [RFC3840] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.)) provides one possible framework in which, with some enhancements, an Advertisement might be articulated. Work has also been done in [RFC3407] (Andreasen, F., “Session Description Protocol (SDP) Simple Capability Declaration,” October 2002.) to express capability information with less ambiguity in SDP; by going down that path, an Advertisement might even be rendered in SDP. Rendering a Proposal in SDP would probably return that format to something like its original purpose. This document, however, proposes no specific syntactical format for Advertisements or Proposals - it merely describes the semantics of these objects as a set of requirements that future format proposals could meet.
While the work in this document is most immediately relevant to SIP, and discusses its applicability to SIP throughout, the underlying model may have further applicability to other protocol using session descriptions in a similar manner.
| TOC |
There are several limitations of the offer/answer model that cause issues with the operation of SIP. Many have been the target of prior work intended to repair the problem by adding additional syntactical structure to SDP. However, these problems arise from the semantics of SDP in the offer/answer context - not only because an offer represents an incomplete picture of the session, and at that a picture filled with conditional elements, but because an answer does not describe a session completely either.
In the traditional offer/answer model, in order to maximize the chances of the negotiation process arriving at an acceptable session, an offerer must propose the largest set of session features possible. This includes the various combinations of RTP profiles, transport addresses, security properties and so forth that would be acceptable to the offerer. Disambiguating the semantics of these features - distinguishing, for example, the session features the offerer would like to invoke concurrently as opposed to those offered as alternatives - has required the additional of significant complexity to SDP. Because SDP's underlying syntax is not designed to carry structured or hierarchical data, the resulting documents can be large and confusing. Indeed, the term "offer" no longer seems to fit what that sort of document describes - it is a menu rather than a selection. The resulting negotiation process, in which an answerer evaluates the alternatives described in the offer and arrives at a response, has become complex enough to call into question the wisdom of executing it in real-time, such as during the alerting phase of a telephone call.
Architecturally, an offerer moreover cannot anticipate what entity, or entities, their offer will reach, due to the potential in SIP for retargeting and/or forking. The fact that an answer typically arrives in a message confirming session establishment (the 200 OK), yet that it can originate from a surprising source, and make surprising stipulations, is a weakness in offer/answer. The offer/answer model places all of the onus, and the authority, on the answerer to complete a session within the very broad constraints that can be specified by the offerer. It is unclear why this power is better invested in the answerer than the offerer, but ideally, whichever side develops a finalizes proposal for the session should pass it to the other for approval, rather than assuming it will be acceptable and turning on the session. That somewhat philosophical point is not purely theoretical - it is one of the major drivers for classic problems in SIP such as early media, where due to forking several answerers may unknowingly operate on the same offer at once.
The fact that neither an offer nor an answer alone contains a complete picture of the session also compels intermediaries interested in SDP, for example application-layer gateways assisting with NAT traversal, to hear and modify, potentially, both requests and responses (e.g. a 200 carrying SDP) during session establishment. Unlike requests, responses cannot be rejected at the SIP layer, for security reasons or any other reasons, which effectively prevents endpoints from cleanly negotiating away from any unwanted "suggestions" made by intermediaries.
Some of this problem space in SDP is addressed by ongoing work of the MMUSIC working group on capability negotiation in SDP. The Advertisement/Proposal model differs from the capneg work in so far as capneg retains the offer/answer model and provides sufficient syntactical equipment in SDP to differentiate the various functions of expressing capability, proposing the properties of a session and confirming those proposals. However, despite their differences the approaches here and in are not mutually exclusive; in order to express Advertisements or Proposals in SDP, something very much like the attributes defined in the capneg work is required.
| TOC |
An Advertisement is a document detailing the parameters of sessions that a user is willing to accept. A user agent who aspires to initiate a session uses an Advertisement as the basis for a Proposal, a complete description of a session, by selecting a common set of desired capabilities from the Advertisement. This Proposal is then carried in a session initiation message such as an INVITE whose recipient will either accept or reject it in its entirety. A recipient who rejects a proposal may search for an Advertisement from the proposer, and in turn make their own Proposal based on it; this counter-Proposal has no necessary relationship with the rejected Proposal. Unlike the offer/answer model, in the Advertisement/Proposal model a Proposal is a complete description of a session - it does not specify preferences or capabilities, instead it proposes the media types, sources and sinks that shall be used by both endpoints in a session.
Advertisements incorporate the session-related capabilities of the user agent(s) they describe, as modified by user policy. A user agent may elect to share a customized Advertisement with a would-be proposer, and thus depending on the proposer, user policy may dictate an Advertisement offer different media types or what have. Advertisements may contain various proposer-specific information that is of use to endpoints prior to setting up a session, including information used in connectivity checks or keying media-layer security.
Promulgating Advertisements requires some administrative pre-association between user agents as well as a means of requesting and transmitting the Advertisement itself outside context of a session. The existing availability of presence in many systems that establish multimedia sessions permits the sharing of capability and preference expression, as per the work in RFC5196. Presence establishes a channel for communicating availability or capability information between presence user agents which can also share additional information relevant to a later stage of session establishment. Many presence systems moreover have the capability to supply customized presence data to particular watchers, a desirable quality for the Advertisement/Proposal model. An Advertisement may be shared as a component of an existing presence document, including a Presence Information Data Format (PIDF) document, or any other presence format. Note that the use of presence does not necessarily entail the maintenance of long-term subscriptions, and might rely in some cases on fetch operations conducted immediately prior to session initiation.
The Session Description Protocol provides numerous other expressions of capability (for example, the language of speakers in audio sessions) which are not considered here as requirements for adaptation to the Advertisement/Proposal model, though they may be incorporated into applications if desired.
| TOC |
In addition to addressing some existing problems in common SIP deployments, the use of the advertisement/proposal model also creates opportunities for new features. Most of these new features rely on the availability of the Advertisement prior to the time of session establishment, which allows user agents or applications to consider or act upon this information, in non-real-time.
The simplest application of this model is to allow the proposer the opportunity to browse the capabilities of an advertiser prior to making a session initiation attempt. In the traditional offer/answer model, the user must express any preferences to his user agent prior to attempting to initiate a session, and only when the INVITE is received, and one is on the proverbial clock, does the answerer begin the process of determining how the offerer's capabilities and preferences match to its own. While some potential methods in SIP of providing this "browsing" user experience prior to initiating a session have already been specified, as detailed above, those methods might turn out to be either partially redundant with the negotiation of the offer/answer phase or even contradictory to it - the Advertisement/Proposal model makes this user experience part and parcel of the session initiation process.
Another example is the use of an Advertisement to predict whether or not connectivity will be possible behind endpoints. Due to various network-layer obstacles (include NATs or firewalls), one SIP user agent may not be capable of forming a media session with another endpoint, despite their ability to rendez-vous successfully at the SIP layer. In an Advertisement, a user agent might express enough information to allow a would-be proposer to perform ICE-style checks prior to initiating a session, and thus to learn whether or not a potential target would be reachable. This information could be rendered to the proposer's user as a sort of presence information, for example ("red" signifying a media session cannot be formed with the target, "green" suggesting that it could). This is just one example of a whole class of information useful during session establishment that could be shared during the Advertisement phase - encryption keys for the bodies of SIP requests are another bit of information that might be difficult to acquire otherwise.
Advertisements are also useful in bunches. For a case where a third-party call control system is attempting to figure out how two or more parties could share some sort of common session, acquiring Advertisements from all parties ahead of time greatly facilitates the process of assembling Proposals that would be acceptable to the group. Conducting this process during session establishment itself (by inviting each party serially to a session, for example) could yield far less optimal results.
Any application that consumes Advertisement data prior to session establishment in order to make predictions about the session faces a trade-off resulting from the potential for that data to become stale. For an application performing a pre-session connectivity check, for example, changes in both the state of the presentity and the state of the network could render the results of a check stale at any time; however, the application simply can't perform connectivity checks constantly to mitigate this difficulty. Moreover, since that results of that connectivity check are rendered to a human, nor do the checks even need to be performed if applications are aware that no human currently requires them. Setting sensible thresholds for these sorts of pre-session application activities is a subject for future work, as are the scalability concerns arising from a watcher who follows Advertisements from an enormous number of presentities.
| TOC |
This document articulates the high-level qualities of the Advertisement/Proposal model. Document formats for Advertisements are therefore out of scope; it is possible that even the Session Description Protocol could be adapted to express an Advertisement or Proposal, provided that it can articulate the necessary elements unambiguously.
Purely for exemplary purposes, an Advertisement might contain the following elements:
| TOC |
The Proposal is a document which describes the entire state of the desired session. The construction of the Proposal may be informed by the Advertisement, but the interpretation of the Proposal is unambiguous without the Advertisement. Again, this section merely sketches the high-level properties of a Proposal as an indication of the direction of future work.
A Proposal may contain:
| TOC |
The use of the Advertisement/Proposal model integrates nicely with an existing deployed base of offer/anser model compliance, for the simple reason that one cannot send a Proposal without an Advertisement, and any entity that promulgates Advertisements supports Proposals. For deployments where both models are in simultaneous use, baseline mandatory compliance with offer/answer would be required, though when support for Advertisement/Proposal is detected (via the presence of an Advertisement), it could be then invoked when preferred.
At a syntactical level, any path to implementing an Advertisement/Proposal model requires disambiguating Proposals from offers or answers. For Proposals written in SDP, perhaps a separate MIME media type (e.g., "application/sdp-prop") might be defined which could in turn be negotiated in the usual SIP matter, via OPTIONS requests, 415 response codes, and so forth. Any new document format for Proposals could of course define a new MIME type and operate in the same fashion.
| TOC |
The Advertisement/Proposal model assumes the secure distribution of Advertisements from a presentity to one or more watchers with whom the presentity might want to share a session. An Advertisement could impart secrets for keying media security, for example, which are intended only for a particular watcher. The secure distribution of presence documents is therefore essential to this model. Fortunately, this problem is shared with most other sensitive presence data, and thus this document need only point to the existing guidance for securing presence documents in RFC3863.
| TOC |
This document contains no considerations for the IANA.
| TOC |
| TOC |
| Jon Peterson | |
| NeuStar, Inc. | |
| Email: | jon.peterson@neustar.biz |
| Cullen Jennings | |
| Cisco Systems | |
| Email: | fluffy@cisco.com |