One document matched: draft-andreasen-mmusic-sdp-capability-negotiation-00.txt
MMUSIC Working Group F. Andreasen
Internet Draft Cisco Systems
Expires: December 2006 June 19, 2006
SDP Capability Negotiation
draft-andreasen-mmusic-sdp-capability-negotiation-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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 December 19, 2006.
Abstract
The Session Description Protocol (SDP) was intended for describing
multimedia sessions for the purposes of session announcement, session
invitation, and other forms of multimedia session initiation. SDP was
not intended to provide capability indication or capability
negotiation, however over the years, SDP has seen widespread adoption
and as a result it has been gradually extended to provide limited
support for these. SDP and its current extensions however do not have
the ability to negotiate one or more alternative transport protocols
(e.g. RTP profiles) which makes it particularly difficult to deploy
new RTP profiles such as secure RTP and RTP with RTCP-based feedback.
Andreasen Expires December 19, 2006 [Page 1]
Internet-Draft SDP Capability Negotiation June 2006
The purpose of this document is to address that by identifying a set
of requirements, evaluate existing work in this area, and provide a
recommended solution for extending SDP with capability negotiation.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction...................................................3
2. Requirements...................................................5
3. Review of Existing Work........................................7
3.1. Grouping of Media Lines...................................7
3.2. Session Description Protocol (SDP) Simple Capability
Declaration....................................................9
3.3. Session Description and Capability Negotiation (SDPng)...10
3.4. Multipart/alternative....................................12
3.5. Sharing Ports Between "m=" Lines.........................13
3.6. Opportunistic Encryption Using a Session Attribute.......14
3.7. Opportunistic Encryption using Probing...................14
4. Proposed Solution.............................................15
4.1. Solution Overview........................................15
4.2. Attribute Definitions....................................17
4.2.1. The Transport Protocol Capability Attribute.........17
4.2.2. The Transport Address Capability Attribute..........18
4.2.3. The Potential Configuration Attribute...............19
4.2.4. The Actual Configuration Attribute..................20
4.3. Offer/Answer Model Extensions............................22
4.3.1. Generating the Initial Offer........................22
4.3.2. Generating the Answer...............................23
4.3.3. Offerer Processing of the Answer....................23
4.3.4. Modifying the Session...............................24
5. Examples......................................................24
6. Security Considerations.......................................24
7. IANA Considerations...........................................24
8. To Do.........................................................24
9. Acknowledgments...............................................24
10. References...................................................25
10.1. Normative References....................................25
10.2. Informative References..................................25
Author's Addresses...............................................26
Intellectual Property Statement..................................27
Disclaimer of Validity...........................................27
Andreasen Expires December 19, 2006 [Page 2]
Internet-Draft SDP Capability Negotiation June 2006
Copyright Statement..............................................27
Acknowledgment...................................................27
1. Introduction
The Session Description Protocol (SDP) was intended for describing
multimedia sessions for the purposes of session announcement, session
invitation, and other forms of multimedia session initiation. The SDP
contains one or more media stream descriptions with information such
as IP-address and port, type of media stream (e.g. audio or video),
transport protocol (possibly including profile information, e.g.
RTP/AVP or RTP/SAVP), media formats (e.g. codecs), and various other
session and media stream parameters that define the session.
Simply providing media stream descriptions is sufficient for session
announcements for a broadcast application, where the media stream
parameters are fixed for all participants. When a participant wants
to join the session, he obtains the session announcement and uses the
media descriptions provided, e.g., joins a multicast group and
receives media packets in the encoding format specified. If the
media stream description is not supported by the participant, he is
unable to receive the media.
Such restrictions are not generally acceptable to multimedia session
invitations, where two or more entities attempt to establish a media
session using a set of media stream parameters acceptable to all
participants. First of all, each entity must inform the other of its
receive address, and secondly, the entities need to agree on the
media stream parameters to use for the session, e.g. transport
protocols and codecs. We here make a distinction between the
capabilities supported by each participant and the parameters that
can actually be used for the session. More generally, we can say that
we have the following:
o A set of capabilities, or potential configurations of the media
stream components, supported by each side.
o A set of actual configurations of the media stream components,
which specifies which media stream components to use and with what
parameters.
o A negotiation process that takes the set of potential
configurations (capabilities) as input and provides the actual
configurations as output.
SDP by itself was designed to provide only the second of these, i.e.,
the actual configurations, however over the years, use of SDP has
Andreasen Expires December 19, 2006 [Page 3]
Internet-Draft SDP Capability Negotiation June 2006
been extended beyond its original scope. Session negotiation
semantics was defined by the offer/answer model in RFC 3264. It
defines how two entities, an offerer and an answerer, exchange SDPs
to negotiate a session. The offerer can include one or more media
formats (codecs) per media stream, and the answerer then selects one
or more of those offered and returns them in an answer. Both the
offer and the answer contain actual configurations - potential
configurations are not supported. The answer however may reduce the
set of actual configurations from the offer.
Other relevant extensions have been defined. Simple capability
declarations, which defines how to provide a simple and limited set
of capability descriptions in SDP was defined in RFC 3407. Grouping
of media lines, which defines how media lines in SDP can have other
semantics than the traditional "simultaneous media streams"
semantics, was defined in RFC 3388, etc.
Each of these extensions was designed to solve a specific limitation
of SDP. Since SDP had already been stretched beyond its original
intent, a more comprehensive capability declaration and negotiation
process was intentionally not defined. Instead, work on a "next
generation" of a protocol to provide session description and
capability negotiation was initiated [SDPng]. SDPng however has not
gained traction and has remained as work in progress for an extended
period of time. Existing real-time multimedia communication
protocols such as SIP, RTSP, Megaco, and MGCP continue to use SDP.
SDP and its current extensions however do not address an increasingly
important problem: the ability to negotiate one or more alternative
transport protocols (e.g., RTP profiles). This makes it difficult to
deploy new RTP profiles such as secure RTP (SRTP) [RFC3711], RTP with
RTCP-Based Feedback [AVPF], etc. This particular problem is
exacerbated by the fact that RTP profiles are defined independently.
When a new profile is defined and N other profiles already exist,
there is a potential need for defining N additional profiles, since
profiles cannot be combined automatically. For example, in order to
support the plain and secure RTP version of RTP with and without
RTCP-based feedback, four separate profiles (and hence profile
definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP [RFC3711],
RTP/AVPF [AVPF], and RTP/SAVPF [SAVPF]. In addition to the pressing
profile negotiation problem, other important real-life constraints
have been found as well.
The purpose of this document is to define a mechanism that enables
SDP to provide limited support for indicating potential
configurations (capabilities) and negotiate the use of those
potential configurations as actual configurations. It is not the
intent to provide a full-fledged capability indication and
Andreasen Expires December 19, 2006 [Page 4]
Internet-Draft SDP Capability Negotiation June 2006
negotiation mechanism along the lines of SDPng or ITU-T H.245.
Instead, the focus is on addressing a set of well-known real-life
limitations.
As mentioned above, SDP is used by several protocols, and hence the
mechanism should be usable by all of these. One particularly
important protocol for this problem however is the Session Initiation
Protocol (SIP) [RFC3261]. SIP uses the offer/answer model (which is
not specific to SIP) to negotiate sessions and hence any mechanism
must at least consider how it either interacts with offer/answer, or
how it should extend it.
The rest of the document is structured as follows. We first provide a
set of requirements for the solution in Section 2. In Section 3. we
review relevant existing work in this area, how a solution based on
that might look, and the pros and cons associated with each. In
Section 4. we present our proposed solution in more detail followed
examples in Section 5. and security considerations in Section 6.
2. Requirements
REQ-10: It MUST be possible to indicate and negotiate alternative
media formats on a per media stream basis.
For example, many implementations support multiple codecs, but
only one at a time. Changes between codecs cannot be done on-
the-fly, e.g. when receiving a simple RTP payload type change.
REQ-20: It MUST be possible to indicate and negotiate alternative
attribute values ("a=") on a per media stream basis.
For example, T.38 defines new attributes that may need to be
conveyed as part of a capability.
REQ-30: It MUST be possible to indicate and negotiate alternative
media format parameter values ("a=fmtp") per media format on a per
media stream basis.
For example, a media format (codec) indicated as an alternative
capability may include fmtp parameters.
REQ-40: It MUST be possible to indicate and negotiate alternative
transport protocols, e.g. different RTP profiles, on a per media
stream basis.
For example, "RTP/AVP" and "RTP/SAVP" may be alternatives.
Andreasen Expires December 19, 2006 [Page 5]
Internet-Draft SDP Capability Negotiation June 2006
REQ-50: It MUST be possible to indicate and negotiate alternative
transport protocol and media type combinations on a per media stream
basis.
For example, an entity may support a fax call using either T.38
fax relay ("m=image <port> udptl t38") or PCMU ("m=audio <port>
RTP/AVP 0").
REQ-60: It MUST be possible to specify unicast and multicast
addresses as alternatives.
[Editor's Note: This leads to some interesting issues with respect
to the offer/answer model, where the set of parameters of
relevance (or even defined) for a unicast stream differs from
that of multicast streams. Also, some parameters have different
meanings (e.g. direction attributes).]
REQ-70: It MUST be possible to specify IPv4 and IPv6 addresses as
alternatives.
[Editor's note: This duplicates the ANAT grouping semantics - is
it needed here ?]
REQ-80: The mechanism MUST be backwards compatible for at least SIP
and RTSP. Ideally, the mechanism should be completely transparent to
entities that do not support it, without the need for any further
signaling.
REQ-90: The mechanism MUST either be backwards compatible for Megaco
and MGCP or it MUST be possible to interwork it with Megaco and MGCP
without any additional signaling.
For example, if a media gateway controller (MGC) uses SIP to
communicate with peers, and the MGC uses Megaco or MGCP to
control a media gateway, it must be possible to translate between
the mechanism and normal SDP. Avoiding interworking requirements
in the MGC is desirable.
REQ-100: The mechanism MUST work within the context of the
offer/answer model [RFC3264]. Specifically, it MUST be able to
negotiate alternatives within a single round-trip.
[Editor's note: Should we limit scope to O/A only, or should we
include RTSP as well ?]
REQ-110: The offer/answer model requires the offerer to be able to
receive media for any media streams listed as either "recvonly" or
Andreasen Expires December 19, 2006 [Page 6]
Internet-Draft SDP Capability Negotiation June 2006
"sendrecv" in an offer, as soon as that offer is generated. The
mechanism MUST preserve this capability for all actual configurations
included in an offer.
Potential configurations do not have such a requirement.
REQ-120: The mechanism MUST enable inclusion of potential
configurations (alternative capabilities) in the offer - the answer
would then indicate which, if any of these potential configurations
were accepted. The offerer is not required to process media for a
specific potential configuration until the offerer receives an answer
showing that potential configuration was accepted.
REQ-130: The mechanism MUST work in the presence of SIP forking.
REQ-140: The mechanism SHOULD be reasonably efficient in terms of
overall message size.
This is a relative requirement to evaluate alternative solutions
as opposed to an absolute and quantifiable requirement
Above, we presented the requirements for the capability negotiation
mechanism. Below, we provide a set of features that were considered
and then explicitly deemed to be out-of-scope:
o Indication of mandatory and optional capabilities.
o Constraints on combinations of configurations, e.g. inability to
use a video codec together with a particular audio codec,
parameter X values that can only be used with parameter Y values,
etc.
3. Review of Existing Work
In this section, we provide an overview of existing relevant work
that has either been completed or is work in progress. For each
item, we outline how/if it can be used to address the requirements
provided and the pros and cons of doing so.
3.1. Grouping of Media Lines
Grouping of Media Lines is defined in [RFC3388]. RFC 3388 defines a
framework that enables two or media lines to be grouped together for
different purposes. Each media line is assigned an identifier and one
or more group attributes then references two or more of those
identifiers. Associated with each group attribute is a semantics
indication. One semantic indication is the Alternative Network
Andreasen Expires December 19, 2006 [Page 7]
Internet-Draft SDP Capability Negotiation June 2006
Address Types ("ANAT") [RFC4091] which allows for IPv4 and IPv6
addresses to be specified as alternatives. The requirements presented
above go beyond that, however a new semantic to simply indicate
alternative media lines and associated negotiation rules could easily
be defined.
The main advantages of such an approach would be:
o Mechanism Reuse: Several semantics have already been defined
which increases the likelihood of an implementation supporting the
framework.
The disadvantages of such an approach would be:
o Backwards Compatibility: The mechanism is not transparently
backwards compatible. If an entity that does not support the
mechanism receives it, the entity may incorrectly interpret the
SDP as consisting of multiple media streams. While RFC 3388
defines procedures for recognizing and recover from this when
using offer/answer, it can still lead to unintended behavior with
endpoints that do not support the mechanism.
In practice, it is not clear how much of an issue this is, at
least for intelligent SIP endpoints. Most current
implementations generally accept only one media stream of a
given type (e.g. audio). Use of alternatives with different
media stream types (e.g. a fax call using "audio" for voice-
band data or "image" for T.38) makes it less clear though.
Also, Media Gateway Controllers and Media Gateways that do not
support grouping of media lines have been known to encounter
problems.
o Semantics Combination Issues: Multiple semantics may be provided
by use of grouping, however they may interact with each other
unintentionally. For example, the "FID" semantics defined in RFC
3388 forbids grouping of media lines with the same transport
address, however that would be needed for alternative
capabilities. Thus, using "FID" and alternative capabilities
together would require special consideration.
Andreasen Expires December 19, 2006 [Page 8]
Internet-Draft SDP Capability Negotiation June 2006
o Some Combinatoric Explosion: The mechanism is not ideal to
indicate alternative capabilities for multiple parameters or media
formats within a particular media stream. For example, alternative
attribute values and media format parameters for several codecs
would lead to combinatoric explosion.
[Editor's note: In practice, it is not clear this is a huge issue
though.]
o Message Size: Each alternative requires full duplication of all
the relevant media stream parameters.
[Editor's note: In practice, it is not clear this is a huge issue
though.]
3.2. Session Description Protocol (SDP) Simple Capability Declaration
SDP Simple Capability Declaration (simcap) is defined in [RFC3407].
It defines a set of SDP attributes that enables capabilities to be
described at a session level or on a per media stream basis. RFC
3407 defines capability declaration only - actual negotiation
procedures taking advantage of such capabilities have not been
defined. Also, RFC 3407 does not define a way to indicate
alternative transport addresses. Such rules and transport address
capabilities however could easily be defined - the negotiation part
would extend the offer/answer model to examine alternative
configurations (capabilities). In conjunction with that, attributes
to indicate the alternative configurations accepted would likely be
needed as well.
The main advantages of this approach are:
o Satisfies all the requirements provided above. In particular, by
relying solely on SDP attributes, transparent backwards
compatibility is always ensured.
The disadvantages of this approach are:
o Offered Capabilities Hidden in Attributes: An offer may be
accepted by the answerer and a media stream established based on
SDP parameters contained in SDP attributes not known to
intermediaries. Such intermediaries may be back-to-back user
agents, or proxies that need to inspect the SDP, e.g., to
authorize Quality of Service, add transcoders, etc.
Andreasen Expires December 19, 2006 [Page 9]
Internet-Draft SDP Capability Negotiation June 2006
o Maximum of 255 alternative media formats per SDP: RFC 3407
currently allows a maximum of 255 alternative media formats
(codecs) per SDP. This may be too restrictive.
3.3. Session Description and Capability Negotiation (SDPng)
The Session Description and Capability Negotiation protocol [SDPng]
was intended as a replacement for SDP [SDP]. SDPng includes a full
capability indication and negotiation framework that would address
the shortcomings of SDP and satisfy the requirements provided above.
However, SDPng has not gained traction, in large part due to existing
widespread adoption of SDP. As a consequence, SDPng has remained as
work in progress with limited progress for an extended period of
time.
SDPng consists of two things: an SDPng description, which is an XML
document that describes the actual and/or potential configurations as
well as an optional negotiation process (an offer/answer compliant
process is included as part of SDPng). The SDPng description consists
of up to five parts:
o Capabilities: An optional list of capabilities (potential
configurations) to be matched with the other parties'
capabilities.
o Definitions: An optional set of definitions of commonly used
parameters for later referencing.
o Configurations: A mandatory description of the conference
components, each of which can provide a list of alternative
configurations.
o Constraints: An optional set of constraints of combinations
of configurations. Constraints are not defined as part of the
base SDPng specification.
o Session Information: Optional meta information on the
conferences and individual components.
SDPng is application-agnostic with the base specification defining a
basic XML schema supporting the above. In order to actually use
SDPng, application-specific packages are needed. Packages define
things such as media types, codecs and their configuration
parameters, etc. The base SDPng specification includes a couple of
example packages to support audio, video, and RTP.
Andreasen Expires December 19, 2006 [Page 10]
Internet-Draft SDP Capability Negotiation June 2006
One approach to extending SDP with capability indication and
negotiation capabilities could be to adopt the mechanisms defined by
SDPng that are necessary to satisfy the requirements provided above.
Those areas could then be included within SDP itself, e.g. in the
form of one or more SDP attributes ("a=") containing the actual SDPng
description. The areas to consider here include:
o Capabilities: This would be needed to describe alternative media
formats and media format parameters.
o Definitions: This would be needed to define alternative
transport addresses.
o Configurations: This would be needed to define alternative
configurations
The constraints and session information parts of SDPng would not be
used.
The main advantages of such an approach would be:
o SDPng was designed and intended to solve the general capability
negotiation problems faced by SDP. A considerable amount of work
has already gone into it and it was originally targeted as the
long-term direction (replacement for SDP).
The disadvantages of such an approach would be:
o Duplicate Encoding and Specification Work: SDPng uses a
different coding format than SDP and hence all SDP parameters
(incl. codecs and transports) that need to be provided will need
to have an equivalent SDPng definition. There is currently no
automatic process for translating all SDP parameters or values
into corresponding SDPng parameters or values; many existing SDP
parameters and values currently have no corresponding SDPng
definition.
o SDPng is Work in Progress: SDPng is currently work in progress but
has seen limited interest and progress for a while. Adoption of a
subset of its current definition may end up differing from the
final specification. Also, the current SDPng specification needs
further clarification and semantic tightening in a number of areas
that would be of relevance to this approach.
Andreasen Expires December 19, 2006 [Page 11]
Internet-Draft SDP Capability Negotiation June 2006
o Negotiation of Transport Parameters: SDPng currently does not
support negotiation of transport parameters as individual
capabilities. It is however still possible to negotiate different
transport parameters by providing alternative configurations.
o Verbose Encoding and Large Message Size: SDPng descriptions are
XML documents, which are fairly verbose and result in descriptions
that are substantially larger than existing SDP.
3.4. Multipart/alternative
In [I-D.jenning-sipping-multipart], the use of multipart/alternative
MIME is proposed as a way to support multiple alternative offers.
Each alternative offer has an id associated with it by use of a new
MIME header field called Content-Answering-CID. The answerer chooses
one of the offers and performs normal offer/answer operation on that
offer, and then sends back a single answer which includes the
Content-Answering-CID value of the offer chosen.
The main advantages of this approach are:
o It allows for use of alternative encodings of the offer, e.g. SDP
and SDPng, as well as varying levels of confidentiality and
integrity by use of S/MIME [RFC3851].
Use of multipart/alternative to solve the SDP capability negotiation
problems however has several shortcomings:
o Backwards Compatibility: Neither SIP nor RTSP mandate support
for Multipart MIME. In the case of SIP, multipart/alternative is
generally incompatible with existing SIP proxies, firewalls,
Session Border Controllers, and endpoints.
o Heterogeneous Error Response Forking Problem (HERFP): When a SIP
proxy forks a request to multiple Contacts, each of which generate
a response, the proxy only forwards the "best" of these responses
to the request originator. If one or more of the Contacts do not
support multipart/alternative, the request originator may never
discover this. Instead, only a Contact that supports
multipart/alternative will be able to generate an answer that
reaches the request originator.
o Combinatoric Explosions: Use of multipart/alternative to convey
alternatives on a per media stream basis or even per media format
parameter basis quickly leads to combinatoric explosions.
Andreasen Expires December 19, 2006 [Page 12]
Internet-Draft SDP Capability Negotiation June 2006
o Message Size: Each alternative requires full duplication of all
the relevant SDP parameters (one complete SDP per alternative).
It should be noted, that use of multipart/alternative has been
discussed several times before and, in large part due to the problems
mentioned above as well as the semantics defined for
multipart/alternative [RFC2046], has met with opposition when it
comes to addressing the above types of requirements.
3.5. Sharing Ports Between "m=" Lines
SDP [SDP] does not state whether two "m=" lines can share the same
transport address or not but rather leaves this explicitly undefined.
It has been suggested that alternative capabilities for a media
stream could be indicated by including multiple media stream
descriptions sharing the same transport address (i.e. using the same
port number in the "m=" line and sharing the same IP-address).
Such practice was not defined in [RFC2327], however it was
suggested in an Internet-Draft version of [SDP]. Following
discussion of the potential problems it introduced, it was removed.
The main advantages of this approach would be:
o May not require any additional extensions to SDP - only additional
semantics.
[Editor's note: It is somewhat unclear how it would work without
extensions if we allow for alternative attributes and media format
parameters and the offerer needs to always know which ones were
accepted]
The disadvantages of this approach would be:
o Alternative Address Support: It would not be possible to support
unicast and multicast transport addresses as alternatives using
this method. Similarly, IPv4 and IPv6 addresses as alternatives
would not be possible.
o Backwards Compatibility Issues: Since sharing of transport
addresses between multiple streams was never specified as part of
SDP, backwards compatibility is likely to be an issue. Some
implementations may support it whereas others may not. The lack of
an explicit signaling indication to indicate the desired operation
may lead to ungraceful failure scenarios. Offer/answer semantics
would be unclear here as well.
Andreasen Expires December 19, 2006 [Page 13]
Internet-Draft SDP Capability Negotiation June 2006
o Some Combinatoric Explosion: The mechanism is not ideal to
indicate alternative capabilities for multiple parameters or media
formats within a particular media stream. For example, alternative
attribute values and media format parameters for several codecs
would lead to combinatoric explosion.
o Message Size: Each alternative requires full duplication of all
the relevant media stream parameters.
[Editor's note: In practice, it is not clear this is a huge issue
though.]
3.6. Opportunistic Encryption Using a Session Attribute
This approach was suggested to address the specific scenario of
negotiating either RTP or SRTP. The endpoints signal their desire to
do SRTP by signaling RTP (RTP/AVP), and using an attribute ("a=") in
the SDP that indicates whether SRTP is supported or not.
The main advantages of this approach are:
o Compatible with non-SRTP-aware endpoints.
The disadvantages of this approach are:
o Violates RFC 3711 by listing an incorrect profile ("RTP/AVP"
instead of "RTP/SAVP").
o Addresses only a small subset of the requirements provided above.
3.7. Opportunistic Encryption using Probing
This is another approach suggested to address the specific scenario
of negotiating either RTP or SRTP. In this case, the endpoints first
establish an RTP session using RTP (RTP/AVP). The endpoints send
probe messages, over the media path, to determine if the remote
endpoint supports their keying technique.
The main advantages of this approach are:
o Compatible with non-SRTP-aware endpoints.
The disadvantages of this approach are:
o Addresses only a small subset of the requirements provided above.
Andreasen Expires December 19, 2006 [Page 14]
Internet-Draft SDP Capability Negotiation June 2006
4. Proposed Solution
Based on the requirements provided in Section 2. and the alternatives
examined in Section 3. the solution based on the Session Description
Protocol (SDP) Simple Capability Declaration (simcap) [RFC3407] with
extensions as outlined in Section 3.2. is preferred. In this section
we present that solution in detail.
4.1. Solution Overview
The solution consists of the following:
o The capability declaration mechanism defined by simcap [RFC3407].
o A new attribute ("a=ctrpr") that defines how to list transport
protocols as capabilities.
o A new attribute ("a=ctrad") that defines how to list transport
addresses as capabilities.
o A new attribute ("a=pcfg") that lists the potential configurations
supported by the entity that generated the SDP. This is done by
reference to the simcap capabilities from the SDP in question, and
optionally one or more of the transport protocol and transport
address capabilities.
o A new attribute ("a=acfg") to be used in an answer SDP. The
attribute identifies which of the potential configurations from an
offer SDP were used as actual configurations to form the answer
SDP. This is done by listing the potential configurations that
were used from the offer SDP.
o Extensions to the offer/answer model that allow for potential
configurations to be included in an offer, where they constitute
offers that may be accepted by the answerer instead of the actual
configuration(s) included in the "m=" line(s).
The mechanism is illustrated by the offer/answer exchange below,
where Alice sends an offer to Bob:
Andreasen Expires December 19, 2006 [Page 15]
Internet-Draft SDP Capability Negotiation June 2006
Alice Bob
| (1) Offer (SRTP and RTP) |
|--------------------------------->|
| |
| (2) Answer (RTP) |
|<---------------------------------|
| |
Alice's offer includes RTP and SRTP as alternatives, with SRTP being
the preferred one:
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=sqn: 0
a=cdsc: 1 audio RTP/SAVP 0 18
a=cdsc: 3 audio RTP/AVP 0 18
a=pcfg: c=1,2|3,4
The "m=" line indicates that Alice is offering to use RTP with PCMU
or G.729. The "crypto" attribute provides the keying material using
SDP security descriptions [SDES]. The simcap capability declaration
is provided by the "a=sqn" and "a=cdsc" attributes as defined in
[RFC3407]. The capabilities indicate that PCMU and G.729 are
supported with either secure RTP (preferred) or RTP. The new "a=pcfg"
attribute provides the potential configurations included in the offer
by reference to the simcap capability declarations. Two alternatives
are provided; the first one using capabilities 1 and 2, i.e. PCMU and
G.729 under the RTP/SAVP profile (secure RTP), and the second one
using capabilities 3 and 4, i.e. PCMU and G.729 under the RTP/AVP
profile.
Bob receives the SDP offer from Alice. Bob supports RTP, but not
SRTP, and hence he accepts the potential configuration for RTP
provided by Alice:
v=0
o=- 24351 621814 IN IP4 128.96.41.2
s=
c=IN IP4 128.96.41.2
t=0 0
Andreasen Expires December 19, 2006 [Page 16]
Internet-Draft SDP Capability Negotiation June 2006
m=audio 4567 RTP/AVP 0 18
a=acfg: c=3,4
Bob includes the new "a=acfg" attribute in the answer to inform Alice
that he based his answer on an offer containing the potential
configuration with capabilities 3 and 4 from the offer SDP (i.e. PCMU
and G.729 under the RTP/AVP profile). This in turn implies that
absence of an "a=crypto" attribute in the answer (to convey SRTP
keying material) does not constitute an error.
4.2. Attribute Definitions
4.2.1. The Transport Protocol Capability Attribute
Transport Protocols can be expressed as capabilities by use of a new
Transport Protocol Capability attribute ("a=ctrpr") defined as
follows:
a=ctrpr: <trpr-cap-num> <proto>
where <trpr-cap-num> is an integer between 1 and 255 (both included)
used to number the transport address capability for later reference,
and <proto> is defined as in the SDP "m=" line.
The "ctrpr" attribute is a media-level only attribute. Each
occurrence of the attribute within a given media description ("m="
line) MUST use a different value of <trpr-cap-num>, with the first
one being 1, the second one being 2, etc. The <trpr-cap-num> values
provided are independent of similar <cap-num> values provided for
other attributes, i.e., they form a separate name-space for transport
protocol capabilities.
[Editor's Note: Could easily be a session-level attribute - would
potentially be more efficient in case of multiple media
descriptions.]
Below, we provide examples of the "a=ctrpr" attribute:
a=ctrpr: 1 RTP/AVP
a=ctrpr: 2 RTP/AVPF
The first one provides a capability for the "RTP/AVP" profile defined
in [RFC3551] and the second one provides a capability for the RTP
with RTCP-Based Feedback profile defined in [AVPF].
Note that the simcap extensions already provide for this capability
by inclusion in the "cdsc" attribute, however having this as a
Andreasen Expires December 19, 2006 [Page 17]
Internet-Draft SDP Capability Negotiation June 2006
separate capability indication can provide significant message size
reduction when negotiating alternative profiles (of which there can
be many).
TO DO: Explain further when it is appropriate to use one
mechanism versus the other. For example, when attributes are
included as capabilities and those attributes apply to only some
profiles, use of this attribute may not be appropriate (e.g.
consider "crypto" attribute with "RTP/AVP" and "RTP/SAVP".
4.2.2. The Transport Address Capability Attribute
Transport addresses can be expressed as capabilities by use of a new
Transport Address Capability attribute ("a=ctrad") defined as
follows:
a=ctrad: <trad-cap-num> <network type> <address type>
<connection address> <port> *<port>
where <trad-cap-num> is an integer between 1 and 255 (both included)
used to number the transport address capability for later reference,
<network type>, <address type> and <connection address> are defined
as in the SDP "c=" line, and the first occurrence of <port> is as
defined in the SDP "m=" line. Additional <port> occurrences may be
present; the only currently well-defined semantics associated with
this is when one additional port is present for RTP-based media
streams. In that case, that second port field takes on the meaning of
the "a=rtcp" attribute defined in [RFC3605].
The "ctrad" attribute is a media-level only attribute. Each
occurrence of the attribute within a given media description ("m="
line) MUST use a different value of <trad-cap-num>, with the first
one being 1, the second one being 2, etc. The <trad-cap-num> values
provided are independent of similar <cap-num> values provided for
other attributes, i.e., they form a separate name-space for transport
address capabilities.
Below, we provide an example of the "a=ctrad" attribute:
a=ctrad: 1 IN IP4 128.96.41.1 3456
a=ctrad: 2 IN IP4 224.2.17.12/127 49170
The first provides a unicast address on port 3456, whereas the second
provides a multicast address with a time to live of 127 on port
49170.
Andreasen Expires December 19, 2006 [Page 18]
Internet-Draft SDP Capability Negotiation June 2006
4.2.3. The Potential Configuration Attribute
Potential Configurations can be expressed by use of a new Potential
Configuration Attribute ("a=pcfg") defined as follows:
a=pcfg: <simcap-capabilities>
[<transport-protocol-capabilities]
[<transport-address-capabilities>]
The potential configuration attribute includes one or more sets of
simcap-capabilities. A list of possible transport address
capabilities as well as transport protocol capabilities can
optionally be included as well. Together, these values define a set
of potential configurations.
TO DO: Clean up capability and configuration terminology.
<simcap-capabilities> is defined by the following ABNF:
simcap-capabilities = "c=" cap-list *("|" cap-list)
cap-list = cap-num *("," cap-num)
cap-num = 1*3DIGIT ; defined in [RFC4234]
Each capability list is a comma-separated list of simcap capability
numbers where cap-num refers to simcap capability numbers and hence
MUST be between 1 and 255 (both included). Alternative potential
simcap configurations are separated by a vertical bar ("|").
<transport-protocol-capabilities> is defined by the following ABNF:
transport-protocol-capabilities = "p=" trpr-cap-list
trpr-cap-list = trpr-cap-num *("," trpr-cap-num)
trpr-cap-num = 1*3DIGIT ; defined in [RFC4234]
The trpr-cap-num refers to transport protocol capability numbers
defined above and hence MUST be between 1 and 255 (both included).
Multiple transport protocol capabilities are provided in a comma-
separated list. When transport protocol capabilities are not
included, the transport protocol information from the media
description ("m=" line) will be used.
<transport-address-capabilities> is defined by the following ABNF:
transport-address-capabilities = "a=" trad-cap-list
trad-cap-list = trad-cap-num *("," trad-cap-num)
trad-cap-num = 1*3DIGIT ; defined in [RFC4234]
Andreasen Expires December 19, 2006 [Page 19]
Internet-Draft SDP Capability Negotiation June 2006
The trad-cap-num refers to transport address capability numbers
defined above and hence MUST be between 1 and 255 (both included).
Multiple transport address capabilities are provided in a comma-
separated list. When transport address capabilities are not included,
the transport address information from the media description ("m="
line and corresponding "c=" line) will be used.
The potential configuration ("a=pcfg") attribute is a media-level
only attribute. Each occurrence of the attribute within a given media
description ("m=" line) defines a set of potential configurations
that can be used for that media description.
Below, we provide an example of the "a=pcfg" attribute in a complete
media description in order to properly indicate the supporting
attributes:
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/SAVPF 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=sqn: 0
a=cdsc: 1 audio RTP/SAVP 0 4 18
a=ctrad: 1 IN IP4 128.96.41.1 3456
a=ctrad: 2 IN IP4 224.2.17.12/127 49170
a=ctrpr: 1 RTP/AVP
a=ctrpr: 2 RTP/AVPF
a=ctrpr: 3 RTP/SAVP
a=ctrpr: 4 RTP/SAVPF
a=pcfg: c=1|3 p=1,2,3,4 a=1
a=pcfg: c=2 p=1 a=1,2
We have two potential configurations listed here. The first one
indicates that PCMU (payload type number 0) or G.729 (payload type
number 18) can be supported with either of the profiles RTP/AVP,
RTP/AVPF, RTP/SAVP, or RTP/SAVPF on the unicast address only. The
second potential configuration indicates that G.723 (payload type
number 4) can be supported with the RTP/AVP profile only but on
either the unicast or multicast address indicated.
4.2.4. The Actual Configuration Attribute
The actual configuration attribute identifies which of the potential
configurations from an offer SDP were used as actual configurations
Andreasen Expires December 19, 2006 [Page 20]
Internet-Draft SDP Capability Negotiation June 2006
in an answer SDP. This is done by reference to the simcap
capabilities, and the transport protocol and transport address (if
included) capabilities from the offer that were actually used by the
answerer in his offer/answer procedure.
The Actual Configuration Attribute ("a=acfg") is defined as follows:
a=acfg: <simcap-capability-list>
[<transport-protocol-capability]
[<transport-address-capability>]
<simcap-capabily-list> is defined by the following ABNF:
simcap-capabily-list = "c=" cap-list
cap-list = cap-num *("," cap-num)
cap-num = 1*3DIGIT ; defined in [RFC4234]
Each capability list is a comma-separated list of simcap capability
numbers where cap-num refers to simcap capability numbers and hence
MUST be between 1 and 255 (both included).
<transport-protocol-capabilities> is defined by the following ABNF:
transport-protocol-capability = "p=" trpr-cap-num
trpr-cap-num = 1*3DIGIT ; defined in [RFC4234]
The trpr-cap-num refers to transport protocol capability numbers
defined above and hence MUST be between 1 and 255 (both included).
When a transport protocol capability is not included, the transport
protocol information from the media description ("m=" line) in the
offer is being used.
<transport-address-capability> is defined by the following ABNF:
transport-address-capability = "a=" trad-cap-num
trad-cap-num = 1*3DIGIT ; defined in [RFC4234]
The trad-cap-num refers to transport address capability numbers
defined above and hence MUST be between 1 and 255 (both included).
When a transport address capability is not included, the transport
address information from the media description ("m=" line and
corresponding "c=" line) in the corresponding offer is being used.
The actual configuration ("a=acfg") attribute is a media-level only
attribute. There MUST NOT be more than one occurrence of an actual
configuration attribute within a given media description.
Andreasen Expires December 19, 2006 [Page 21]
Internet-Draft SDP Capability Negotiation June 2006
Below, we provide an example of the "a=acfg" attribute (building on
the previous example with the potential configuration attribute):
v=0
o=- 24351 621814 IN IP4 128.96.41.2
s=
c=IN IP4 128.96.41.2
t=0 0
m=audio 4567 RTP/AVPF 0
a=acfg: c=1 p=2 a=1
It indicates that the answerer used an offer consisting of simcap
capability 1 (PCMU), transport protocol capability 2 (RTP/AVPF), and
transport address capability 1 (IPv4 address 128.96.41.1 and port
3456).
4.3. Offer/Answer Model Extensions
In this section, we define extensions to the offer/answer model
defined in [RFC3264] to allow for potential configurations to be
included in an offer, where they constitute offers that may be
accepted by the answerer instead of the actual configuration(s)
included in the "m=" line(s).
[Editor's Note: Multicast considerations have been omitted for
now.]
TO DO: Elaborate and firm up offer/answer procedures.
4.3.1. Generating the Initial Offer
An offerer that wants to use capability negotiation extensions
defined in this document MUST include the following in the offer:
o one or more simcap capability descriptions (as defined in
[RFC3407]) for each of the capabilities
o optionally, one or more transport protocol capability attributes
(as defined in Section 4.2.1. if one or more alternative transport
protocols is to be negotiated)
o optionally, one or more transport address capability attributes
(as defined in Section 4.2.2. if one or more alternative transport
addresses is to be negotiated)
Andreasen Expires December 19, 2006 [Page 22]
Internet-Draft SDP Capability Negotiation June 2006
o one or more potential configuration attributes (as defined in
Section 4.2.3. which define the potential configurations supported
by the offerer.
Each of the potential configurations listed constitutes an
alternative offer which may be used to negotiate and establish the
session. The current actual configuration is included in the "m="
line (as defined by [RFC3264]).
4.3.2. Generating the Answer
When the answerer receives an offer with one or more valid potential
configuration information attributes present, it may use any of the
potential configurations as an alternative offer. A potential
configuration information attribute is valid if all of the
capabilities (simcap, transport protocol and transport addresses) it
references are present and valid themselves.
The actual configuration is contained in the media description's "m="
line. The answerer can send media to the offerer in accordance with
the actual configuration, however if it chooses to use one of the
alternative potential configurations, media sent to the offerer may
be discarded by the offerer until the answer is received.
If the answerer chooses to accept one of the alternative potential
configurations instead of the actual configuration, the answerer MUST
generate an answer as if the offer contained that potential
configuration instead of the actual configuration included. The
answerer MUST also include an actual configuration attribute in the
answer that identifies the potential configuration from the offer
used by the answerer.
4.3.3. Offerer Processing of the Answer
When the offerer included potential configurations for a media
stream, it MUST examine the answer for the presence of an actual
configuration attribute for each such media stream. If the attribute
is missing, offerer processing of the answer MUST proceed as defined
by [RFC3264]. If the attribute is present, processing continues as
follows:
The actual configuration attribute specifies which of the potential
configurations was used by the answerer to generate the answer. The
offerer MUST now process the answer as if the offer had contained the
potential configuration indicated as the actual configuration in the
media description ("m=" line) in the offer.
Andreasen Expires December 19, 2006 [Page 23]
Internet-Draft SDP Capability Negotiation June 2006
4.3.4. Modifying the Session
Potential configurations may be included in subsequent offers as
defined in [RFC3264, Section 8]. The procedure for doing so is
similar to that described above with the answer including an
indication of the actual configuration used by the answerer.
5. Examples
TBD.
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. To Do
o Simcap allows for the same parameter to be described more than
once as a way of indicating alternative parameter values.
Whenever this is done, the answer must enable the offerer to
determine which of the alternatives was accepted. Similar
considerations apply to min and max values supported by simcap.
o Lots of other things noted throughout the document.
9. Acknowledgments
Thanks to Francois Audet and Dan Wing for comments on this document.
Andreasen Expires December 19, 2006 [Page 24]
Internet-Draft SDP Capability Negotiation June 2006
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October
2003.
[RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4567, June 2006.
10.2. Informative References
[RFC2046] Freed, N., and N. Borensteain, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 2327, April 1998.
[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.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
Andreasen Expires December 19, 2006 [Page 25]
Internet-Draft SDP Capability Negotiation June 2006
[RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", RFC 3551, July
2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network
Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework, RFC 4091, June 2005.
[AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)",
Work in Progress, August 2004.
[I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session
Initiation Protocol (SIP) Offer/Answer with Multipart
Alternative", Work in Progress, March 2006.
[SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)", Work in Progress,
December 2005.
[SDES] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol Security Descriptions for Media
Streams", Work in Progress, September 2005.
[SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description
and Capability Negotiation", Work in Progress, February
2005.
Author's Addresses
Flemming Andreasen
Cisco Systems
Edison, NJ
Email: fandreas@cisco.com
Andreasen Expires December 19, 2006 [Page 26]
Internet-Draft SDP Capability Negotiation June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Andreasen Expires December 19, 2006 [Page 27]
Internet-Draft SDP Capability Negotiation June 2006
Andreasen Expires December 19, 2006 [Page 28]
| PAFTECH AB 2003-2026 | 2026-04-23 20:26:44 |