tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6871

 
 
 

Session Description Protocol (SDP) Media Capabilities Negotiation

Part 4 of 4, p. 44 to 55
Prev RFC Part

 


prevText      Top      Up      ToC       Page 44 
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 provides a choice of one of six variations of the
   Adaptive Multi-Rate 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".

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

      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

Top      Up      ToC       Page 46 
      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
      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

Top      Up      ToC       Page 47 
      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
   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 that 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

Top      Up      ToC       Page 48 
   audio as a last resort.  In addition, the offerer wishes to announce
   its ability to support video and Message Session Relay Protocol
   (MSRP) in the future, but does not wish to offer a video stream or an
   MSRP stream at present.  The offer might look 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
      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
      a=lcfg:3 mt=message t=2 m=20
      a=tcap:2 TCP/MSRP
      a=omcap:20 *

   The first "lcfg" attribute line ("lcfg:2") announces support for
   H.263 and H.264 video (H.263 preferred) for future negotiation.  The
   second "lcfg" attribute line ("lcfg:3") announces support for MSRP
   for future negotiation.  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 RTP-
   based media format capabilities (PCMU, G729, telephone-event,
   H263-1998, and H264) and the omcap line defines the non-RTP-based
   media format capability (wildcard).  The "mfcap" attribute provides
   the format parameters for telephone-event, 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 the following:

Top      Up      ToC       Page 49 
      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
   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.

5.  IANA Considerations

5.1.  New SDP Attributes

   IANA has registered the following new SDP attributes:

      Attribute name: rmcap
      Long form name: RTP-based media format 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
      Contact name: Flemming Andreasen, fandres@cisco.com

      Attribute name: omcap
      Long form name: non-RTP-based media format 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
      Contact name: Flemming Andreasen, fandreas@cisco.com

Top      Up      ToC       Page 50 
      Attribute name: mfcap
      Long form name: media format parameter 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
      Contact name: Flemming Andreasen, fandreas@cisco.com

      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
      Contact name: Flemming Andreasen, fandreas@cisco.com

      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
      Contact name: Flemming Andreasen, fandreas@cisco.com

      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
      Contact name: Flemming Andreasen, fandreas@cisco.com

5.2.  New SDP Capability Negotiation Option Tag

   IANA has added the new option tag "med-v0", defined in this document,
   to the "SDP Capability Negotiation Option Capability Tags" registry
   created for RFC 5939 [RFC5939].

5.3.  SDP Capability Negotiation Configuration Parameters Registry

   IANA has changed the "SDP Capability Negotiation Potential
   Configuration Parameters" registry, currently registered and defined
   by RFC 5939 [RFC5939], as follows:

Top      Up      ToC       Page 51 
   The name of the registry should be "SDP Capability Negotiation
   Configuration Parameters Registry" and it should contain a table with
   the following column headings:

   o  Encoding Name: The syntactical value used for the capability
      negotiation configuration parameter, as defined in RFC 5939
      [RFC5939], Section 3.5.

   o  Descriptive Name: The name commonly used to refer to the
      capability negotiation configuration parameter.

   o  Potential Configuration Definition: A reference to the RFC that
      defines the configuration parameter in the context of a potential
      configuration attribute.  If the configuration parameter is not
      defined for potential configurations, the string "N/A" (Not
      Applicable) MUST be present instead.

   o  Actual Configuration Definition: A reference to the RFC that
      defines the configuration parameter in the context of an actual
      configuration attribute.  If the configuration parameter is not
      defined for actual configurations, the string "N/A" (Not
      Applicable) MUST be present instead.

   o  Latent Configuration Definition: A reference to the RFC that
      defines the configuration parameter in the context of a latent
      configuration attribute.  If the configuration parameter is not
      defined for latent configurations, the string "N/A" (Not
      Applicable) MUST be present instead.

   An IANA SDP Capability Negotiation Configuration registration MUST be
   documented in an RFC in accordance with the IETF Review policy
   [RFC5226].  Furthermore:

   o  The RFC MUST define the syntax and semantics of each new potential
      configuration parameter.

   o  The syntax MUST adhere to the syntax provided for extension
      configuration lists in RFC 5939 [RFC5939], Section 3.5.1, and the
      semantics MUST adhere to the semantics provided for extension
      configuration lists in RFC 5939 [RFC5939], Sections 3.5.1 and
      3.5.2.

   o  Configuration parameters that apply to latent configurations MUST
      furthermore adhere to the syntax provided in Section 3.3.5 and the
      semantics defined overall in this document.

   o  Associated with each registration MUST be the encoding name for
      the parameter as well as a short descriptive name for it.

Top      Up      ToC       Page 52 
   o  Each registration MUST specify if it applies to

      *  Potential configurations

      *  Actual configurations

      *  Latent configurations

5.4.  SDP Capability Negotiation Configuration Parameter Registrations

   IANA has registered the following capability negotiation
   configuration parameters:

      Encoding Name: a
      Descriptive Name: Attribute Configuration
      Potential Configuration Definition: [RFC5939]
      Actual Configuration Definition: [RFC5939]
      Latent Configuration Definition: [RFC6871]

      Encoding Name: t
      Descriptive Name: Transport Protocol Configuration
      Potential Configuration Definition: [RFC5939]
      Actual Configuration Definition: [RFC5939]
      Latent Configuration Definition: [RFC6871]

      Encoding Name: m
      Descriptive Name: Media Configuration
      Potential Configuration Definition: [RFC6871]
      Actual Configuration Definition: [RFC6871]
      Latent Configuration Definition: [RFC6871]

      Encoding Name: pt
      Descriptive Name: Payload Type Number Mapping
      Potential Configuration Definition: [RFC6871]
      Actual Configuration Definition: [RFC6871]
      Latent Configuration Definition: [RFC6871]

      Encoding Name: mt
      Descriptive Name: Media Type
      Potential Configuration Definition: N/A
      Actual Configuration Definition: N/A
      Latent Configuration Definition: [RFC6871]

6.  Security Considerations

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

Top      Up      ToC       Page 53 
   In RFC 5939 [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
   non-secure 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 RFC 5939 [RFC5939], the
   considerations and mitigation strategies are similar to those
   described in RFC 5939 [RFC5939].

   Another variation on the above attack involves 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 RFC 5939 [RFC5939].

   The addition of negotiable media formats and their associated
   parameters, defined in this specification can cause problems for
   middleboxes that attempt to control bandwidth utilization, media
   flows, and/or processing resource consumption as part of network
   policy, but that do not understand the media capability negotiation
   feature.  As for the initial SDP capability negotiation 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.

7.  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.

Top      Up      ToC       Page 54 
   We thank Ingemar Johansson and Magnus Westerlund for examples that
   stimulated this work, and for critical reading of the document.  We
   also thank Cullen Jennings, Christer Holmberg, and Miguel Garcia for
   their review of the document.

8.  References

8.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.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

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

   [RFC5939]  Andreasen, F., "Session Description Protocol (SDP)
              Capability Negotiation", RFC 5939, September 2010.

8.2.  Informative References

   [RFC2198]  Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
              Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
              Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
              September 1997.

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 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.

Top      Up      ToC       Page 55 
   [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.

Authors' Addresses

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

   EMail: bob_gilman@comcast.net


   Roni Even
   Huawei Technologies
   14 David Hamelech
   Tel Aviv  64953
   Israel

   EMail: roni.even@mail01.huawei.com


   Flemming Andreasen
   Cisco Systems
   Iselin, NJ
   USA

   EMail: fandreas@cisco.com