SDP Media Capabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-13

Gilman, et al.         Expires September 13, 2012              [Page 40]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

3.4.4.  Modifying the Session

   If, at a later time, one of the parties wishes to modify the
   operating parameters of a session, e.g., by adding a new media
   stream, or by changing the properties used on an existing stream, it
   may do so via the mechanisms defined for offer/answer [RFC3264].  If
   the initiating party has remembered the codecs, potential
   configurations, latent configurations and session capabilities
   provided by the other party in the earlier negotiation, it may use
   this knowledge to maximize the likelihood of a successful
   modification of the session.  Alternatively, the initiator may
   perform a new capabilities exchange as part of the reconfiguration.
   In such a case, the new capabilities will replace the previously-
   negotiated capabilities.  This may be useful if conditions change on
   the endpoint.

Gilman, et al.         Expires September 13, 2012              [Page 41]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

4.  Examples

   In this section, we provide examples showing how to use the Media
   Capabilities with the SDP Capability Negotiation.

4.1.  Alternative Codecs

   This example provide a choice of one of six variations of the
   adaptive multirate codec.  In this example, the default configuration
   as specified by the media line is the same as the most preferred
   configuration.  Each configuration uses a different payload type
   number so the offerer can interpret early media.

             v=0
             o=- 25678 753849 IN IP4 192.0.2.1
             s=
             c=IN IP4 192.0.2.1
             t=0 0
             a=creq:med-v0
             m=audio 54322 RTP/AVP 96
             a=rtpmap:96 AMR-WB/16000/1
             a=fmtp:96 mode-change-capability=1; max-red=220; \
             mode-set=0,2,4,7
             a=rmcap:1,3,5 audio AMR-WB/16000/1
             a=rmcap:2,4,6 audio AMR/8000/1
             a=mfcap:1,2,3,4 mode-change-capability=1
             a=mfcap:5,6 mode-change-capability=2
             a=mfcap:1,2,3,5 max-red=220
             a=mfcap:3,4,5,6 octet-align=1
             a=mfcap:1,3,5 mode-set=0,2,4,7
             a=mfcap:2,4,6 mode-set=0,3,5,6
             a=pcfg:1 m=1 pt=1:96
             a=pcfg:2 m=2 pt=2:97
             a=pcfg:3 m=3 pt=3:98
             a=pcfg:4 m=4 pt=4:99
             a=pcfg:5 m=5 pt=5:100
             a=pcfg:6 m=6 pt=6:101

   In the above example, media capability 1 could have been excluded
   from the first rmcap declaration and from the corresponding mfcap
   attributes, and the pcfg:1 attribute line could have been simply
   "pcfg:1".

   The next example offers a video stream with three options of H.264
   and 4 transports.  It also includes an audio stream with different
   audio qualities: four variations of AMR, or AC3.  The offer looks
   something like:

Gilman, et al.         Expires September 13, 2012              [Page 42]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

             v=0
             o=- 25678 753849 IN IP4 192.0.2.1
             s=An SDP Media NEG example
             c=IN IP4 192.0.2.1
             t=0 0
             a=creq:med-v0
             a=ice-pwd:speEc3QGZiNWpVLFJhQX
             m=video 49170 RTP/AVP 100
             c=IN IP4 192.0.2.56
             a=maxprate:1000
             a=rtcp:51540
             a=sendonly
             a=candidate 12345 1 UDP 9 192.0.2.56 49170 host
             a=candidate 23456 2 UDP 9 192.0.2.56 51540 host
             a=candidate 34567 1 UDP 7 198.51.100.1 41345 srflx raddr \
             192.0.2.56 rport 49170
             a=candidate 45678 2 UDP 7 198.51.100.1 52567 srflx raddr \
             192.0.2.56 rport 51540
             a=candidate 56789 1 UDP 3 192.0.2.100 49000 relay raddr \
             192.0.2.56 rport 49170
             a=candidate 67890 2 UDP 3 192.0.2.100 49001 relay raddr \
             192.0.2.56 rport 51540
             b=AS:10000
             b=TIAS:10000000
             b=RR:4000
             b=RS:3000
             a=rtpmap:100 H264/90000
             a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; \
             sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; \
             sprop-interleaving-depth=45; sprop-deint-buf-req=64000; \
             sprop-init-buf-time=102478; deint-buf-cap=128000
             a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
             a=rmcap:1-3,7-9 H264/90000
             a=rmcap:4-6 rtx/90000
             a=mfcap:1-9 profile-level-id=42A01E
             a=mfcap:1-9 aMljiA==
             a=mfcap:1,4,7 packetization-mode=0
             a=mfcap:2,5,8 packetization-mode=1
             a=mfcap:3,6,9 packetization-mode=2
             a=mfcap:1-9 sprop-parameter-sets=Z0IACpZTBYmI
             a=mfcap:1,7 sprop-interleaving-depth=45; \
             sprop-deint-buf-req=64000; sprop-init-buf-time=102478; \
             deint-buf-cap=128000
             a=mfcap:4 apt=100
             a=mfcap:5 apt=99
             a=mfcap:6 apt=98
             a=mfcap:4-6 rtx-time=3000
             a=mscap:1-6 rtcp-fb nack

