One document matched: draft-peterson-sipcore-advprop-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2026 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc3261 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
    <!ENTITY rfc3264 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
    <!ENTITY rfc3265 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml'>
    <!ENTITY rfc3325 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml'>
    <!ENTITY rfc3407 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3407.xml'>
    <!ENTITY rfc3840 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3840.xml'>
    <!ENTITY rfc3863 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3863.xml'>
    <!ENTITY rfc3968 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3968.xml'>
    <!ENTITY rfc4566 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
    <!ENTITY rfc5111 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5111.xml'>
    <!ENTITY rfc5196 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5196.xml'>
    <!ENTITY rfc5226 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
]>

<rfc category="std" ipr="pre5378Trust200902" docName="draft-peterson-sipcore-advprop-00">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>
        <title abbrev="Advertisement/Proposal">
The Advertisement/Proposal Model of Session Description</title>
        <author initials='J.' surname="Peterson" fullname='Jon Peterson'>
            <organization>NeuStar, Inc.</organization>
	<address>
            <email>jon.peterson@neustar.biz</email>
	</address>
        </author>
        <author initials='C.' surname="Jennings" fullname='Cullen Jennings'>
            <organization>Cisco Systems</organization>
	<address>
            <email>fluffy@cisco.com</email>
	</address>
        </author>
        <date/>
        <abstract><t>
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.
        </t></abstract>
    </front>

    <middle>
        <section title="Terminology">
            <t>
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD",
and "SHOULD NOT", are to be interpreted as described in
<xref target="RFC2119"/>. This document additionally uses <xref target="RFC5226"/> language to describe IANA
   registrations. The terms "watcher" and "presentity" and related presence terms are defined in RFC2778.
	</t>
        </section>

        <section title="Introduction">
        <t>
The <xref target="RFC4566">Session Description Protocol (SDP)</xref> enjoys widespread use in the Internet for the description of sessions established by protocols such as the <xref target="RFC3261">Session Initiation Protocol (SIP)</xref>. Most uses of SDP assume an offer/answer model as described in <xref target="RFC3264"/> 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.
	</t><t>
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.
	</t><t>
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.
	</t><t>
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 <xref target="RFC5196"/> (which in turn builds upon the user agent capabilities work in <xref target="RFC3840"/>) provides one possible framework in which, with some enhancements, an Advertisement might be articulated. Work has also been done in <xref target="RFC3407"/> 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.
	</t><t>
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.
	</t>
        </section>

        <section title="Limitations of the offer/answer model">
        <t>
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. 
	</t><t>
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. 
	</t><t>
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.
	</t><t>
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.
	</t><t>
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.
	</t>
        </section>

        <section title="Overview of the Advertisement/Proposal Model">
        <t>
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. 
	</t><t>
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.
	</t><t>
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.
	</t><t>
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.
	</t>
        </section>

        <section title="Benefits of the Advertisement/Proposal Model">
        <t>
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.
	</t><t>
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.
	</t><t>
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.
	</t><t>
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.
	</t><t>
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.
	</t>
        </section>

        <section title="The Advertisement">
        <t>
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. 
	</t><t>
Purely for exemplary purposes, an Advertisement might contain the following elements:
	<list style="symbols"><t>
Codecs and payload types supported by the originator of the advertisement
	</t><t>
Protocol support (RTP, DCCP, TCP, UDP, HTTP, etc)
	</t><t>
IP Addresses and ports where the originator may send and receive media
	</t><t>
Layer coding schemes, redundant encoding and forward error correction
	</t><t>
Bit-rate limits, frame rates, display capabilities
	</t><t>
Security parameters of the session, including any information needed to key media
	</t><t>
Content meta-data and information about repositories (for file-transfer sessions)
	</t></list>

	</t>
        </section>

        <section title="The Proposal">
        <t>
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.
	</t><t>
A Proposal may contain:
	<list style="symbols"><t>
A specific five tuple for each media session proposed by its creator
	</t><t>
A specific codec, payload type and SSRC for said media where applicable
	</t><t>
Codec parameters (bit rates, picture sizes, etc)

	</t></list>
	</t><t>
	</t>
        </section>

        <section title="Backward Compatibility">
        <t>
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.
	</t><t>
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.
	</t>
        </section>


        <section title="Security Considerations">
        <t>
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.
	</t>
        </section>


        <section title="IANA Considerations">
        <t>
This document contains no considerations for the IANA.
	</t>
        </section>


    </middle>

    <back>

        <references title='Informative References'>
		&rfc2026;
		&rfc2119;
		&rfc3261;
		&rfc3264;
		&rfc3265;
		&rfc3407;
		&rfc3325;
		&rfc3840;
		&rfc3863;
		&rfc3968;
		&rfc4566;
		&rfc5111;
		&rfc5196;
		&rfc5226;
	</references>
    </back>

</rfc>