MMUSIC WG M. Garcia-Martin Internet-Draft S. Veikkolainen Intended status: Standards Track Nokia Siemens Networks Expires: August 21, 2008 February 18, 2008 Describing CS audio streams in the Session Description Protocol (SDP) draft-garcia-mmusic-sdp-cs-00 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 August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo describes use cases and requirements for controlling circuit-switched media streams using the Session Description Protocol (SDP). Additional, it proposes conventions on how to use SDP and the SDP capability negotiation framework for agreeing on alternative media streams between the endpoints. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 1]
Internet-Draft CS audio streams in SDP February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. General Requirements . . . . . . . . . . . . . . . . . . . 4 3.2. Media-specific requirements . . . . . . . . . . . . . . . 5 4. Overview of operation . . . . . . . . . . . . . . . . . . . . 5 4.1. Example call flow . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 5.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Connection Data . . . . . . . . . . . . . . . . . . . 7 5.1.2. Media Descriptions . . . . . . . . . . . . . . . . . . 7 5.2. Offering alternative media streams . . . . . . . . . . . . 9 5.3. Determining the direction of the circuit-switched connection setup . . . . . . . . . . . . . . . . . . . . . 12 5.4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . 12 6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Basic SDP example: Single Circuit-Switched Audio Stream . 14 6.1.1. CS audio stream as an alternative to RTP . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1. Registration of a new "nettype" value . . . . . . . . . . 15 7.2. Registration of new "addrtype" values . . . . . . . . . . 15 7.3. Registration of a new "proto" value . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Design Alternatives . . . . . . . . . . . . . . . . . 17 A.1. Analysis of alternative conventions for describing circuit-switched audio media streams in SDP . . . . . . . 18 A.1.1. Grouping of media lines . . . . . . . . . . . . . . . 18 A.1.2. Alternative network types . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 2]
Internet-Draft CS audio streams in SDP February 2008 1. Introduction The Session Description Protocol (SDP) [RFC4566] is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP is most commonly used for describing media streams that are transported over the Real-Time Transport Protocol (RTP) [RFC3550], using the profiles for audio and video media defined in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551]. However, SDP can be used to describe other transport protocols than RTP. Previous work includes SDP conventions for describing ATM bearers [RFC3108] and the Message Session Relay Protocol [RFC4975]. SDP is commonly carried in Session Initiation Protocol (SIP) [RFC3261] messages in order to agree on a common media description among the endpoints. An Offer/Answer Model with Session Description Protocol (SDP) [RFC3264] defines a framework by which two endpoints can exchange SDP media descriptions and come to an agreement as to which media streams should be used, along with the media related parameters. In some scenarios it might be desirable to establish the media stream over a circuit-switched bearer even if the signaling for the session is carried over an IP bearer. An example of such a scenario is two mobile devices capable of both circuit-switched and packet-switched communication over a low-bandwidth radio bearer. The radio bearer may not be suitable for carrying real-time audio media, and using a circuit-switched bearer would offer a better perceived quality of service. So, according to this scenario, SIP is used over regular IP connectivity, while the audio is received through the classical circuit-switched bearer. Additional media streams, such as text messaging can also be used over the IP bearer. At a later point in time the mobile device might move to an area where a high-bandwidth packet-switched bearer, for example a Wireless Local Are Network (WLAN) connection, is available. At this point the mobile device may perform a handover and move the audio media streams over to the high-speed bearer. This implies a new exchange of SDP offer/answer that least to a re-negotiation of the media streams. Other use cases exists. For example, and endpoint might have at its disposal circuit-switch and packet-switched connectivity, but the audio codecs are not the same in both access networks. Consider that the circuit-switched audio stream supports narrow-bandwidth codecs, while the packet-switched access allows any other audio codec implemented in the endpoint. In this case, it might be beneficial Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 3]
Internet-Draft CS audio streams in SDP February 2008 for the endpoint to describe different codecs for each access type and get an agreement on the bearer together with the remote endpoint. The rest of the document is structured as follows: Section 2 provides the document conventions, Section 3 introduces the requirements, Section 4 presents an overview of the proposed solutions, and Section 5 contains the protocol description. Section 6 provide a few examples of descriptions of circuit-switched audio streams in SDP. Section 7 and Section 8 contain the IANA and Security considerations, respectively. 2. Document Conventions 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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 3. Requirements 3.1. General Requirements This section presents the general requirements that are specific for the circuit-switched audio media stream. REQ-GEN-1: A mechanism for endpoints to negotiate and agree on a circuit-switch bearer for audio media must be available. REQ-GEN-2: The mechanism must allow the endpoints to combine circuit-switched audio media streams with other complementary media streams, for example, text messaging. REQ-GEN-3: An endpoint might be able to offer an audio stream where the circuit-switched bearer is an alternative to the IP bearer, and vice versa. REQ-GEN-4: The mechanism must be backwards compatible with SDP [RFC4566] and the SDP Offer/Answer Model [RFC3264] in the sense that if an endpoint offers a description of a circuit-switched audio stream in addition to a classical RTP-based audio stream, and the other endpoint supports only the classical RTP, then both endpoints can agree on the RTP-based audio stream, according to the rules in SDP offer/answer [RFC3264], and communication may still be possible. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 4]
Internet-Draft CS audio streams in SDP February 2008 3.2. Media-specific requirements This section presents the requirements that are specific for the circuit-switched audio media. REQ-CS-1: It must be possible for endpoints to advertise a circuit- switch audio stream with a different list of audio codecs from those used in a packet-switched audio stream. REQ-CS-2: It must be possible for endpoints to not advertise the list of available codecs for circuit-switched audio streams. REQ-CS-3: There must be a mechanism that helps an endpoint to correlate an incoming CS call with the one negotiated in SDP, as opposed to another incoming call that is not related to that. 4. Overview of operation The mechanism defined in this memo extends SDP and allows describing a circuit-switched media stream in SDP. Since circuit-switched bearers are a sort of connection-oriented media streams, the mechanism re-uses the connection-oriented extensions defined in RFC 4145 [RFC4145] to negotiate the active and passive sides of a connection setup. The mechanism allows expressing an audio media stream with two separate bearers: a regular IP bearer using RTP [RFC3550] and a circuit-switched bearer. The endpoints agree on a given bearer and establish the media stream. 4.1. Example call flow Consider the example presented in Figure 1. In this example, Alice is located in an environment where she has access to both IP and circuit-switched bearers for communicating with other endpoints. Alice issues an SDP Offer containing two alternative audio media stream descriptions: one that uses a circuit-switched connection, and the other uses an IP bearer and RTP. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 5]
Internet-Draft CS audio streams in SDP February 2008 Alice Bob | (1) SDP Offer (RTP and CS audio) | |--------------------------------->| | | | (2) SDP Answer (CS audio) | |<---------------------------------| | | | cs call setup | |<---------------------------------| | | | | |<======media over cs bearer======>| | | Figure 1: Example flow Bob receives the SDP Offer and determines that he is located in an environment where the IP based bearer is not suitable for real-time audio media, but he has circuit-switched bearer available for audio. Bob sends back an SDP Answer where he selects the circuit-switched media stream description. During the offer-answer exchange Alice and Bob also agree the direction in which the circuit-switched connection should be established. The exchange also contained identifiers or references that can be used on the circuit-switched network for addressing the other endpoint, as well as identifying that the incoming circuit- switched connection establishment is related to the ongoing session between Alice and Bob. Bob establishes a circuit-switched connection towards Alice using whatever mechanisms are defined for the network type in question. When receiving the incoming circuit-switched connection attempt, Alice is able to determine that the attempt is related to the session she has with Bob. Alice accepts the circuit-switched connection, and the circuit- switched connection setup is completed. Bob and Alice can now use the circuit-switched connection for two-way audio media. 5. Protocol Description 5.1. Extensions to SDP This section provides the syntax and semantics of the extensions required for providing a description of circuit-switched streams in SDP. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 6]
Internet-Draft CS audio streams in SDP February 2008 5.1.1. Connection Data According to SDP [RFC4566], the connection data line in SDP has the following syntax: c=<nettype> <addrtype> <connection-address> where <nettype> indicates the network type, <addrtype> indicates the address type, and the <connection-address> is the connection address, which is dependent on the address type. At the moment, the only network type defined is "IN", which indicates Internet network type. The address types "IP4" and "IP6" indicate the type of IP addresses. This memo defines a new network type for describing circuit-switched network type. The mnemonic "CS" is used for this network type. For the address type, we initially consider the possibility of describing E.164 telephone numbers. We define a new "E164" address type. When used, the "E164" address type indicates that the connection address contains a telephone number represented according to the ITU-T E.164 [ITU.E164.1991] specification. There are cases, though, when the endpoint is merely aware of a circuit-switched bearer, without having further information about the address type or the E.164 number allocated to it. In these cases, we indicate with a dash "-" an unknown address type or connection address. This makes the connection data line be according to the SDP syntax. Note that <addrtype> and/or <connection-address> should not be omitted without being set to a "-" since this would violate basic syntax of SDP [RFC4566]. The following are examples of the extension to the connection data line: c=CS E164 +15551234 c=CS - - 5.1.2. Media Descriptions According to SDP [RFC4566], the media descriptions line in SDP has the following syntax: Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 7]
Internet-Draft CS audio streams in SDP February 2008 m=<media> <port> <proto> <fmt> ... The <media> sub-field carries the media type. Since this document deals with establishing an audio bearer, the currently defined "audio" media type is used. The <port> sub-field is the transport port to which the media stream is sent. Circuit-switched access lacks the concept of a port number. However, an endpoint might be capable of simultaneous circuit- switched connections, in which case, there is a need for an identifier so that the endpoint can have its own reference for correlation. The <port> sub-field serves the purpose. We use the <port> sub-field as a locally scoped circuit identification. In circuit-switched streams the <port> is a decimal number. Most endpoints are capable of a single circuit-switched bearer, thus, the decimal number "1" can be used. However, any other decimal number that is useful for the endpoint can be used as well. The <proto> sub-field is the transport protocol. The circuit- switched bearer uses whatever transport protocol it has available. This subfield SHOULD be set to the mnemonic "CS" to be syntactically correct with SDP [RFC4566] and to indicate the usage of circuit- switched protocols. The <fmt> sub-field is the media format description. When the <proto> sub-field is set to "RTP/AVP" or "RTP/SAVP", the <fmt> sub- field contains the payload types as defined in the RTP audio profile [RFC3551]. In the case of circuit-switched descriptions, RTP is not really used. Rather than specifying the RTP audio profile payload type, we use the <fmt> sub-field to indicate the list of available codecs over the circuit-switched bearer. Therefore, the <fmt> sub-field MAY indicate one or more available audio codecs for a circuit-switched audio stream. The namespace applicable to the <fmt> sub-field is composed of the union of the mnemonics listed in the "encoding name" column of the RTP Payload types for standard audio encodings and the "subtype" column in the RTP Payload Format media types in the RTP registry maintained by IANA. However, in some cases, the endpoint is not able to determine the list of available codecs for circuit-switched audio streams. In this case, in order to be syntactically compliant with SDP [RFC4566], the endpoint MUST include a single dash "-" in the <fmt> sub-field. As per RFC 4566 [RFC4566], the media format descriptions are listed in priority order. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 8]
Internet-Draft CS audio streams in SDP February 2008 Examples of media descriptions for circuit-switched audio streams are: m=audio 1 CS AMR GSM m=audio 1 CS - 5.2. Offering alternative media streams In many cases where circuit-switched audio streams are described in SDP it is foreseen that CS audio streams will be an alternative to regular RTP media streams. Therefore, it is reasonable to provide a mechanism to define a CS audio stream as an alternative to an RTP- based audio stream. To offer an audio media stream with alternative bearers for RTP and circuit-switched bearer, we reuse some of the capability attributes defined in SDP capability negotiation [I-D.ietf-mmusic-sdp-capability-negotiation] as well as in SDP media capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities]. Additionally, we define a new capability attribute "a=ccap" in this document that allows to express a connection address as a capabilities. The "a=mcap" media capability attribute defined in SDP media capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities] lists media formats as capabilities in the form a media type and one or more subtypes. An example provided in [I-D.ietf-mmusic-sdp-capability-negotiation] lists four audio media subtypes which are numbered consecutively (starting from 1 in this example). a=mcap:1 audio g729 iLBC PCMU g729 Similarly, we can use the a=mcap capability attribute to indicate media capabilities that correspond to the m-line described in Section 5.1.2. a=mcap:1 audio GSM AMR Here, we declare two media subtype capabilities with associated numbers 1 and 2, for GSM and AMR codecs, respectively. Transport Protocols can be expressed as capabilities by the "a=tcap" capability attribute defined in SDP capability negotiation [I-D.ietf-mmusic-sdp-capability-negotiation]. The "a=tcap" capability attribute lists one or more <proto> elements, defined in Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 9]
Internet-Draft CS audio streams in SDP February 2008 SDP [RFC4566]. An example of transport protocol capability indicating "CS" transport protocol defined in this document would thus be: a=tcap:1 CS In this document, we define a new capability attribute, the connection address capability attribute, "a=ccap". The connection address capability lists connection addresses as capabilities, and is defined as follows: a=ccap:<c-cap-num> <c-cap-attr> *[ <c-cap-attr>] where <c-cap-num> is an integer between 1 and 2^31-1 (both included) used to number the connection address capability attribute. The <c-cap-attr> field consists of network type, address type and a connection address, as specified for a "c=" line in SDP [RFC4566]. As an example, to list <nettype> value of "CS", <addrtype> value of "E164", and a <connection-address> value of "+15551234" as a connection capability attribute, we get: a=ccap:1 CS E164 +15551234 We also define an extension to the potential configuration attribute ("a=pcfg"), originally defined in SDP capabilities negotiation [I-D.ietf-mmusic-sdp-capability-negotiation], according to which the 'pcfg' attribute has the following definition: a=pcfg: <config-number> [<pot-cfg-list>] We extend the <pot-cfg-list> field to be able to convey one or more connection capability numbers.according to the following definition: pot-connection-config = "c=" c-cap-list *(BAR c-cap-list) c-cap-list = c-cap-num *("," c-cap-num) c-cap-num = 1*DIGIT ; BAR defined in SDP capabilities ; negotiation Each potential connection configuration is a comma-separated list of connection capability numbers where c-cap-num refers to connection capability numbers defined explicitly by a=ccap attributes and hence must be between 1 and 2^31-1 (both included). Alternative potential connection configurations are separated by a vertical bar ("|"). Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 10]
Internet-Draft CS audio streams in SDP February 2008 An exmple SDP consisting of two alternative media stream is as follows: v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s= t=0 0 m=audio 49170 RTP/AVP 0 8 3 c=IN IP4 10.47.16.5 a=mcap:1 audio GSM AMR a=tcap:1 CS a=ccap:1 CS - - a=pcfg:1 m=1|2 t=1 c=1 Figure 2: Example SDP with alternative media streams In this example, the SDP defines a media capability 1 (a=mcap:1) that uses audio media using GSM codec and an alternative media capability 2 that uses AMR, a transport capability 1 that defines CS protocol type, as well as a connection capability 1 (a=ccap:1) that defines a CS network type for the capability, and omits the connection address. The potential configuration 1 consist of the media capabilities 1 or 2, transport protocol capability 1, and connection capability 1. This is also the preferred configuration. Note that according to the SDP capabilities negotiation framework the potential configurations are preferred over the actual configurations. In some use cases the offerer may want to offer two media streams as truly alternatives, and not prefer one over the other. Further consideration is needed to determine how this is accomplished. An exmple SDP answer to the offer presented in Figure 2 where CS audio has been selected as the actual configration is as follows: v=0 o=- 2890973824 2890987289 IN IP4 10.47.16.7 s= t=0 0 a=csup:med-v0 m=audio 1 CS AMR c=CS - - a=acfg:1 Figure 3: Example SDP answer with CS audio media selected Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 11]
Internet-Draft CS audio streams in SDP February 2008 The answer contains the "a=csup" and "a=acfg" attributes to indicate that the answerer supports the med-v0 level of capability negotiations as defined in SDP media capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities]. The answer carries the accepted configuration in the m and c lines. 5.3. Determining the direction of the circuit-switched connection setup The circuit-switched connection can typically be initiated by either endpoint. In order to avoid a situation where both endpoints attempt to initiate a connection simultaneously, the direction in which the circuit-switched connection is set up should be negotiated during the Offer/Answer exchange. The framework defined in TCP-Based Media Transport in the Session Description Protocol (SDP) [RFC4145] allows the endpoints to agree which endpoint acts as the active endpoint when initiating a TCP connection. The "setup" attribute defines which endpoint is the active party and which one is the passive in setting up the circuit- switched media stream. The "connection" attribute indicates whether a new connection is needed, or an existing connection is reused. While RFC 4145 was originally designed for establishing TCP connection, it could be extended to allow other types of connections as well, or, alternatively, a new mechanism based on the ideas presented in RFC4145 could be developed for the purposes of negotiating the direction of the circuit-switched connection. 5.4. Formal syntax The following is the formal Augmented Backus-Naur Form (ABNF) [RFC4234] syntax that supports the extensions defined in his specification. The syntax is built above the SDP [RFC4566] grammar and the SDP capability negotiation [I-D.ietf-mmusic-sdp-capability-negotiation]. Implementations according to this specification MUST implement this syntax. ; sub-rules of 'c=' connection-field = [%x63 "=" nettype SP addrtype SP connection-address CRLF] ;a connection field must be present ;in every media description or at the ;session-level nettype = token ;typically "IN" ;"CS" added by this spec Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 12]
Internet-Draft CS audio streams in SDP February 2008 addrtype = token ;typically "IP4" or " ;"E164" and "-" added by this spec connection-address = multicast-address / unicast-address / telephone-number ; added by this spec telephone-number = token ;token specified in RFC 4566 media-field = %x6d "=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF ; sub-rules of 'm=' media = token ;typically "audio", "video", "text", or ;"application" fmt = token ;typically an RTP payload type for audio ;and video media ;codec mnemonics used by this specification proto = token *("/" token) ;typically "RTP/AVP" or "udp" ;"CS" added by this specification port = 1*DIGIT ;subrules for the media capabilities negotiation attribute = ccapattr ccapattr = "ccap:" c-cap-num SP c-cap-attr c-cap-num = 1*DIGIT c-cap-attr = connection-field ;subrules for the potential configuration attribute pot-config = pot-conn-config ; pot-config defined in SDP capability negotiation pot-conn-config = "c=" c-cap-list *(BAR c-cap-list) ; BAR defined in SDP capability negotiation c-cap-list = c-cap-num *("," c-cap-num) Figure 4: Syntax of the SDP extension Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 13]
Internet-Draft CS audio streams in SDP February 2008 6. SDP Examples 6.1. Basic SDP example: Single Circuit-Switched Audio Stream Figure 5 shows a basic example that describes a single audio stream over a circuit-switched bearer. The endpoint describes as the circuit with reference "1" where it can provide the AMR and GSM codecs. It also indicates that it can initiate the circuit-switched connection or be the recipient of it. v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s= t=0 0 m=audio 1 CS AMR GSM c=CS - - a=setup:actpass a=connection:new Figure 5: Basic SDP example 6.1.1. CS audio stream as an alternative to RTP Figure 6 provides an exmple of SDP consisting of two alternative audio media streams, one using RTP over an IP bearer, the other using a CS bearer. The SDP offerer describes the PCMU, PCMA, and GSM payload types for RTP usage and the GSM and AMR codecs for CS audio. It also indicates that can initiate or receive the CS connection. v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s= t=0 0 m=audio 49170 RTP/AVP 0 8 3 c=IN IP4 10.47.16.5 a=mcap:1 audio GSM AMR a=tcap:1 CS a=ccap:1 CS - - a=pcfg:1 m=1|2 t=1 c=1 a=setup:actpass a=connection:new Figure 6: Example of an SDP offer with alternative media streams The SDP answerer replies with the SDP of Figure 7 where the CS audio stream is selected. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 14]
Internet-Draft CS audio streams in SDP February 2008 v=0 o=- 2890973824 2890987289 IN IP4 10.47.16.7 s= t=0 0 a=csup:med-v0 m=audio 1 CS AMR c=CS - - a=acfg:1 a=setup:active a=connection:new Figure 7: Example of an SDP answer with CS audio media selected 7. IANA Considerations This document instructs IANA to register a number of SDP tokens according to the following data. 7.1. Registration of a new "nettype" value This memo provides instructions to IANA to register a new "nettype" in the Session Description Protocol Parameters registry [1]. The registration data, according to RFC 4566 [RFC4566] follows. Type SDP Name Reference ---- ------------------ --------- nettype CS [RFCxxxx] 7.2. Registration of new "addrtype" values This memo provides instructions to IANA to register a new "addrtype" in the Session Description Protocol Parameters registry [1]. The registration data, according to RFC 4566 [RFC4566] follows. Type SDP Name Reference ---- ------------------ --------- addrtype E164 [RFCxxxx] - [RFCxxxx] 7.3. Registration of a new "proto" value This memo provides instructions to IANA to register a new "proto" in the Session Description Protocol Parameters registry [1]. The registration data, according to RFC 4566 [RFC4566] follows. Type SDP Name Reference -------------- --------------------------- --------- Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 15]
Internet-Draft CS audio streams in SDP February 2008 proto CS [RFCxxxx] 8. Security Considerations TBD. 9. Acknowledgments The authors want to thank Thomas Belling, Jari Mutikainen, and Miikka Poikselka for providing a discussion and comments on preliminary versions of this document. 10. References 10.1. Normative References [I-D.ietf-mmusic-sdp-capability-negotiation] Andreasen, F., "SDP Capability Negotiation", draft-ietf-mmusic-sdp-capability-negotiation-08 (work in progress), December 2007. [I-D.ietf-mmusic-sdp-media-capabilities] Gilman, R., Even, R., and F. Andreasen, "SDP media capabilities Negotiation", draft-ietf-mmusic-sdp-media-capabilities-02 (work in progress), November 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 16]
Internet-Draft CS audio streams in SDP February 2008 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 10.2. Informative References [ITU.E164.1991] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU- T Recommendation E.164, 1991. [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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [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. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. URIs [1] <http://www.iana.org/assignments/sdp-parameters> Appendix A. Design Alternatives NOTE: This Appendix provides an analysis of the alternatives that were considered. The intention is to provide background information to the reader. Eventually, this Appendix should be removed from the specification. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 17]
Internet-Draft CS audio streams in SDP February 2008 A.1. Analysis of alternative conventions for describing circuit- switched audio media streams in SDP A.1.1. Grouping of media lines An alternative way of indicating alternative media streams could be based on Grouping of Media Lines in the Session Description Protocol (SDP) [RFC3388]. RFC3388 defines two new attributes o a=mid (media stream identification) o a=group (group creation) The media grouping semantics are defined in the a=group line. Currently two semantics are defined: LS (Lip Synchronization) and FID (Flow Identification). While defining additional semantics is allowed by a standards-track document, RFC3388 explicitly discourages additional semantics and proposes to use other session description mechanisms, such as SDPng. Several "m" lines that are grouped together with the FID attribute form a media flow. A flow consists of media streams which logically belong together, like an audio stream, a video stream and whiteboard sharing for an online meeting. Another example presented in RFC3388 is audio media using two or more codecs which can be dynamically changed during the session's lifetime. This can be beneficial is some environments, for example when the multimedia session is carried over a cellular radio network, which may use separate port numbers and separate bearers for different codecs. An example SDP provided in RFC3388 presents a configuration where two codecs are grouped using the FID attribute. The semantics of the FID attribute define that whenever there is media to be sent using a specific codec, and that codec is part of the flow and the direction attribute is "sendonly" or "sendrecv" then media is copied to that specific stream. RFC3388 further states that if a codec is not used, or the direction attribute is neither "sendonly" nor "sendrecv", then media is "muted". Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 18]
Internet-Draft CS audio streams in SDP February 2008 v=0 o=Laura 289083124 289083124 IN IP4 two.example.com t=0 0 c=IN IP4 131.160.1.112 a=group:FID 1 2 m=audio 30000 RTP/AVP 3 a=rtpmap:3 GSM/8000 a=mid:1 m=audio 30002 RTP/AVP 97 a=rtpmap:97 AMR/8000 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-neighbor; maxframes=1 a=mid:2 Figure 8: Example SDP according to RFC 3388 While this would seem like an appropriate use case for using circuit- switched bearer as an alternative for RTP, there is one difference. Even though FID grouping allows media to be sent alternatively on difference ports depending on the codec used, the assumption is that the underlying bearer is established at the time of session initiation. For our purposes, the circuit-switched and RTP based bearers are alternatives in the sense that once one is selected during Offer/ Answer exchange, the other one is not established. For example, if the endpoints agree to use circuit-switched bearer for he audio media, no resources are reserved in the IP domain. A.1.2. Alternative network types The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework [RFC4091] defines additional semantics for the media grouping framework. The ANAT semantics provide alternative network addresses of different types for a single logical media stream. The primary use case is to offer alternative addresses, one from IPv4 address space, and the other from IPv6 address space. The idea of ANAT could be extended for provide alternative network types (ANT). ANT semantics defines that the media streams offered are alternatives on the network type level. An example SDP showing alternative network types is presented in Figure 9 below. Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 19]
Internet-Draft CS audio streams in SDP February 2008 v=0 o=bob 280744730 28977631 IN IP4 host.example.com s= t=0 0 a=group:ANT 1 2 m=audio 25000 RTP/AVP 0 c=IN IP6 2001:DB8::1 a=mid:1 m=audio 1 CS gsm amr c=CS a=mid:2 Figure 9: Example of SDP with alternative network types Authors' Addresses Miguel Garcia-Martin Nokia Siemens Networks P.O. Box 6 Nokia Siemens Networks, FIN 02022 Finland Phone: +358 50 480 4586 Email: miguel.garcia@nsn.com Simo Veikkolainen Nokia Siemens Networks P.O. Box 6 Nokia Siemens Networks, FIN 02022 Finland Phone: +358 50 486 4463 Email: simo.veikkolainen@nsn.com Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 20]
Internet-Draft CS audio streams in SDP February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 21]