Network Working Group J. Peterson
Internet-Draft NeuStar, Inc.
Intended status: Standards Track C. Jennings
Expires: September 15, 2011 Cisco Systems
March 14, 2011
The Advertisement/Proposal Model of Session Description
draft-peterson-sipcore-advprop-01
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 15, 2011.
Copyright Notice
Copyright (c) 2011 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
Peterson & Jennings Expires September 15, 2011 [Page 1]
Internet-Draft Advertisement/Proposal March 2011
(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 Simplified 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.
Peterson & Jennings Expires September 15, 2011 [Page 2]
Internet-Draft Advertisement/Proposal March 2011
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Limitations of the offer/answer model . . . . . . . . . . . . 5
4. Overview of the Advertisement/Proposal Model . . . . . . . . . 6
5. Benefits of the Advertisement/Proposal Model . . . . . . . . . 8
6. The Advertisement . . . . . . . . . . . . . . . . . . . . . . 9
7. The Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Peterson & Jennings Expires September 15, 2011 [Page 3]
Internet-Draft Advertisement/Proposal March 2011
1. Terminology
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD",
and "SHOULD NOT", are to be interpreted as described in [RFC2119].
This document additionally uses [RFC5226] language to describe IANA
registrations. The terms "watcher" and "presentity" and related
presence terms are defined in RFC2778.
2. Introduction
The Session Description Protocol (SDP) [RFC4566] enjoys widespread
use in the Internet for the description of sessions established by
protocols such as the Session Initiation Protocol (SIP) [RFC3261].
Most uses of SDP assume an offer/answer model as described in
[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.
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
Peterson & Jennings Expires September 15, 2011 [Page 4]
Internet-Draft Advertisement/Proposal March 2011
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] (which in turn
builds upon the user agent capabilities work in [RFC3840]) provides
one possible framework in which, with some enhancements, an
Advertisement might be articulated. Work has also been done in
[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.
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.
3. Limitations of the offer/answer model
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
Peterson & Jennings Expires September 15, 2011 [Page 5]
Internet-Draft Advertisement/Proposal March 2011
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.
4. Overview of the Advertisement/Proposal Model
An Advertisement is a document detailing the parameters of sessions
Peterson & Jennings Expires September 15, 2011 [Page 6]
Internet-Draft Advertisement/Proposal March 2011
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
Peterson & Jennings Expires September 15, 2011 [Page 7]
Internet-Draft Advertisement/Proposal March 2011
incorporated into applications if desired.
5. Benefits of the Advertisement/Proposal Model
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
Peterson & Jennings Expires September 15, 2011 [Page 8]
Internet-Draft Advertisement/Proposal March 2011
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.
6. The Advertisement
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:
o Codecs and payload types supported by the originator of the
advertisement
o Protocol support (RTP, DCCP, TCP, UDP, HTTP, etc)
o IP Addresses and ports where the originator may send and receive
media
o Layer coding schemes, redundant encoding and forward error
correction
o Bit-rate limits, frame rates, display capabilities
o Security parameters of the session, including any information
needed to key media
o Content meta-data and information about repositories (for file-
transfer sessions)
Peterson & Jennings Expires September 15, 2011 [Page 9]
Internet-Draft Advertisement/Proposal March 2011
7. The Proposal
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:
o A specific five tuple for each media session proposed by its
creator
o A specific codec, payload type and SSRC for said media where
applicable
o Codec parameters (bit rates, picture sizes, etc)
8. Backward Compatibility
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.
9. Security Considerations
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
Peterson & Jennings Expires September 15, 2011 [Page 10]
Internet-Draft Advertisement/Proposal March 2011
presence data, and thus this document need only point to the existing
guidance for securing presence documents in RFC3863.
10. IANA Considerations
This document contains no considerations for the IANA.
11. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
Peterson & Jennings Expires September 15, 2011 [Page 11]
Internet-Draft Advertisement/Proposal March 2011
December 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5111] Aboba, B. and L. Dondeti, "Experiment in Exploratory Group
Formation within the Internet Engineering Task Force
(IETF)", RFC 5111, January 2008.
[RFC5196] Lonnfors, M. and K. Kiss, "Session Initiation Protocol
(SIP) User Agent Capability Extension to Presence
Information Data Format (PIDF)", RFC 5196, September 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses
Jon Peterson
NeuStar, Inc.
Email: jon.peterson@neustar.biz
Cullen Jennings
Cisco Systems
Email: fluffy@cisco.com
Peterson & Jennings Expires September 15, 2011 [Page 12]