Gilman, et al.         Expires September 13, 2012              [Page 43]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

             a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 \
             inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
             a=pcfg:1 t=1 m=1,4 a=1 pt=1:100,4:97
             a=pcfg:2 t=1 m=2,5 a=1 pt=2:99,4:96
             a=pcfg:3 t=1 m=3,6 a=1 pt=3:98,6:95
             a=pcfg:4 t=2 m=7 a=1 pt=7:100
             a=pcfg:5 t=2 m=8 a=1 pt=8:99
             a=pcfg:6 t=2 m=9 a=1 pt=9:98
             a=pcfg:7 t=3 m=1,3 pt=1:100,4:97
             a=pcfg:8 t=3 m=2,4 pt=2:99,4:96
             a=pcfg:9 t=3 m=3,6 pt=3:98,6:95
             m=audio 49176 RTP/AVP 101 100 99 98
             c=IN IP4 192.0.2.56
             a=ptime:60
             a=maxptime:200
             a=rtcp:51534
             a=sendonly
             a=candidate 12345 1 UDP 9 192.0.2.56 49176 host
             a=candidate 23456 2 UDP 9 192.0.2.56 51534 host
             a=candidate 34567 1 UDP 7 198.51.100.1 41348 srflx \
             raddr 192.0.2.56 rport 49176
             a=candidate 45678 2 UDP 7 198.51.100.1 52569 srflx \
             raddr 192.0.2.56 rport 51534
             a=candidate 56789 1 UDP 3 192.0.2.100 49002 relay \
             raddr 192.0.2.56 rport 49176
             a=candidate 67890 2 UDP 3 192.0.2.100 49003 relay \
             raddr 192.0.2.56 rport 51534
             b=AS:512
             b=TIAS:512000
             b=RR:4000
             b=RS:3000
             a=maxprate:120
             a=rtpmap:98 AMR-WB/16000
             a=fmtp:98 octet-align=1; mode-change-capability=2
             a=rtpmap:99 AMR-WB/16000
             a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
             a=rtpmap:100 AMR-WB/16000/2
             a=fmtp:100 octet-align=1; interleaving=30
             a=rtpmap:101 AMR-WB+/72000/2
             a=fmtp:101 interleaving=50; int-delay=160000;
             a=rmcap:14 ac3/48000/6
             a=acap:23 crypto:1 AES_CM_128_HMAC_SHA1_80 \
             inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
             a=tcap:4 RTP/SAVP
             a=pcfg:10 t=4 a=23
             a=pcfg:11 t=4 m=14 a=23 pt=14:102

   This offer illustrates the advantage in compactness that arises if

Gilman, et al.         Expires September 13, 2012              [Page 44]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

   one can avoid deleting the base configuration attributes and
   recreating them in acap attributes for the potential configurations.

