[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 04                                                         
                                                               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