B. Beser Internet Draft 3Com Document: draft-beser-mmusic-capabilities-00.txt March 2000 Category: Informational Codec Capabilities Attribute for SDP Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026 [1], and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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. 1. Abstract The need for assured communication arisen protocols like RSVP [2] and SBM [3] which are linked to access technologies to guarantee the delay and drop probabilities of a given IP flow. One of the side-effects of the assurance is that when the bandwidth of the IP flow goes outside the contracted region then the IP flow will be disturbed and the communication will be effected. This document discusses the effects of assured communication to SDP protocol, identifies the weaknesses and proposes a new attribute to rectify these weaknesses. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 4. Introduction The introduction of commercial services (e.g. VoIP) brought along with the quality concept. Although the quality has many dimensions one of the basic aspects of quality is the packet delay and drop probabilities. Resource Reservation Protocol (RSVP) answers these basic QoS requirements by making a contract with the client. Using RSVP protocol the client defines its IP flow using a set of filters and defines its IP flow by using a set of measures. When the Router accepts the contract it is assumed that as far as the client is within the contracted parameters it will get the requested QoS. The Session Description Protocol [5] which is designed for the advertisement of conference sessions and communicate the relevant conference setup information to recipients. SDP by definition does not contain elements that would enable the end-points for media encoding negotiations. In this document a new attribute Codec Capabilities is defined such that end-points will know codec choices at the same time having definite codec(s) agreed for communication. 5. The Current SDP Codec Communication Several drafts are written to identify and solve problems involving QoS setup in IP telephony [6, 7, 8]. In all of the drafts that are cited it is assumed that the both ends of communication will have a solid understanding of which codec the other side will use. For example consider the call flow of Figure 1 which is taken from [6] which uses SIP messaging [9]. A B ----------INV-(1)------------> <------180 w/SDP-(2)----------- <.....PATH..B2A................ ..........RESV.B2A............> ..........PATH.A2B............> <,,,,,,,,RESVCONF B2A,,,,,,,,,, LOCAL RB <........RESV...A2B............ ,,,,,,,,,,,,RESVCONF A2B,,,,,,> RINGING <--------------- 200 OK-(3)---- --------------ACK ------------> Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 For the case of simplicity lets assume that both A and B has two codec's G.726 for voice communications and G.711 for fax and modem. In this case the SIP messages INVITE, 183 and 200 OK will contain the following SDP's. INVITE (1) SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=TakeMeHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 183 (2) SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 200OK (3) SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv At the end of the messaging both of the ends have information regarding both ends, meaning G.711 and G.726 codecs. The problem is that if both ends does not have any kind of pre- agreement than although both ends will use 8Kb/s bandwidth they has to reserve 64Kb/s since they cannot control when will the other end switch to the high bandwidth codec. Which would mean that there will be an over-reservation of 56Kb/s. Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 6. Codec Capabilities The _m=_ Media Announcements has double interpretations: first it contains the capabilities of the receiver, and second it contains the expected Codec(s) at the same time. The proposed attribute codec Capabilities takes the double meaning from Media Announcements. Codec Capabilities shows to the other end the originators capabilities and preferences. 7. Definition The Codec Capabilities attribute is defined as: a= cap: <media> <port> <transport> <Codec Capabilities List> The definitions of <media> <port> and <transport> are the same as Media Announcement and they are used for identifying the correct media announcement for the cases that there are more than one media announcement. The <Codec Capabilities> is an preference list containing: <Codec Capabilities List> = <Payload Type>["/"<Direction>["/"<Group>]] The leftmost item in the list is the most desired codec to be used with the order of decreasing reference moving right in the list. The <Payload Type> contains the payload types that the originator is willing to send and/or receive. The <Direction> field is optional and if exists it MUST contain one of the following: r: if the client is willing to receive (default). s: if the client is willing to send. a: if the client is willing to send and/or receive. b: if the client is willing to both send and receive. The nonexistence of <Direction> field means the client is willing to receive. The difference between "a" and "b" is the fact that if "a" is used it is possible for a media exchange in one direction and with a different selection in the other direction. If "b" is to be used the media exchange can only take place if both directions use the same codec type. The <Group> field is optional and if exists it is used for tying multiple media streams together. If there is no grouping for the payload type than either 0 SHOULD be used or the field MUST be omitted. Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 8. Examples 8.1. IP Telephony If the previous example is to be re-written: INVITE SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 183 SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 200OK SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 8.2. UAS with Limited Processing Power If the UAS has limited processing power and cannot handle both sending and receiving of low bandwidth codecs simultaneously then the SDP will be: INVITE SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 0/b/0 96/s/1 0/r/1 0/s/2 96/r/2 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 8.3. Sending Capabilities without Tying the Originator Codec In all of the examples above the originator set the Codec it wants to receive without knowing the other ends capabilities. The only way to achieve this is to have symmetric codec definition for bth send and receive dircetions such that the receiving end chooses the codec for both directions. The SDP exchange will be: INVITE SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 96 a=cap: audio 49170 RTP/AVP 0/b/0 96/b/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 183 SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv At the end of 183 exchange both ends has the codec(s) that will be used both directions for media exchange, and originator has the knowledge that the terminating end can support any codec combination, and the preferred codec is G.726. 8.4. Codec change The codec change by the consent of other end can be achieved by changing the first payload type defined in the Codec Capablities List. If the above example the originator decides that both ends should change to a lower bandwidth codec G726 then the SDP exchange will be: Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 INVITE SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 96/b/0 0/b/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 183 SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 96 a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv Notice that the terminating end still shows its preference for the higher bandwidth lower processing power codec keeping the preference list the same. 8.5. Rejection of Codec Change If in the above example the other end is to reject the request because it does not have processing power than it would reply with SDP: 183 SDP: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv In the above SDP the G.726 is still retained in the capabilities but it is possible for the other end not to use the codec anymore which would result with the SDP: 183 SDP: Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 0/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv 8.6. Tying Multiple Media Types If there is a limited bandwidth between two end-points that is not sufficient for both high quality high bandwidth voice Codec and Video communications. Than the definition of SDP will be: High Quality Voice: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 99 a=cap: audio 49170 RTP/AVP 99/a/0 0/a/1 a=rtpmap:0 PCMU/8000 a=rtpmap:99 VeryHighQualityCodec/64000 a=qos:mandatory sendrecv a=cap: video 51372 RTP/AVP 31 b 1 Both Voice and Video: INVITE: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=WannaGoHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 99 a=cap: audio 49170 RTP/AVP 0/a/1 99/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:99 VeryHighQualityCodec/64000 a=qos:mandatory sendrecv a=cap: video 51372 RTP/AVP 31 b 1 183/200: v=0 o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4 s=TakeMeHome c=IN IP4 224.2.17.12/127 t=907165245 0 m=audio 49170 RTP/AVP 0 a=cap: audio 49170 RTP/AVP 0/a/1 99/a/0 a=rtpmap:0 PCMU/8000 a=rtpmap:99 VeryHighQualityCodec/64000 Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 a=qos:mandatory sendrecv m= video 51372 RTP/AVP 31 b 1 a=cap: video 51372 RTP/AVP 31 b 1 9. Security Considerations If the contents of the SDP contained in the messages are private then end-to-end encryption of the message body can be used to prevent unauthorized access to the content. 10. References 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. RFC 2210, The Use of RSVP with IETF Integrated Services by J. Wroclawski, September 1997. 3. SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks by Raj Yavatkar, Don Hoffman, Yoram Bernet, Fred Baker and Michael Speer. Internet-Draft, work in progress, May 1999. 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5. M. Handley and V. Jacobson, "SDP: session description protocol, "Request for Comments (Proposed Standard) 2327, Internet Engineering 6. Rosenberg, J., Schulzrinne,H., Donovan S., _Establishing QoS and Security Preconditions for SDP Sessions_, Internet Draft, April 1998 7. Manyfolks, " Integration of Resource Management and SIP for IP Telephony", draft-manyfolks-sip-resource-00.txt, March 2000. 8. Sinnreich, H., Donovan, S., Rawlins, D., Thomas, S., _IP Communication with QoS, Authorization and Usage Reporting_, draft-sinnreich-sip-qos-sp-00.txt, October 1999. 9. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. 11. Acknowledgments I would like to extend a heartfelt thanks to all those who contributed to the development of PacketCable DCS specification. Particular thanks are given Mike Mannette, Kurt Steinbrenner (3Com); Dave Boardman (Arris), K.K. Ramakrishnan, Bill Marshall, Doug Nortz, Chuck Kalmanek, and Tung-Hai Hsiao (AT&T); Dave Oran, Bill Guckel, Flemming Andreasen and Michael Ramalho (Cisco); John Pickens (Com21); D.R. Evans (Lucent Cable Communications); Poornima Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000 Lalwaney, Jon Fellows, John Wheeler (Motorola); Keith Kelly (NetSpeak); Edward Miller, and Glenn Russell (CableLabs). 11. Author's Address Burcak Beser 3Com Mount Prospect, IL 60056 Email: Burcak_Beser@3com.com Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000