4.2.  Alternative Combinations of Codecs (Session Configurations)

   If an endpoint has limited signal processing capacity, it might be
   capable of supporting, say, a G.711 mu-law audio stream in
   combination with an H.264 video stream, or a G.729B audio stream in
   combination with an H.263-1998 video stream.  It might then issue an
   offer like the following:

             v=0
             o=- 25678 753849 IN IP4 192.0.2.1
             s=
             c=IN IP4 192.0.2.1
             t=0 0
             a=creq:med-v0
             a=sescap:1 2,4
             a=sescap:2 1,3
             m=audio 54322 RTP/AVP 18
             a=rtpmap:18 G729/8000
             a=fmtp:18 annexb=yes
             a=rmcap:1 PCMU/8000
             a=pcfg:1 m=1 pt=1:0
             a=pcfg:2
             m=video 54344 RTP/AVP 100
             a=rtpmap:100 H263-1998/90000
             a=rmcap:2 H264/90000
             a=mfcap:2 profile-level-id=42A01E; packetization-mode=2
             a=pcfg:3 m=2 pt=2:101
             a=pcfg:4

   Note that the preferred session configuration (and the default as
   well) is G.729B with H.263.  This overrides the individual media
   stream preferences which are PCMU and H.264 by the potential
   configuration numbering rule.

4.3.  Latent Media Streams

   Consider a case in which the offerer can support either G.711 mu-law,
   or G.729B, along with DTMF telephony events for the 12 common
   touchtone signals, but is willing to support simple G.711 mu-law
   audio as a last resort.  In addition, the offerer wishes to announce
   its ability to support video in the future, but does not wish to
   offer a video stream at present.  The offer might look like the
   following:

Gilman, et al.         Expires September 13, 2012              [Page 45]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

             v=0
             o=- 25678 753849 IN IP4 192.0.2.1
             s=
             c=IN IP4 192.0.2.1
             t=0 0
             a=creq:med-v0
             m=audio 23456 RTP/AVP 0
             a=rtpmap:0 PCMU/8000
             a=rmcap:1 PCMU/8000
             a=rmcap:2 g729/8000
             a=rmcap:3 telephone-event/8000
             a=mfcap:3 0-11
             a=pcfg:1 m=1,3|2,3 pt=1:0,2:18,3:100
             a=lcfg:2 mt=video t=1 m=10|11
             a=rmcap:10 H263-1998/90000
             a=rmcap:11 H264/90000
             a=tcap:1 RTP/AVP

   The lcfg attribute line announces support for H.263 and H.264 video
   (H.263 preferred) for future reference.  The m-line and the rtpmap
   attribute offer an audio stream and provide the lowest precedence
   configuration (PCMU without any DTMF encoding).  The rmcap lines
   define the media capabilities (PCMU, G729, and telephone-event) to be
   offered in potential configurations.  The mfcap attribute provides
   the format parameters for telephone-events, specifying the 12
   commercial DTMF 'digits'.  The pcfg attribute line defines the most-
   preferred media configuration as PCMU plus DTMF events and the next-
   most-preferred configuration as G.729B plus DTMF events.

   If the answerer is able to support all the potential configurations,
   and also support H.263 video (but not H.264), it would reply with an
   answer like:

             v=0
             o=- 24351 621814 IN IP4 192.0.2.2
             s=
             c=IN IP4 192.0.2.2
             t=0 0
             a=csup:med-v0
             m=audio 54322 RTP/AVP 0 100
             a=rtpmap:0 PCMU/8000
             a=rtpmap:100 telephone-event/8000
             a=fmtp:100 0-11
             a=acfg:1 m=1,3 pt=1:0,3:100
             a=pcfg:1 m=2,3 pt=2:18,3:100
             a=lcfg:2 mt=video t=1 m=10

   The lcfg attribute line announces the capability to support H.263

Gilman, et al.         Expires September 13, 2012              [Page 46]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

   video at a later time.  The media line and subsequent rtpmap and fmtp
   attribute lines present the selected configuration for the media
   stream.  The acfg attribute line identifies the potential
   configuration from which it was taken, and the pcfg attribute line
   announces the potential capability to support G.729 with DTMF events
   as well.  If, at some later time, congestion becomes a problem in the
   network, either party may, with expectation of success, offer a
   reconfiguration of the media stream to use G.729 in order to reduce
   packet sizes.

