MMUSIC Working Group
Internet Draft M. Bhatia
Expires: January 10, 2005 J. Oliver
NexTone Communications
July 12, 2004
Alternate Simultaneous Capabilities and Offers in the Session
Description Protocol (SDP)
draft-bhatia-mmusic-sdp-altcap-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines Session Description Protocol (SDP) attributes
and semantics to express alternate capabilities and offers. The
attribute "cgroupö is defined to express alternate simultaneous sets
of capabilities. The ôALTSö semantics are defined to express specific
alternate simultaneous offers. Existing methods like the MIME
multipart/alternative subtype and the use of multiple session
descriptions in SDP are also discussed.
Bhatia & Oliver Expires û January 10, 2005 [Page 1]
Alternate Capabilities and Offers for SDP July 2004
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. The need for expressing alternate simultaneous capabilities....3
4. Requirements and considerations for mechanisms to specify
simultaneous alternate capabilities...............................3
5. The ALTS semantics for constructing alternate simultaneous offers
..................................................................4
5.1 Specifying preference among alternate offers...............4
5.2 Offer/Answer and ALTS......................................4
5.3 Example of ALTS............................................4
6. The ôcgroupö attribute for grouping capabilities...............5
7. The ALTC semantics for expressing alternate simultaneous
capabilities......................................................5
7.1 Specifying preference among alternate capabilities.........6
8. The MIME multipart/alternative subtype.........................6
9. Security Considerations........................................7
10. IANA Considerations...........................................8
11. References....................................................8
11.1 Informative References....................................8
11.2 Normative References......................................9
Author's Addresses................................................9
Copyright Statement...............................................9
1. Introduction
The SDP framework as specified in RFC 2327 [5] has limitations for
expressing capabilities and complex relationships which can exist
among media types while constructing an offer. Several efforts have
been made in this regard. RFC 3407 [9] defines a method to express
simple capabilities and RFC 3388 [7] defines a means to express
relationship among media lines. Definition of methods to express
alternate simultaneous capabilities and offers has been moved into
the SDPng framework [3].
For brevity, we will use the following terms to speak of these two
problems:
AltOffer: A mechanism capable of representing alternate simultaneous
offers
AltCap: A mechanism capable of representing alternate simultaneous
capabilities.
We feel that there is a need to address these issues in the current
SDP framework and its extensions. While these issues may warrant
separate documents eventually, we start by presenting three methods
Bhatia & Oliver Expires - January 10, 2005 [Page 2]
Alternate Capabilities and Offers for SDP July 2004
for discussion by the internet community. The three methods we
propose are based on the following:
1. Definition of a grouping framework for capabilities. We define a
ôcgroupö attribute for capabilities similar to the ôgroupö
attribute defined in RFC 3388 [7] for media lines. This
addresses the AltCap problem.
2. Semantics based on grouping framework for media lines defined in
RFC 3388 [7]. This addresses the AltOffer problem.
3. The MIME multipart/alternative subtype in protocols such as SIP
[6]. This is a scenario where the syntax exists, and the
offer/answer semantics need to be extended to specify behavior.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. The need for expressing alternate simultaneous capabilities
1. SDPng and its scope: While the scope of the SDPng effort is
substantial, ôSDPng is not anticipated to be backwards
compatible with SDP and work on SDPng is currently in the early
stages. Several other protocols, e.g. SIP [6] and Media Gateway
Control Protocol (MGCP) [2], use SDP and are likely to continue
doing so for the foreseeable future. In many cases these
signaling protocols have an urgent need for some limited form of
capability negotiationö RFC 3407 [9].
2. Support of similar feature in other protocols: H.245 [4] used by
the H.323 suit of protocols allows elaborate mechanisms for
endpoints to be able to specify constraints on capabilities and
offers. We feel that using SDP, these endpoints should be able
to achieve the same level of functionality.
3. Interworking between SDP and H.245: As carriers are increasingly
adopting SIP [6], it becomes pertinent that Interworking between
these protocols is possible to the extent that existing
functionality is not lost, but only improved. Alternate
simultaneous capabilities allow for optimal call setup both in
terms of resource usage on the caller as well as quality of
media traffic received by the called party.
4. Requirements and considerations for mechanisms to specify
simultaneous alternate capabilities
Bhatia & Oliver Expires - January 10, 2005 [Page 3]
Alternate Capabilities and Offers for SDP July 2004
Before we come up with extensions to SDP to specify these mechanisms,
it is worthwhile to summarize the requirements such mechanisms should
satisfy:
The mechanism MUST be compatible with existing implementations based on RFC
RFC 3264 [8] and RFC 2327 [5]. Newer implementations which use such a
mechanism must be able to complete calls with existing implementations which
are based on these specifications.
5. The ALTS semantics for constructing alternate simultaneous offers
We define a new semantics attribute within the SDP grouping framework
[7]: ALTS. This attribute addresses the AltOffer problem.
Each set of media lines grouped using the ALTS semantics provides an
alternative offer for establishing a session. Media lines within a
group provide a simultaneous offer. An entity constructing an offer
based on these semantics MUST be ready to receive (or send) media
over any set of the grouped m= lines.
5.1 Specifying preference among alternate offers
An offer may contain several groups of media lines grouped using the
ALTS semantics. The order in which the ôgroupö session level
attribute appears in the offer specifies a decreasing level of
preference among the alternate offers.
The order of identifiers of media streams within a group line does
not specify any order of preference relevant among the alternate
offers.
5.2 Offer/Answer and ALTS
An offerer using SIP [6] to send its offer SHOULD place the sdp-
session option-tag [WIP] in a Require header field.
An answerer receiving a session description that uses the ALTS
semantics MUST set the ports of m= lines in all groups besides the
group it accepts to zero.
The answerer may use locally defined policy and available bandwidth
as well as the callerÆs order of preference when making the decision
as to which group to pick for the answer.
5.3 Example of ALTS
The following SDP represents two alternate offers: {1,2} representing
{G.711, H.261} and {3,4} representing {G.729, H.262}. In this case
Bhatia & Oliver Expires - January 10, 2005 [Page 4]
Alternate Capabilities and Offers for SDP July 2004
the endpoint intends to operate the H.262 codec only with a low
complexity codec G.711 codec.
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
t=0 0
a=group:ALTS 1 2
a=group:ALTS 3 4
m=audio 6886 RTP/AVP 0
c=IN IP6 2001:0600::1
a=mid:1
m=audio 22334 RTP/AVP 18
c=IN IP4 192.0.2.2
a=mid:3
m=video 9000 RTP/AVP 34
c=IN IP4 192.0.2.2
a=rtpmap:34 .....
a=mid:2
m=video 9001 RTP/AVP 35
c=IN IP4 192.0.2.2
a=rtpmap:35 .....
a=mid:4
6. The ôcgroupö attribute for grouping capabilities
A new "cgroup" session-level attribute is defined. It is used for
grouping together different capability attributes as specified in RFC
3407 [9]. A group attribute is of the form:
a=cgroup: <semantics-token> <cap-num-list>
We define the ALTC semantics token below. The <cap-num-list> is a
list of <cap-num> as specified in RFC 3407 [9] for each capability in
a capability attribute line.
7. The ALTC semantics for expressing alternate simultaneous capabilities
An application that receives SDP containing capabilities grouped
together by the ALTC semantics should treat capabilities within each
group as simultaneous and the groups themselves as alternate to each
other.
For example:
Bhatia & Oliver Expires - January 10, 2005 [Page 5]
Alternate Capabilities and Offers for SDP July 2004
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
a=cgroup: ALTC 1 3
a=cgroup: ALTC 2 4
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0
a=cdsc: 2 audio RTP/AVP 18
m=video 3458 RTP/AVP 31
a=cdsc: 3 video RTP/AVP 31
a=cdsc: 4 video RTP/AVP 34
7.1 Specifying preference among alternate capabilities
The order in which the cgroup lines appear in the SDP specifies the
decreasing order of preference among the capabilities.
8. The MIME multipart/alternative subtype
For protocols such as SIP [6], the MIME multipart/alternative
approach is a method to include alternate sets of offers. An example
of such an offer is:
Content-Type: multipart/alternative; boundary=ÆxxxÆ
--xxx
Content-Type: application/sdp
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/AVP 0
m=video 3458 RTP/AVP 31
--xxx
Content-Type: application/sdp
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/AVP 18
m=video 3458 RTP/AVP 34
Bhatia & Oliver Expires - January 10, 2005 [Page 6]
Alternate Capabilities and Offers for SDP July 2004
--xxxù
The order in which the message bodies occur also specifies the
increasing order of preference for the offerer.
All message bodies are returned by the answerer, with port number = 0
in SDPs which are not accepted. Any media streams within an
individual SDP may also be rejected by setting the port number to 0,
as per RFC 3264 [8]. For example:
Content-Type: multipart/alternative; boundary=ÆxxxÆ
--xxx
Content-Type: application/sdp
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 49000 RTP/AVP 0
m=video 59000 RTP/AVP 31
--xxx
Content-Type: application/sdp
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 0 RTP/AVP 18
m=video 0 RTP/AVP 34
--xxx--
This method could potentially also be use to specify alternate sets
of capabilities
9. Security Considerations
It is STRONGLY RECOMMENDED that integrity protection be applied to
the SDP session descriptions. For session descriptions carried in SIP
[6], S/MIME is the natural choice to provide such end-to-end
integrity protection, as described in RFC 3261 [6]. Other
applications MAY use a different form of integrity protection
Bhatia & Oliver Expires - January 10, 2005 [Page 7]
Alternate Capabilities and Offers for SDP July 2004
10. IANA Considerations
This document defines one SDP attribute: "cgroup".
The "cgroup" attribute is used for grouping together different media
capabilities and its format is defined in Section 6.
This document defines a framework to group media lines in SDP using
different semantics. Semantics to be used with this framework are
registered by the IANA when they are published in standards track
RFCs.
The IANA Considerations section of the RFC MUST include the following
information, which appears in the IANA registry along with the RFC
number of the publication.
o A brief description of the semantics.
o Token to be used within the group attribute. This token may be
of any length, but SHOULD be no more than four characters long.
Reference to an standards track RFC.
The only entry in the registry for the time being is:
Semantics Token Reference
------------------- ----- -----------
Alternate Capabilities ALTC RFC XXXX
IANA needs to register the following new ``semantics'' attribute for
the SDP grouping framework [7]:
Semantics Token Reference
------------------- ----- ---------
Alternate Sessions ALTS RFCxxxx
It should be registered in the SDP parameters registry (http://
www.iana.org/assignments/sdp-parameters) under Semantics for the
"group" SDP Attribute.
11. References
11.1 Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
"Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
October 1999.
Bhatia & Oliver Expires - January 10, 2005 [Page 8]
Alternate Capabilities and Offers for SDP July 2004
[3] Dirk Kutscher, Joerg Ott, Carsten Bormann, "Session Description
and Capability Negotiation", Internet Draft draft-ietf-mmusic-
sdpng-06.txt, Work in Progress, March 2003.
[4] ITU-T Recommendation H.245, Control Protocol for Multimedia
Communication, July 2000.
11.2 Normative References
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] 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.
[7] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] F. Andreasen, ôSession Description Protocol (SDP) Simple
Capability Declarationö, RFC 3407, October 2002.
Author's Addresses
Medhavi Bhatia
NexTone Communications
101 Orchard Ridge Drive
Gaithersburg, MD 20878
Email: mbhatia@nextone.com
John Oliver
NexTone Communications
101 Orchard Ridge Drive
Gaithersburg, MD 20878
Email: joliver@nextone.com
Copyright Statement
Copyright (C) The Internet Society (2004). 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."
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
Bhatia & Oliver Expires - January 10, 2005 [Page 9]
Alternate Capabilities and Offers for SDP July 2004
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."
Bhatia & Oliver Expires - January 10, 2005 [Page 10]