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: We define the ALTC semantics token below. The is a list of 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]