Gilman, et al.         Expires September 13, 2012              [Page 47]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

5.  IANA Considerations

5.1.  New SDP Attributes

   The IANA is hereby requested to register the following new SDP
   attributes:

             Attribute name: rmcap
             Long form name: RTP-based media capability
             Type of attribute: session-level and media-level
             Subject to charset: no
             Purpose: associate RTP-based media capability number(s)
             with
             media subtype and encoding parameters
             Appropriate Values: see Section 3.3.1

             Attribute name: omcap
             Long form name: Non RTP-based media capability
             Type of attribute: session-level and media-level
             Subject to charset: no
             Purpose: associate non RTP-based media capability number(s)
             with
             media subtype and encoding parameters
             Appropriate Values: see Section 3.3.1

             Attribute name: mfcap
             Long form name: media format capability
             Type of attribute: session-level and media-level
             Subject to charset: no
             Purpose: associate media format attributes and
             parameters with media format capabilities
             Appropriate Values: see Section 3.3.2

             Attribute name: mscap
             Long form name: media-specific capability
             Type of attribute: session-level and media-level
             Subject to charset: no
             Purpose: associate media-specific attributes and
             parameters with media capabilities
             Appropriate Values: see Section 3.3.3

             Attribute name: lcfg
             Long form name: latent configuration
             Type of attribute: media-level
             Subject to charset: no
             Purpose: to announce supportable media streams
             without offering them for immediate use.
             Appropriate Values: see Section 3.3.5

Gilman, et al.         Expires September 13, 2012              [Page 48]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

             Attribute name: sescap
             Long form name: session capability
             Type of attribute: session-level
             Subject to charset: no
             Purpose: to specify and prioritize acceptable
             combinations of media stream configurations.
             Appropriate Values: see Section 3.3.8

5.2.  New SDP Option Tag

   The IANA is hereby requested to add the new option tag "med-v0",
   defined in this document, to the SDP Capability Option Negotiation
   Capability registry created for [RFC5939].

5.3.  New SDP Capability Negotiation Parameters

   The IANA is hereby requested to expand the SDP Capability Negotiation
   Potential Configuration Parameter Registry established by [RFC5939]
   to become the SDP Capability Negotiation Configuration Parameter
   Registry and to include parameters for the potential, actual and
   latent configuration attributes.  The new parameters to be registered
   are the "m" for "media", "pt" for "payload type number", and "mt" for
   "media type" parameters.  Note that the "mt" parameter is defined for
   use only in the latent configuration attribute.

Gilman, et al.         Expires September 13, 2012              [Page 49]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

6.  Security Considerations

   The security considerations of [RFC5939] apply for this document.

   In [RFC5939], it was noted that negotiation of transport protocols
   (e.g. secure and non-secure) and negotiation of keying methods and
   material are potential security issues that warrant integrity
   protection to remedy.  Latent configuration support provides hints to
   the other side about capabilities supported for further offer/answer
   exchanges, including transport protocols and attribute capabilities,
   e.g. for keying methods.  If an attacker can remove or alter latent
   configuration information to suggest that only insecure or less
   secure alternatives are supported, then he may be able to force
   negotiation of a less secure session than would otherwise have
   occurred.  While the specific attack as described here differs from
   those described in [RFC5939], the considerations and mitigation
   strategies are similar to those described in [RFC5939].

   Another variation on the above attack involves the the Session
   Capability ("sescap") attribute defined in this document.  The
   "sescap" enables a preference order to be specified for all the
   potential configurations, and that preference will take precedence
   over any preference indication provided in individual potential
   configuration attributes.  Consequently, an attacker that can insert
   or modify a "sescap" attribute may be able to force negotiation of an
   insecure or less secure alternative than would otherwise have
   occurred.  Again, the considerations and mitigation strategies are
   similar to those described in [RFC5939].

   The addition of negotiable media formats and their associated
   parameters, defined in this specification can cause problems for
   middleboxes which attempt to control bandwidth utilization, media
   flows, and/or processing resource consumption as part of network
   policy, but which do not understand the media capability negotiation
   feature.  As for the initial CapNeg work [RFC5939], the SDP answer is
   formulated in such a way that it always carries the selected media
   encoding for every media stream selected.  Pending an understanding
   of capabilities negotiation, the middlebox should examine the answer
   SDP to obtain the best picture of the media streams being
   established.  As always, middleboxes can best do their job if they
   fully understand media capabilities negotiation.

