| TOC |
|
Today, a session description negotiates preferences, capabilities and requested sessions in one document, which greatly confuses the disambiguation of these elements and thus the clear characterization of sessions. This document proposes an alternative to the offer/answer model which leverages presence to distribute session description into two phases: a presence-based Advertisement of capabilities and preferences which occurs in non-real-time before a session is ever requested, which is followed by a unidirectional Proposal of a session which is either accepted as a whole by its recipient or countered with a different proposal.
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 3, 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
1.
Terminology
2.
Motivation
3.
Overview of the Model
4.
The Advertisement
5.
The Proposal
6.
Security Considerations
7.
IANA Considerations
8.
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, RFC4566) enjoys widespread use in the Internet for the description of session 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 for interactive session establishment, where one side sends an offer and the other side replies with an answer. However, the enumeration of media streams in SDP is 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 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 radical increase its syntactical complexity, and thus have found mixed acceptance in the deployment community.
| TOC |
The availability of presence in many systems that establish multimedia sessions permits a new approach to capability and preference expression. Presence necessarily establishes a channel for communicating disposition between presence user agents which can be reused to share additional information useful in a later process of session establishment. This not only allows user agents greater insight into the likelihood of establishing a desired session, but indeed several of the functions which the offer/answer model defers to the session establishment phase can be completed in non-real-time by the presence user agents themselves.
Expressions of capability and preference are thus relegated to an Advertisement. An Advertisement is a document that may be shared as a component of an existing presence document, including a Presence Information Data Format (PIDF) document, or any other applicable format. Advertisements incorporate the session-related capabilities of the user agent they describe, as modified by user policy. A user agent may elect to share a custom Advertisement with any watcher, and thus depending on the watcher, user policy may dictate an Advertisement with a different structure. Advertisements may contain other information that is of use to endpoints prior to setting up a session, including information used in connectivity checks or keying media-layer security.
The Advertisement forms the basis of a Proposal. A user agent that wishes to initiate a session creates a Proposal by selecting a common set of desired capabilities from an Advertisement. 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.
Presence further enables Advertisements which anticipate other needs during session establishment, including the need to establish security parameters or connectivity indications. The ability of presence user agents to predict the availability of these services and report to end users the
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 |
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.
An Advertisement may contain the following elements:
- Codecs and payload types supported by the originator of the advertisement
- Protocol support (RTP, DCCP, TCP, UDP, HTTP, etc)
- IP Addresses and ports where the originator may send and receive media
- Layer coding schemes, redundant encoding and forward error correction
- Bit-rate limits, frame rates, display capabilities
- Security parameters of the session, including any information needed to key media
- Content meta-data and information about repositories (for file-transfer sessions)
| TOC |
In the offer/answer model, an SDP document is contributed by each endpoint that wishes to establish a session, and the session presumably follows the stipulations of both documents. The answer, in other words, is insufficient to characterize a session without its offer. This new method of session establishment forgoes this model and instead requires a single Proposal 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.
A Proposal may contain:
- A specific five tuple for each media session proposed by its creator
- A specific codec, payload type and SSRC for said media where applicable
- Codec parameters (bit rates, picture sizes, etc)
| 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 PIDF.
| 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 |