Network Working Group I. Johansson Internet-Draft Ericsson AB Intended status: Standards Track Feb 10, 2009 Expires: August 14, 2009 Setup of Asymmetric Media with SDP draft-johansson-mmusic-asymmetric-media-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 14, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This draft proposes an extension to the SDP Capability Negotiation framework for the setup of asymmetric sessions. One example of an Johansson Expires August 14, 2009 [Page 1] Internet-Draft Asymmetric Media with SDP Feb 2009 asymmetric session is a conversational video session between a handset with a small screen (high-resolution camera) and a home- entertainment set-top box connected to a wide-screen TV. Another example is tightly coupled conferences with different number of in and outgoing streams for each client. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Asymmetric Media Format (Audio) . . . . . . . . . . . . . 7 4.2. Asymmetric Media Format (Video) . . . . . . . . . . . . . 8 4.3. Asymmetric Number of Streams . . . . . . . . . . . . . . . 10 5. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Payload Formats that Supports Asymmetry . . . . . . . . . 13 5.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 14 5.3. Bidirectional Attributes . . . . . . . . . . . . . . . . . 14 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Johansson Expires August 14, 2009 [Page 2] Internet-Draft Asymmetric Media with SDP Feb 2009 1. Introduction This draft describes a new session setup attribute to be used when negotiating various asymmetric session setups such as tightly coupled multiparty multimedia sessions or other situations where the participants may have different properties or requirements. The different properties are: o Number of concurrent streams (up and downlink): This may be limited by either the link bandwidth or by the processing capacity in the terminal. o Number of input/output channels: Depending on e.g user setup and rendering capabilities, a device may be setup for mono or multichannel audio output. Furthermore a client may have one microphone or a set of microphones in a conference room. o Different quality requirements in each direction: One extreme use case could be a mobile user communicating with a peer who is connected to a 50" TV set. In one direction a video bitrate of 500kbps with CIF resolution may be sufficient while in the other direction a bitrate of 5Mbps and 16CIF resolution may be desirable. o Different other properties in the two directions: An extreme case may be different connections or QoS mechanisms in the two directions In order to work, the proposed schema strives to isolate the send and receive directions where needed and possible. For obvious reasons various multicast scenarios are excluded. The framework builds upon the SDP Capability Negotiation framework [SDPCapNeg] and the SDP Media capabilities extension [SDPMedCapNeg] meaning that it does not work with legacy SDP syntax alone. Moreover the framework goes against some of the design principles in [SDPCapNeg]. 2. Conventions, Definitions and Acronyms 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 RFC 2119. A few buzzwords in this doc. Johansson Expires August 14, 2009 [Page 3] Internet-Draft Asymmetric Media with SDP Feb 2009 o Configuration : Could be potential, latent or actual configuration as described in SDPCapNeg and SDPMedCapNeg. 3. Description To be able to negotiate the media in each direction [SDPCapNeg] with [SDPMedCapNeg] are extended with a set of different features described below: o The m= parameter is extended with a numerator which defines the number of streams of the same media. For instance "m=1(3),2(1)" depicts 3 streams of media 1 and 1 stream of media 2. Furthermore the bandwidth modifiers as defined in [RFC3550] and [RFC3890] can be appended for more efficient bandwidth description than "a=bcap" defined in [SDPMiscCapNeg]. Thus "m=1(3),2(1),AS:200" adds the information that the bandwidth for this particular alternative is 200kbps. o A new option tag asym-v0 is introduced, it is RECOMMENDED to put this option tag only on the potential, latent and actual configurations that actually exploits the extension defined in this memo. o Two new parameters "send" and "recv" are introduced, these defines the direction of the parameters that follow. An example pcfg line may look like "a=pcfg:1 send t=1 m=1(3),2(1),AS:200 pt=1:96,2:97 recv t=1 m=2,AS:80 pt=2:97" o A selected potential configuration using the extension is not realizable using legacy SDP syntax. This means that the requirement in SDPCapNeg that the legacy SDP part of an SDP answer MUST reflect the selected potential configuration as legacy SDP is changed into a MUST NOT when the option tag asym-v0 is specified. o A consequence of the fact that the extension is no longer realizable using legacy SDP syntax is that parameters that are described in the attributes defined by SDPCapNeg and its extensions need to be modified. One example in the H.264 case is sprop-parameter-sets that is wrapped in the "a=mfcap" attribute by the SDPMedCapNeg extension. The text below defines the necessary modifications to the [SDPCapNeg] framework and the [SDPMedCapNeg] extension. Parts are stolen with pride from the said drafts. We define the (modified) media configuration parameter, media-config- Johansson Expires August 14, 2009 [Page 4] Internet-Draft Asymmetric Media with SDP Feb 2009 list, in accordance with the following format: ---- m= *["|"] media-config-list = "m=" med-cap-list *(BAR med-cap-list) ; BAR is defined in [SDPCapNeg] med-cap-list = med-cap-id *("," med-cap-id) *("," bw-mod) med-cap-id = med-cap-num [ "(" med-cap-n-str ")" ] med-cap-num = 1*DIGIT[ ; defined in SDP med-cap-n-str = 1*DIGIT[ ; defined in SDP bw-mod = bandwidth modifiers as described in [RFC3550] and [RFC3890]. The modifiers MUST be of the form : ---- med-cap-num is defined in [SDPMedCapNeg]. med-cap-n-str defines the number of streams with the given med-cap-num. If med-cap-n-str is omitted a default value of 1 is assumed. bw-mod are the bandwidth modifiers as described in [RFC3550] and [RFC3890]. We add the direction parameters "send" and "recv" to the potential, actual and latent configurations defined in [SDPCapNeg] and [SDPMedCapNeg]. The ABNF for the potential configuration will then look like : ---- a=pcfg: "+asym-v0" 1*WSP ["send"/"recv" 1*WSP] [] *[1*WSP "send"/"recv" 1*WSP ] or for the special symmetric case. a=pcfg: "+asym-v0" 1*WSP [] for comparison SDPCapNeg (section 3.5.1) specifies: a=pcfg: [] ---- Similar for the latent and actual configurations. Note that only one occurrence each of "send" and "recv" is allowed for each potential configuration. Note that it is possible to use the extended format in a symmetric setup as well. Some observations: o For simplicity and to avoid repetitions, the pt= parameter(s) MAY be placed in the very beginning of the potential configuration, the pt= parameter(s) then applies to both send and recv Johansson Expires August 14, 2009 [Page 5] Internet-Draft Asymmetric Media with SDP Feb 2009 directions. o It is RECOMMENDED to put the option tag for this extended formulation on each configuration that makes use of it, this makes it possible to define fallback configurations in case the extension described in this draft is not supported by the endpoints or intermediary nodes. An offer may look like ---- a=tcap:1 RTP/AVPF a=creq:med-v0 m=audio 5000 RTP/AVP 98 a=rtpmap:98 AMR-WB/16000/1 a=mcap:1 AMR-WB/16000/1 a=mcap:2 AMR-WB/16000/2 a=bcap:1 AS:40 b=RS:0 b=RR=2000 a=pcfg:1 +asym-v0 \ send t=1 m=1(3),2,AS:200|1(2),2,AS:160|1,2,AS:120 pt=1:96,2:97 \ recv t=1 m=1,AS:40 pt=1:96 a=pcfg:2 t=1 m=1 b=1 pt=1:96 ---- Meaning that the offerer can send 3, 2, 1 mono streams and 1 stereo stream, while it wish to receive only one mono stream. The alternative with the highest number of streams has the highest priority as per rules defined in SDPCapNeg. Note also that the last potential configuration does not use the extended asymmetry formulation, it serves as a fallback (symmetric) configuration for the case that the extension defined in this memo is not supported. [Ed. Note : It is possible to use the a=bcap and b= formulation as well, the problem is then that it is necessary to define several potential configurations. In some cases like different connections or transports it may be the only good solution however] Am SDP answer may look like ---- m=audio 5000 RTP/AVP 98 a=csup:med-v0,bcap-v0,asym-v0 a=rtpmap:98 AMR-WB/16000/1 b=RS:0 b=RR=2000 a=acfg:1 +asym-v0 recv t=1 m=1(2),2,AS:160 pt=1:96,2:97 \ send t=1 m=1,AS:40 pt=1:96 ---- Johansson Expires August 14, 2009 [Page 6] Internet-Draft Asymmetric Media with SDP Feb 2009 Indicating that the answerer wish to receive 2 mono and 1 stereo stream and send 1 mono stream [Ed. Note: It seems reasonable that the bandwidth specifiers override the "legacy SDP" bandwidth specifiers for their respective direction. The implications of this is however not fully clear. For backwards compatibility reasons the applicable bandwidth modifiers (e.g) "b=AS:..." SHOULD be specified as legacy SDP parameters as well. It seems in this case reasonable to specify the worst case from the listed payload types (TBD).] The media direction attribute can inter operate with the a=sendrecv/ sendonly/recvonly/inactive attributes in the way that the former controls what is transmitted in the two directions while the latter controls if any media should be transmitted in a particular direction. This means that an "a=sendonly" attribute overrides any recv direction specification for the configuration, in other words these attributes serves as a "mains switch" for media in the two directions. 4. Use cases The following subsections describe different use cases for the new asymmetry extension. 4.1. Asymmetric Media Format (Audio) The number of channels for a given user may differ in the two directions. As an example a user may use a mono-microphone and stereo headphones. In this case it is preferable to set up a mono stream in one direction and a stereo stream in the other direction. Assume that node C has the capability of receiving in stereo but only transmitting in mono, and node M can both send and receive in stereo. Node C then sends the SDP offer Johansson Expires August 14, 2009 [Page 7] Internet-Draft Asymmetric Media with SDP Feb 2009 ---- a=tcap:1 RTP/AVPF m=audio 5000 RTP/AVP 96 a=creq:med-v0,bcap-v0 a=rptmap:96 AMR-WB/16000/1 a=mcap:1 AMR-WB/16000/1 a=mcap:2 AMR-WB/16000/2 b=RS:0 b=RR=2000 a=bcap:1 AS:40 a=pcfg:1 +asym-v0 \ recv t=1 m=2,AS:80|1,AS:40 pt=1:96,2:97 \ send t=1 m=1,AS:40 pt=1:96 a=pcfg:2 t=1 m=1 b=1 pt=1:96 ---- Node M recognizes these attributes and sends the SDP answer ---- m=audio 5000 RTP/AVP 96 a=csup:med-v0,bcap-v0,asym-v0 a=rptmap:96 AMR-WB/16000/1 b=RS:0 b=RR=2000 a=acfg:1 +asym-v0 \ send t=1 m=2,AS:80 pt=2:97 recv t=1 m=1,AS:40 pt=1:96 ---- and the RTP communication may be started. Optionally it is possible that M does not support stereo, the answer SDP would then look like. ---- m=audio 5000 RTP/AVP 96 a=csup:med-v0,bcap-v0,asym-v0 a=rptmap:96 AMR-WB/16000/1 b=RS:0 b=RR=2000 a=acfg:1 +asym-v0 \ send t=1 m=1,AS:40 pt=1:96 recv t=1 m=1,AS:40 pt=1:96 ---- 4.2. Asymmetric Media Format (Video) An interesting use case is a situation where it is desired to run video with very different bitrates (or even different codecs) in the two directions, one such example SDP would look like: Johansson Expires August 14, 2009 [Page 8] Internet-Draft Asymmetric Media with SDP Feb 2009 ---- a=tcap:1 RTP/AVPF m=video 49154 RTP/AVP 99 a=creq:med-v0 a=rtpmap:99 H263-2000/90000 a=mcap:1 MP4V-ES/90000 a=mfcap:1 profile-level-id=3;config=config-par-1 a=mcap:2 H263-2000/90000 a=mfcap:2 profile=0;level=45 a=bcap:1 AS:500 a=pcfg:1 +asym-v0 send t=1 m=1,AS:2000|2,AS:500 pt=1:96,2:97 \ recv t=1 m=1,AS:2000|2,AS:500 pt=1:96,2:97 a=pcfg:2 t=1 m=2 b=1 pt=1:97 ---- Indicating the possibility to setup different media in the send and recv directions. Here the offerer specifies a desire to send and receive MPEG-4 but also accepts a possibility that it may send and receive H.263 as it is also specified for the media. The answer may look like ---- m=video 49154 RTP/AVP 99 a=csup:med-v0,bcap-v0,asym-v0 a=rtpmap:99 H263-2000/90000 a=pcfg:1 +asym-v0 \ recv t=1 m=2,AS:500 pt=2:97 send t=1 m=1,AS:2000 pt=1:96 ---- Indicating that the answerer can send MPEG-4 (2Mbps) but wish to receive H.263 (500kbps). It may also be the case that the answerer can only send H.263, in which case the streams part of the answer would look like: ---- m=video 49154 RTP/AVP 99 a=csup:med-v0,bcap-v0,asym-v0 a=rtpmap:99 H263-2000/90000 a=pcfg:1 +asym-v0 \ recv t=1 m=2,AS:500 pt=2:97 send t=1 m=2,AS:500 pt=2:97 ---- [Ed. Note 1. The bandwidth figures are only approximate] [Ed. Note 2. RFC3984bis adds support for asymmetric sessions. It comes with some limitations. One limitation is that a given profile- level-id can only be downgraded and depending on which side initiates Johansson Expires August 14, 2009 [Page 9] Internet-Draft Asymmetric Media with SDP Feb 2009 the session this may be a problem (unsure how big it is in reality).] 4.3. Asymmetric Number of Streams The idea is to have separate identities for the available number of media streams that can be transmitted between the central point and a participant in a tightly coupled conference. For e.g. RTP this will mean that the available media streams between the mixer (M) and the participant will have separate SSRC, e.g. SSRC_bridge_A1, SSRC_bridge_A2, ... SSRC_bridge_AN, where N is the maximum number of media streams that can be sent between the central point and a specific participant, for instance A. Note that this number can either be fixed or negotiated at call setup. The active media sources, as decided upon by the central point, are then mapped onto these media streams, and the corresponding SSRC from the originating participant is used for the CSRC in the packets. ------------------- --------- | Central point | | A | | ----------- | | |<---------| Mixer | | | |<---------| M | | --------- | |<---------| | | | D | | | | | |<---------| | | |--------->| | | | | | | | | |--------->| | --------- | | | | | | | | | | --------- --------- | | | | | B | | | | | | |--------->| | | --------- | |--------->| | | | E | | | | | |<---------| | | |<---------| |<---------| | | | | | |<---------| | --------- | | | | | | | | |--------->| | --------- | | |--------->| | | C | | | |--------->| | | |<---------| | | | | | |<---------| | | --------- | | | | | | | |--------->| | | | | | ----------- | --------- | | ------------------- Figure 1 Johansson Expires August 14, 2009 [Page 10] Internet-Draft Asymmetric Media with SDP Feb 2009 With reference to figure 1, consider a scenario with a participant A that has the capability to receive three simultaneous media streams. In the conference, the first participant producing an active media is participant B. The media originating from participant B is then subsequently transmitted from the central point to participant A using SSRC_bridge_A1 and with SSRC_B used as CSRC_bridge_A1 in the RTP packets. Next, two more participants, C and D in turn, start producing media that is decided as active by the central point, and these are transmitted to participant A using SSRC_bridge_A2 with SSRC_C as CSRC_bridge_A2, and SSRC_bridge_A3 with SSRC_D as CSRC_bridge_A3, respectively. If a fourth participant, E, starts to produce active media, this media cannot be transmitted to participant A simultaneously with the media from participants B, C, and D, since participant A only has the possibility to receive and process media from three other participants. Hence, the central point has to decide on which of the 4 incoming media streams to pass on to participant A. If, as an example, participant C is decided by the central point to produce the least active media, then media from participant C is no longer transmitted to participant A, and the media from participant E is instead transmitted to participant A using SSRC_bridge_A2 with SSRC_E as CSRC_bridge_A2 in the RTP packets. Since the CSRC in the packets from the central point with SSRC_bridge_A2 has changed, participant A then has the ability to immediately detect this and start processing the media from participants E without any delay. The above description relates to the case where the mixer has the ability to send multiple streams. A similar situation may also occur if a terminal has the ability to separate the audio input into individual sources, e.g. using source separation based on multi- microphone techniques. Then each individual audio source (usually an individual talker but also other sound sources may be considered) may be sent as individual signal sources from the participant to the central point. Assume that a node A can receive three incoming streams and send one stream, and a node M can receive one and send three streams, as displayed in Figure 2. Note that a node in this context may be either a central point or a participant. Johansson Expires August 14, 2009 [Page 11] Internet-Draft Asymmetric Media with SDP Feb 2009 --------- ----------- | A | | Mixer | | |<---------| M | | |<---------| | | |<---------| | | | | | | |--------->| | | | | | --------- ----------- Figure 2 In order to negotiate the format of the media streams so as to utilize the full processing and rendering capabilities, node A sends an offer with an AMR-WB stream but also specifies that it can handle 3 parallel incoming streams (alternatives for 2 and 1 streams are also given). The media stream is set to inactive since the number of streams needs to be negotiated before setting up the resources needed for coding and decoding. This can be achieved with the following attributes in the SDP: ---- a=tcap:1 RTP/AVP m=audio 5000 RTP/AVP 96 a=creq:med-v0,bcap-v0 a=rptmap:96 AMR-WB/16000/1 a=mcap:1 AMR-WB/16000/1 a=bcap:1 AS:40 a=pcfg:1 +asym-v0 \ recv t=1 m=1(3),AS:120|1(2),AS:80|1,AS:40 pt=1:96 \ send t=1 m=1,AS:40 pt=1:96 a=pcfg:2 t=1 m=1 b=1 pt=1:96 a=inactive ---- Node M recognizes the processing and rendering capabilities expressed by node A, and answers: ---- a=tcap:1 RTP/AVP m=audio 5000 RTP/AVP 96 a=creq:med-v0,bcap-v0 a=rptmap:96 AMR-WB/16000/1 a=mcap:1 AMR-WB/16000/1 a=acfg:1 +asym-v0 \ send t=1 m=1(3),AS:120 pt=1:96 recv t=1 m=1,AS:40 pt=1:96 a=inactive ---- Node A now knows that node M supports 3 parallel outgoing streams and Johansson Expires August 14, 2009 [Page 12] Internet-Draft Asymmetric Media with SDP Feb 2009 can therefore set up the needed resources for decoding three parallel streams. The streams are then activated by sending an update SDP: ---- a=tcap:1 RTP/AVP m=audio 5000 RTP/AVP 96 a=creq:med-v0,bcap-v0 a=rptmap:96 AMR-WB/16000/1 a=mcap:1 AMR-WB/16000/1 b=AS:120 a=pcfg:1 +asym-v0 \ recv t=1 m=1(3),AS:120 pt=1:96 send t=1 m=1,AS:40 pt=1:96 a=sendrecv ---- The b=AS parameter is added to indicate that A can receive a bitrate of 120kbps. Finally, node M answers: ---- a=tcap:1 RTP/AVP m=audio 5000 RTP/AVP 96 a=creq:med-v0,bcap-v0 a=rptmap:96 AMR-WB/16000/1 a=mcap:1 AMR-WB/16000/1 b=AS:40 a=acfg:1 +asym-v0 \ send t=1 m=1(3),AS:120 pt=1:96 recv t=1 m=1,AS:40 pt=1:96 a=sendrecv ---- M indicates in the answer that it can receive a bitrate of 40kbps. After this the RTP communication may be started. 5. Considerations 5.1. Payload Formats that Supports Asymmetry Certain payload format already supports asymmetry. One such example is RFC3984bis (H.264) which allows level downgrading and specification of sprop-level-parameter-sets. In general it is NOT RECOMMENDED to use the asymmetric extension described in this draft in these cases. Johansson Expires August 14, 2009 [Page 13] Internet-Draft Asymmetric Media with SDP Feb 2009 5.2. Backwards Compatibility For reasons of backwards compatibility it is RECOMMENDED to specify a number of potential and/or latent configurations that does not use the asymmetry extension described in this draft. 5.3. Bidirectional Attributes Bidirectional attributes [Ed. Note: is this the correct term?] are in the SDPCapNeg framework wrapped in the "a=acap" attribute. One such example is --- a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 \ inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 --- In the SDPCapNeg framework the selected crypto attribute is copied to an "a=crypto" attribute and with other keying material. As the new extension to [SDPCapNeg] defined in this memo does not allow this for reasons of asymmetry the selected crypto attributes MUST remain in their "a=acap" attributes. Moreover the keying info is subject to change. A consequence of this is that the same "a=acap:x crypto:x...." can not be used in the send and the receive direction. [Ed. Note... Confusing text, rewrite...]. Other examples of bidirectional attributes may be those contained by the "a=mfcap" attributes, in this case it is also necessary to define extra "a=mcap" attributes in order to isolate the send and receive directions. 6. Open Issues Open issues and observations. o Asymmetric sessions in practice means that the bandwidth requirements in each direction will differ, and also that this difference may be quite large. A solution to this is given that may in some cases conflict with the mechanisms in sections 5.1 and 6.1 in [RFC3264] o Can the answerer modify alternatives towards a lower value, for instance can ---- a=pcfg:1 +asym-v0 \ send t=1 m=1(3),2,AS:200 b=1 pt=1:96,2:97 \ recv t=1 m=1 pt=1:96 ---- Johansson Expires August 14, 2009 [Page 14] Internet-Draft Asymmetric Media with SDP Feb 2009 be modified to ?. ---- a=pcfg:1 +asym-v0 \ send t=1 m=1(2),2,AS:200 b=1 pt=1:96,2:97 \ recv t=1 m=1 b=4 pt=1:96 ---- A problem with this possibility is that it may make bandwidth specifiers showing wrong values. In some cases it may be possible to recompute the bandwidth but in the general case it is likely too complicated. Worth notice is also that the attribute in its present formulation makes it possible to specify several alternatives with maintained support for consistent bandwidth modifiers. o Is there a need to clearly specify when negotiation is finalized, like is done for example in XMPP Jinge (session-initiate, session- accept) ?. 7. IANA Considerations T.B.D 8. Security Considerations T.B.D 9. Acknowledgements Thanks to Tomas Frankkila and Christer Holmberg for useful comments. Also thanks to Anders Eriksson, Tommy Falk, Magnus Westerlund and Per Boussard for their initial work that eventually led to this memo. 10. References 10.1. Informative References [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 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. Johansson Expires August 14, 2009 [Page 15] Internet-Draft Asymmetric Media with SDP Feb 2009 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [SDPCapNeg] IETF, "SDP Capability Negotiation, http://tools.ietf.org/ wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation". [SDPMedCapNeg] IETF, "SDP media capabilities Negotiation, http:// tools.ietf.org/wg/mmusic/ draft-ietf-mmusic-sdp-media-capabilities". [SDPMiscCapNeg] IETF, "Miscellaneous Capabilities in SDP , http:// tools.ietf.org/id/ draft-garcia-mmusic-sdp-misc-cap-00.txt". 10.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN Phone: +46 73 0783289 Email: ingemar.s.johansson@ericsson.com Johansson Expires August 14, 2009 [Page 16]