Gilman, et al.         Expires September 13, 2012              [Page 50]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

7.  Changes from previous versions

7.1.  Changes from version 12

   o  Removed "dummy" form in the pcfg payload-type-number, since the
      functionality is redundant with the non-RTP media capability
      (omcap) and it was inconsistent with other RTP payload type
      operation.

   o  Clarified that latent configuration attribute (lcfg) can only be
      used at the media level and hence (technically) as part of a media
      description

   o  Rewrote offer/answer sections and expanded significantly on offer/
      answer operation.

   o  Updated security considerations

   o  Various minor editorial clarifications and changes.

7.2.  Changes from version 11

   o  Corrected several statements implying lcfg was a session-level
      attribute.

   o  Added non-RTP based media format capabilities ("a=omcap") and
      renamed "mcap" to "rmcap"

7.3.  Changes from version 10

   o  Defined the latent configuration attribute as a media-level
      attribute because it specifies a possible future media stream.
      Added text to clarify how to specify alternative configurations of
      a single latent stream and/or multiple streams.

   o  Improved the definition of the session capability attribute to
      permit both required configurations and optional configurations -
      latent configurations cannot be required because they have not yet
      been offered.

   o  Removed the special-case treatment of conflicts between base-level
      fmtp attributes and fmtp attributes generated for a configuration
      via invoked mcap and mfcap attributes.

   o  Removed reference to bandwidth capability (bcap) attribute.

   o  Changed various "must", etc., terms to normative terms ("MUST",
      etc.) as appropriate, in Section 3.3.5Section 3.3.6.1

Gilman, et al.         Expires September 13, 2012              [Page 51]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

      Section 3.3.6.3 and Section 3.3.8

   o  Attempted to clarify the substitution mechanism in Section 3.3.7
      and improve its uniqueness.

   o  Made various editorial changes, including changing the title in
      the header, and removing numbering from some SDP examples.

7.4.  Changes from version 09

   o  Additional corrections to latent media stream example in
      Section 4.3

   o  Fixed up attribute formatting examples and corresponding ABNF.

   o  Removed preference rule for latent configurations.

   o  Various spelling and other editorial changes were made.

   o  updated crossreferences.

7.5.  Changes from version 08

   The major change is in Section 4.3, Latent Media Streams, fixing the
   syntax of the answer.  All the other changes are editorial.

7.6.  Changes from version 04

   o  The definitions for bcap, ccap, icap, and kcap attributes have
      been removed, and are to be defined in another document.

   o  Corrected formatting of m= and p= configuration parameters to
      conform to extension-config-list form defined in [RFC5939]

   o  Reorganized definitions of new parameters to make them easier to
      find in document.

   o  Added ability to renegotiate capabilities when modifying the
      session (Section 3.4.4).

   o  Made various editorial changes, clarifications, and typo
      corrections.

7.7.  Changes from version 03

   o  A new session capability attribute (sescap) has been added to
      permit specification of acceptable media stream combinations.

Gilman, et al.         Expires September 13, 2012              [Page 52]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

   o  Capability attribute definitions corresponding to the i, c, b, and
      k SDP line types have been added for completeness.

   o  Use of the pcfg: attribute in SDP answers has been included in
      order to conveniently return information in the answer about
      acceptable configurations in the media stream offer.

   o  The use of the lcfg: attribute(s) in SDP answers has been
      restricted to indicate just which latent configuration offers
      would be acceptable to the answerer.

   o  A suggestion for "naive" middleboxes has been added to the
      Security Considerations.

   o  Various editorial changes have been made.

   o  Several errors/omissions have been corrected.

   o  The description of the mscap attribute has been modified to make
      it clear that it should not be used to generate undefined SDP
      attributes, or to "extend" existing attributes.

   o  <ms-parameters> are made optional in the mscap attribute
      definition.

   o  "AMR" changed to "AMR-WB" in cases in which the sample rate is
      16000.

