RFC 6871
Session Description Protocol (SDP) Media Capabilities Negotiation
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".
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
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
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
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:
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
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:
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.
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.
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.
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.
[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