7.8.  Changes from version 02

   This version contains several detail changes intended to simplify
   capability processing and mapping into conventional SDP media blocks.

   o  The "mcap" attribute is enhanced to include the role of the "ecap"
      attribute; the latter is eliminated.

   o  The "fcap" attribute has been renamed "mfcap".  New replacement
      rules vis-a-vis fmtp attributes in the base media specification
      have been added.

   o  A new "mscap" attribute is defined to handle the problem of
      attributes (other than rtpmap and fmtp) that are specific to a
      particular payload type.

   o  New rules for processing the mcap, mfcap, and mscap attributes,
      and overriding standard rtpmap, fmtp, or other media-specific
      attributes, are put forward to reduce the need to use the deletion
      option in the a= parameter of the potential configuration (pcfg)

Gilman, et al.         Expires September 13, 2012              [Page 53]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

      attribute.

   o  A new parameter, "mt=" is added to the latent configuration
      attribute (lcfg) to specify the media stream type (audio, video,
      etc.) when the lcfg is declared at the session level.

   o  The examples are expanded.

   o  Numerous typos and misspellings have been corrected.

7.9.  Changes from version 01

   The documents adds a new attribute for specifying bandwidth
   capability and a parametr to list in the potential configuration.
   Other changes are to align the document with the terminolgy and
   attribute names from draft-ietf-mmusic-sdp-capability-negotiation-07.
   The document also clarifies some previous open issues.

7.10.  Changes from version 00

   The major changes include taking out the "mcap" and "cptmap"
   parameter.  The mapping of payload type is now in the "pt" parameter
   of "pcfg".  Media subtype need to explictly definesd in the "cmed"
   attribute if referenced in the "pcfg"

Gilman, et al.         Expires September 13, 2012              [Page 54]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

8.  Acknowledgements

   This document is heavily influenced by the discussions and work done
   by the SDP Capability Negotiation Design team.  The following people
   in particular provided useful comments and suggestions to either the
   document itself or the overall direction of the solution defined
   herein: Cullen Jennings, Matt Lepinski, Joerg Ott, Colin Perkins, and
   Thomas Stach.

   We thank Ingemar Johansson and Magnus Westerlund for examples that
   stimulated this work, and for critical reading of the document.

Gilman, et al.         Expires September 13, 2012              [Page 55]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5939]  Andreasen, F., "SDP Capability Negotiation", RFC 5939,
              September 2010.

9.2.  Informative References

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 2006.

   [RFC4583]  Camarillo, G., "Session Description Protocol (SDP) Format
              for Binary Floor Control Protocol (BFCP) Streams",
              RFC 4583, November 2006.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              July 2006.

   [RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
              Digits, Telephony Tones, and Telephony Signals", RFC 4733,
              December 2006.

   [RFC4867]  Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
              "RTP Payload Format and File Storage Format for the
              Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
              (AMR-WB) Audio Codecs", RFC 4867, April 2007.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, February 2008.

Gilman, et al.         Expires September 13, 2012              [Page 56]
Internet-Draft     SDP Media Capabilities Negotiation         March 2012

Authors' Addresses

   Robert R Gilman
   Independent
   3243 W. 11th Ave. Dr.
   Broomfield, CO 80020
   USA

   Email: bob_gilman@comcast.net

   Roni Even
   Gesher Erove Ltd
   14 David Hamelech
   Tel Aviv  64953
   Israel

   Email: ron.even.tlv@gmail.com

   Flemming Andreasen
   Cisco Systems
   Iselin, NJ
   USA

   Email: fandreas@cisco.com

Gilman, et al.         Expires September 13, 2012              [Page 57]