doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc7006.txt b/doc/rfc/rfc7006.txt
new file mode 100644
index 0000000..2a0f38b
--- /dev/null
+++ b/doc/rfc/rfc7006.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  M. Garcia-Martin
+Request for Comments: 7006                                      Ericsson
+Category: Standards Track                                S. Veikkolainen
+ISSN: 2070-1721                                                    Nokia
+                                                               R. Gilman
+                                                          September 2013
+
+
+             Miscellaneous Capabilities Negotiation in the
+                   Session Description Protocol (SDP)
+
+Abstract
+
+   The Session Description Protocol (SDP) has been extended with a
+   capability negotiation mechanism framework that allows the endpoints
+   to negotiate transport protocols and attributes.  This framework has
+   been extended with a media capabilities negotiation mechanism that
+   allows endpoints to negotiate additional media-related capabilities.
+   This negotiation is embedded into the widely used SDP offer/answer
+   procedures.
+
+   This memo extends the SDP capability negotiation framework to allow
+   endpoints to negotiate three additional SDP capabilities.  In
+   particular, this memo provides a mechanism to negotiate bandwidth
+   ("b=" line), connection data ("c=" line), and session or media titles
+   ("i=" line for each session or media).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7006.
+
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 1]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Conventions Used in This Document ...............................3
+   3. Protocol Description ............................................4
+      3.1. Extensions to SDP ..........................................4
+           3.1.1. Bandwidth Capability ................................6
+           3.1.2. Connection Data Capability ..........................8
+           3.1.3. Title Capability ...................................12
+      3.2. Session Level versus Media Level ..........................16
+      3.3. Offer/Answer Model Extensions .............................17
+           3.3.1. Generating the Initial Offer .......................17
+           3.3.2. Generating the Answer ..............................17
+           3.3.3. Offerer Processing of the Answer ...................18
+           3.3.4. Modifying the Session ..............................18
+   4. Field Replacement Rules ........................................18
+   5. Security Considerations ........................................18
+   6. IANA Considerations ............................................19
+      6.1. New SDP Attributes ........................................19
+      6.2. New Option Tags ...........................................20
+      6.3. New SDP Capability Negotiation Configuration Parameters ...20
+   7. Acknowledgments ................................................20
+   8. References .....................................................20
+      8.1. Normative References ......................................20
+      8.2. Informative References ....................................21
+
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 2]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+1.  Introduction
+
+   The Session Description Protocol (SDP) [RFC4566] is intended for
+   describing multimedia sessions for the purposes of session
+   announcement, session invitation, and other forms of multimedia
+   session initiation.  SDP has been extended with an SDP Capability
+   Negotiation Mechanism Framework [RFC5939] that allows the endpoints
+   to negotiate capabilities, such as support for the Real-time
+   Transport Protocol (RTP) [RFC3550] and the Secure Real-time Transport
+   Protocol (SRTP) [RFC3711].  The SDP Media Capabilities Negotiation
+   [RFC6871] provides negotiation capabilities to media lines as well.
+
+   The capability negotiation is embedded into the widely used SDP
+   offer/answer procedure [RFC3264].  This memo provides the means to
+   negotiate further capabilities than those specified in the SDP
+   Capability Negotiation Mechanism Framework [RFC5939] and the SDP
+   Media Capabilities Negotiation [RFC6871].  In particular, this memo
+   provides a mechanism to negotiate bandwidth ("b="), connection data
+   ("c="), and session or media titles ("i=").
+
+   Since the three added capabilities are independent, it is not
+   expected that implementations will necessarily support all of them at
+   the same time.  Instead, it is expected that applications will choose
+   their needed capability for their specific purpose.  For this reason,
+   the normative part pertaining to each capability is in a self-
+   contained section: Section 3.1.1 describes the bandwidth capability
+   extension, Section 3.1.2 describes the connection data capability
+   extension, and Section 3.1.3 describes the title capability
+   extension.  Separate SDP Capability Negotiation option tags are
+   defined for each capability, allowing endpoints to indicate and/or
+   require support for these extensions according to procedures defined
+   in SDP Capability Negotiation [RFC5939].
+
+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 BCP 14, RFC 2119
+   [RFC2119] and indicate requirement levels for compliant
+   implementations.
+
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 3]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+3.  Protocol Description
+
+3.1.  Extensions to SDP
+
+   The SDP Capability Negotiation Framework [RFC5939] and the SDP Media
+   Capabilities Negotiation [RFC6871] specify attributes for negotiating
+   SDP capabilities.  These documents specify new attributes (e.g.,
+   "acap", "tcap", "rmcap", and "omcap") for achieving their purpose.
+   In this document, we define three new additional capability
+   attributes for SDP lines of the general form:
+
+      type=value
+
+   for types "b", "c", and "i".  The corresponding capability attributes
+   are respectively defined as:
+
+   o  "bcap": bandwidth capability
+
+   o  "ccap": connection data capability
+
+   o  "icap": title capability
+
+   From the sub-rules of the attribute ("a=") line in SDP [RFC4566], SDP
+   attributes are of the form:
+
+         attribute          = (att-field ":" att-value) / att-field
+         att-field          = token
+         att-value          = byte-string
+
+   Capability attributes use only the "att-field:att-value" form.
+
+   The new capabilities may be referenced in potential configurations
+   ("a=pcfg") or in latent configurations ("a=lcfg") as productions
+   conforming to the <extension-config-list>, as respectively defined in
+   RFC 5939 [RFC5939] and RFC 6871 [RFC6871].
+
+      extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
+      ext-cap-name          = 1*(ALPHA / DIGIT)
+                              ; ALPHA and DIGIT defined in RFC 5234
+      ext-cap-list          = 1*VCHAR  ; VCHAR defined in RFC 5234
+
+   The optional "+" is used to indicate that the extension is mandatory
+   and MUST be supported in order to use that particular configuration.
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 4]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   The new capabilities may also be referenced in actual configurations
+   ("a=acfg") as productions conforming to the <sel-extension-config>
+   defined in RFC 5939 [RFC5939].
+
+         sel-extension-config = ext-cap-name "=" 1*VCHAR
+
+   The specific parameters are defined in the individual description of
+   each capability below.
+
+   The "bcap", "ccap", and "icap" capability attributes can be provided
+   at the SDP session and/or media level.  According to the SDP
+   Capability Negotiation [RFC5939], each extension capability must
+   specify the implication of making it part of a configuration at the
+   media level.
+
+   According to SDP [RFC4566], "b=", "c=", and "i=" lines may appear at
+   either session or media level.  In line with this, the "bcap",
+   "ccap", and "icap" capability attributes, when declared at session
+   level, are to be interpreted as if that attribute was provided with
+   that value at the session level.  The "bcap", "ccap", and "icap"
+   capability attributes declared at media level are to be interpreted
+   as if that capability attribute was declared at the media level.
+
+   For example, extending the example in [RFC6871] with "icap" and
+   "bcap" capability attributes, we get the following SDP:
+
+         v=0
+         o=- 25678 753849 IN IP4 192.0.2.1
+         s=
+         c=IN IP4 192.0.2.1
+         t=0 0
+         a=bcap:1 CT:200
+         a=icap:1 Video conference
+         m=audio 54320 RTP/AVP 0
+         a=rmcap:1 L16/8000/1
+         a=rmcap:2 L16/16000/2
+         a=pcfg:1 m=1|2 pt=1:99,2:98
+         m=video 66544 RTP/AVP 100
+         a=rmcap:3 H263-1998/90000
+         a=rtpmap:100 H264/90000
+         a=pcfg:10 m=3 pt=3:101 b=1 i=1
+
+              Figure 1: Example SDP offer with bcap and icap
+                          efined at session level
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 5]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   The above SDP defines one PCMU audio stream and one H.264 video
+   stream.  It also defines two RTP-based media capabilities ("rmcap"
+   numbered 1 and 2), using 16-bit linear (L16) audio at 8 kbps and 16
+   kbps, respectively, as well as an RTP-based media capability for
+   H.263 video ("rmcap" numbered 3).  The RTP-based media capabilities
+   all appear at the media level.  The example also contains a single
+   bandwidth capability ("bcap") and a single title capability ("icap"),
+   both defined at session level.  According to the definition above,
+   when the capabilities defined in the "bcap" and "icap" attributes are
+   referenced from the potential configuration, in the resulting SDP
+   they are to be interpreted as session-level attributes (but the
+   RTP-based media capabilities are to be interpreted as media-level
+   attributes).
+
+3.1.1.  Bandwidth Capability
+
+   According to RFC 4566 [RFC4566], the bandwidth field denotes the
+   proposed bandwidth to be used by the session or media.  In this memo,
+   we specify the bandwidth capability attribute, which can also appear
+   at the SDP session and/or media level.  The bandwidth field is
+   specified in RFC 4566 [RFC4566] with the following syntax:
+
+      b=<bwtype>:<bandwidth>
+
+   where <bwtype> is an alphanumeric modifier giving the meaning of the
+   <bandwidth> figure.
+
+   In this document, we define a new capability attribute: the bandwidth
+   capability attribute "bcap".  This attribute lists bandwidth as
+   capabilities, according to the following definition:
+
+      "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF
+
+   where <bw-cap-num> is a unique integer within all the bandwidth
+   capabilities in the entire SDP, which is used to number the bandwidth
+   capability and can take a value between 1 and 2^31-1 (both included).
+   The other elements are as defined for the "b=" field in SDP
+   [RFC4566].
+
+   This format satisfies the general attribute production rules in SDP
+   [RFC4566], according to the following Augmented Backus-Naur Form
+   (ABNF) [RFC5234] syntax:
+
+         att-field       =/ "bcap"
+         att-value       =/ bw-cap-num 1*WSP bwtype ":" bandwidth
+         bw-cap-num      = 1*10(DIGIT)   ; DIGIT defined in RFC 5234
+
+                 Figure 2: Syntax of the "bcap" attribute
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 6]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   Negotiation of bandwidth per media stream can be useful when
+   negotiating media encoding capabilities with different bandwidths.
+
+3.1.1.1.  Configuration Parameters
+
+   The SDP Capability Negotiation Framework [RFC5939] provides for the
+   existence of the "pcfg" and "acfg" attributes.  The concept is
+   extended by the SDP Media Capabilities Negotiation [RFC6871] with an
+   "lcfg" attribute that conveys latent configurations.
+
+   Extensions to the "pcfg" and "lcfg" attributes are defined through
+   <extension-config-list>, and extensions to the "acfg" attribute are
+   defined through the <sel-extension-config>, as defined in the SDP
+   Capability Negotiation [RFC5939].
+
+   In this document, we extend the <extension-config-list> field to be
+   able to convey lists of bandwidth capabilities in latent or potential
+   configurations, according to the following Augmented Backus-Naur Form
+   (ABNF) [RFC5234] syntax:
+
+     extension-config-list  =/ bandwidth-config-list
+     bandwidth-config-list  = ["+"] "b=" bw-cap-list *(BAR bw-cap-list)
+                                 ; BAR defined in RFC 5939
+     bw-cap-list            = bw-cap-num *("," bw-cap-num)
+     bw-cap-num             = 1*10(DIGIT)   ; DIGIT defined in RFC 5234
+
+                Figure 3: Syntax of the bandwidth parameter
+                      in "lcfg" and "pcfg" attributes
+
+   Each bandwidth capability configuration is a comma-separated list of
+   bandwidth capability attribute numbers where <bw-cap-num> refers to
+   the <bw-cap-num> bandwidth capability numbers defined explicitly
+   earlier in this document, and hence MUST be between 1 and 2^31-1
+   (both included).  Alternative bandwidth configurations are separated
+   by a vertical bar ("|").
+
+   The above syntax is very flexible, allowing referencing to multiple
+   "b=" lines per configuration, even for the same <bwtype>.  While the
+   need for such definitions is not seen, we have not restricted this,
+   as it is not restricted in SDP [RFC4566] either.
+
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 7]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   The bandwidth parameter to the actual configuration attribute
+   ("a=acfg") is formulated as a <sel-extension-config> with
+
+      ext-cap-name = "b"
+
+   hence
+
+     sel-extension-config =/ sel-bandwidth-config
+     sel-bandwidth-config = "b=" bw-cap-list  ; bw-cap-list as above.
+
+     Figure 4: Syntax of the bandwidth parameter in "acfg" attributes
+
+3.1.1.2.  Option Tag
+
+   The SDP Capability Negotiation Framework [RFC5939] allows for
+   capability negotiation extensions to be defined.  Associated with
+   each such extension is an option tag that identifies the extension in
+   question.  Hereby, we define a new option tag "bcap-v0" that
+   identifies support for the bandwidth capability.  The endpoints using
+   the "bcap" capability attribute SHOULD add the option tag to other
+   existing option tags present in the "csup" and "creq" attributes in
+   SDP, according to the procedures defined in the SDP Capability
+   Negotiation Framework [RFC5939].
+
+3.1.2.  Connection Data Capability
+
+   According to SDP [RFC4566], the connection data field in SDP contains
+   the connection data, and it has the following syntax:
+
+      c=<nettype> <addrtype> <connection-address>
+
+   where <nettype> indicates the network type, <addrtype> indicates the
+   address type, and the <connection-address> is the connection address,
+   which is dependent on the address type.
+
+   At the moment, network types already defined include "IN", which
+   indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]),
+   used for describing Asynchronous Transfer Mode (ATM) bearer
+   connections.  The Circuit-Switched (CS) descriptions in the SDP
+   document [SDP-CS] adds a "PSTN" network type for expressing a Public
+   Switched Telephone Network (PSTN) circuit switch.
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 8]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   SDP [RFC4566] permits specification of connection data at the SDP
+   session and/or media level.  In order to permit negotiation of
+   connection data at the media level, we define the connection data
+   capability attribute ("a=ccap") in the form:
+
+      "a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP
+      connection-address CRLF
+
+   where <conn-cap-num> is a unique integer within all the connection
+   capabilities in the entire SDP, which is used to identify the
+   connection data capability and can take a value between 1 and 2^31-1
+   (both included).  The other elements are as defined in [RFC4566].
+
+   This format corresponds to the [RFC4566] attribute production rules,
+   according to the following Augmented Backus-Naur Form (ABNF)
+   [RFC5234] syntax:
+
+         att-field       =/ "ccap"
+         att-value       =/ conn-cap-num 1*WSP nettype SP addrtype
+                           SP connection-address
+         conn-cap-num    = 1*10(DIGIT)   ; 1 to 2^31-1, inclusive
+                                         ; DIGIT defined in RFC 5234
+
+                 Figure 5: Syntax of the "ccap" attribute
+
+   The "ccap" capability attribute allows for expressing alternative
+   connections address ("c=") lines in SDP as part of the SDP Capability
+   Negotiation process.  One of the primary use cases for this is
+   offering alternative connection addresses where the <nettype> is "IN"
+   or "PSTN", i.e., selecting between an IP-based bearer or a
+   circuit-switched bearer.
+
+   By supporting the "IN" <nettype>, the "ccap" attribute enables the
+   signaling of multiple IPv4 and IPv6 addresses; however, the Standards
+   Track mechanism for negotiation of alternative IP addresses in SDP is
+   Interactive Connectivity Establishment (ICE) [RFC5245].  The "ccap"
+   attribute does not change that; hence, the combined set of actual and
+   potential configurations (as defined in [RFC5939]) for any given
+   media description MUST NOT use the "ccap" attribute to negotiate more
+   than one address with an IN network type (i.e., it is not permissible
+   to select between "IPv4" and "IPv6" address families or different IP
+   addresses within the same IP address family.
+
+   Figure 6 is an example of an SDP offer that includes a "ccap"
+   capability attribute.  An audio stream can be set up with an RTP flow
+   or by establishing a circuit-switched audio stream:
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                    [Page 9]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+             v=0
+             o=2987933123 2987933123 IN IP4 198.51.100.7
+             s=-
+             t=0 0
+             a=creq:med-v0,ccap-v0
+             m=audio 38902 RTP/AVP 0 8
+             c=IN IP4 198.51.100.7
+             a=ccap:1 PSTN E164 +15555556666
+             a=tcap:2 PSTN
+             a=omcap:1 -
+             a=acap:1 setup:actpass
+             a=acap:2 connection:new
+             a=acap:3 cs-correlation:callerid:+15555556666
+             a=pcfg:1 c=1 t=2 m=1 a=1,2,3
+
+            Figure 6: Example SDP offer with a "ccap" attribute
+
+   The example in Figure 6 represents an SDP offer indicating an audio
+   flow using RTP, such as the one represented in Figure 7, or an audio
+   flow using a circuit-switched connection, such as the one represented
+   in Figure 8.
+
+             v=0
+             o=2987933123 2987933123 IN IP4 198.51.100.7
+             s=-
+             t=0 0
+             m=audio 38902 RTP/AVP 0 8
+             c=IN IP4 198.51.100.7
+
+             Figure 7: Equivalent SDP offer with the RTP flow
+
+             v=0
+             o=2987933123 2987933123 IN IP4 198.51.100.7
+             s=-
+             t=0 0
+             m=audio 9 PSTN -
+             c=PSTN E164 +15555556666
+             a=setup:actpass
+             a=connection:new
+             a=cs-correlation:callerid:+15555556666
+
+       Figure 8: Equivalent SDP offer with the circuit-switched flow
+
+   This document does not define any mechanism for negotiating or
+   describing different port numbers; hence, the port number from the
+   "m=" line MUST be used by default.  Exceptions to this default can be
+   provided by extension mechanisms or network type specific rules.
+   This document defines an exception when the network type is "PSTN",
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 10]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   in which case the port number is replaced with 9 (the "discard"
+   port), as described in "Session Description Protocol (SDP) Extension
+   for Setting Audio and Video Media Streams over Circuit-Switched
+   Bearers in the Public Switched Telephone Network (PSTN)" [SDP-CS].
+   An endpoint offering alternative IP and PSTN bearers MUST include the
+   IP media description in the actual configuration (IP address in the
+   "c=" line and port number in the "m=" line) and the PSTN media
+   description in the potential configuration.
+
+   Exceptions for other network types, such as for the "ATM" network
+   type defined in [RFC3108], require additional specifications.
+
+3.1.2.1.  Configuration Parameters
+
+   The SDP Capability Negotiation Framework [RFC5939] provides for the
+   existence of the "pcfg" and "acfg" attributes, which can convey one
+   or more configurations to be negotiated.  The concept is extended by
+   the SDP Media Capabilities Negotiation [RFC6871] with an "lcfg"
+   attribute that conveys latent configurations.
+
+   In this document, we define a <connection-config> parameter to be
+   used to specify a connection data capability in a potential or latent
+   configuration attribute.  The parameter follows the form of an
+   <extension-config-list> with
+
+      ext-cap-name = "c"
+
+      ext-cap-list = conn-cap-list
+
+   where, according to the following Augmented Backus-Naur Form (ABNF)
+   [RFC5234] syntax:
+
+         extension-config-list =/ conn-config-list
+         conn-config-list      = ["+"] "c=" conn-cap-list
+         conn-cap-list         = conn-cap-num *(BAR conn-cap-num)
+         conn-cap-num          = 1*10(DIGIT)   ; 1 to 2^32-1 inclusive
+
+                  Figure 9: Syntax of the connection data
+                 parameter in "lcfg" and "pcfg" attributes
+
+   Each capability configuration alternative contains a single
+   connection data capability attribute number and refers to the
+   conn-cap-num capability number defined explicitly earlier in this
+   document; hence, the values MUST be between 1 and 2^31-1 (both
+   included).  The connection data capability allows the expression of
+   only a single capability in each alternative, rather than a list of
+   capabilities, since no more than a single connection data field is
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 11]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   permitted per media block.  Nevertheless, it is still allowed to
+   express alternative potential connection configurations separated by
+   a vertical bar ("|").
+
+   An endpoint includes a plus sign ("+") in the configuration attribute
+   to mandate support for this extension.  An endpoint that receives
+   this parameter prefixed with a plus sign and does not support this
+   extension MUST treat that potential configuration as not valid.
+
+   The connection data parameter to the actual configuration attribute
+   ("a=acfg") is formulated as a <sel-extension-config> with
+
+      ext-cap-name = "c"
+
+   hence
+
+         sel-extension-config =/ sel-connection-config
+         sel-connection-config = "c=" conn-cap-num  ; as defined above.
+
+            Figure 10: Syntax of the connection data parameter
+                           in "acfg" attributes
+
+3.1.2.2.  Option Tag
+
+   The SDP Capability Negotiation Framework [RFC5939] solution allows
+   for capability negotiation extensions to be defined.  Associated with
+   each such extension is an option tag that identifies the extension in
+   question.  Hereby, we define a new option tag of "ccap-v0" that
+   identifies support for the connection data capability.  This option
+   tag SHOULD be added to other existing option tags present in the
+   "csup" and "creq" attributes in SDP, according to the procedures
+   defined in the SDP Capability Negotiation Framework [RFC5939].
+
+3.1.3.  Title Capability
+
+   SDP [RFC4566] provides for the existence of an information field
+   expressed in the format of the "i=" line, which can appear at the SDP
+   session and/or media level.  An "i=" line that is present at the
+   session level is known as the "session name", and its purpose is to
+   convey human-readable textual information about the session.
+
+   The "i=" line in SDP can also appear at the media level, in which
+   case it is used to provide human-readable information about the media
+   stream to which it is related; for example, it may indicate the
+   purpose of the media stream.  The "i=" line is not to be confused
+   with the label attribute ("a=label:", [RFC4574]), which provides a
+   machine-readable tag.  It is foreseen that applications declaring
+   capabilities related to different configurations of a media stream
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 12]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   may need to provide different identifying information for each of
+   those configurations.  That is, a party might offer alternative media
+   configurations for a stream, each of which represents a different
+   presentation of the same or similar information.  For example, an
+   audio stream might offer English or Spanish configurations, or a
+   video stream might offer a choice of video source such as speaker
+   camera, group camera, or document viewer.  The title capability is
+   needed to inform the answering user in order to select the proper
+   choice, and the label is used to inform the offering machine which
+   choice the answerer has selected.  Hence, there is value in defining
+   a mechanism to provide titles of media streams as capabilities.
+
+   As defined in SDP [RFC4566], the session information field ("i=",
+   referred to as "title" in this document) is subject to the
+   "a=charset" attribute in order to support different character sets
+   and hence internationalization.  The title capability attribute
+   itself ("a=icap") is, however, not subject to the "a=charset"
+   attribute as this would preclude the inclusion of alternative
+   session/title information each using different character sets.
+   Instead, the session/title value embedded in an "a=icap" attribute
+   (title capability) will be subject to the "a=charset" value used
+   within a configuration that includes that title capability.  This
+   provides for consistent SDP operation while allowing for capabilities
+   and configurations with different session/title information values
+   with different character set encodings (with each such configuration
+   including an "a=charset" value with the relevant character set for
+   the session/title information in question).
+
+   According to SDP [RFC4566], the session information ("i=") line has
+   the following syntax:
+
+      "i=" text
+
+   where "text" represents a human-readable text indicating the purpose
+   of the session or media stream.
+
+   In this document, we define a new capability attribute: the title
+   capability "icap".  This attribute lists session or media titles as
+   capabilities, according to the following definition:
+
+      "a=icap:" title-cap-num 1*WSP text
+
+   where <title-cap-num> is a unique integer within all the connection
+   capabilities in the entire SDP, which is used to identify the
+   particular title capability and can take a value between 1 and 2^31-1
+   (both included). <text> is a human-readable text that indicates the
+   purpose of the session or media stream it is supposed to
+   characterize.
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 13]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   As an example, one might use:
+
+      a=icap:1 Document Camera
+
+   to define a title capability number 1 to identify a particular source
+   of a media stream.
+
+   Or, in another example, one might offer two title capabilities with
+   different character encodings (using the charset attribute defined in
+   "SDP: Session Description Protocol" [RFC4566] and the generic
+   attribute capability attribute ("a=acap:") defined in "Session
+   Description Protocol (SDP) Capability Negotiation" [RFC5939]).
+
+               a=icap:1 [Text encoded in ISO-8859-1]
+               a=acap:1 charset:ISO-8859-1
+               a=icap:2 [Text encoded in UTF-8]
+               a=acap:2 charset:UTF-8
+
+
+   NOTE: Due to limitations of the ASCII encoding of RFCs, the actual
+   text with non-printable characters cannot be represented in the text.
+   See the PDF format of this RFC for a figure with non-printable
+   characters.
+
+   The title capability attribute satisfies the general attribute
+   production rules in SDP [RFC4566], according to the following
+   Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
+
+         att-field       =/ "icap"
+         att-value       =/ title-cap-num 1*WSP text
+                                     ; text defined in RFC 4566
+         title-cap-num   = 1*10(DIGIT)   ; DIGIT defined in RFC 5234
+
+                 Figure 11: Syntax of the "icap" attribute
+
+3.1.3.1.  Configuration Parameters
+
+   The SDP Capability Negotiation Framework [RFC5939] provides for the
+   existence of the "pcfg" and "acfg" attributes.  The concept is
+   extended by the SDP Media Capabilities Negotiation [RFC6871] with an
+   "lcfg" attribute that conveys latent configurations.
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 14]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   In this document, we define a <title-config-list> parameter to be
+   used to convey title capabilities in a potential or latent
+   configuration.  This parameter is defined as an
+   <extension-config-list> with the following associations:
+
+      ext-cap-name = "i"
+
+      ext-cap-list = title-cap-list
+
+   This leads to the following definition for the title capability
+   parameter:
+
+         extension-config-list =/ title-config-list
+         title-config-list     = ["+"] "i=" title-cap-list
+         title-cap-list        = title-cap-num *(BAR title-cap-num)
+                                         ; BAR defined in RFC 5939
+         title-cap-num         = 1*10(DIGIT) ; DIGIT defined in RFC 5234
+
+            Figure 12: Syntax of the title capability parameter
+                      in "lcfg" and "pcfg" attributes
+
+   Each potential capability configuration contains a single title
+   capability attribute number where "title-cap-num" is the title
+   capability number defined explicitly earlier in this document, and
+   hence must be between 1 and 2^31-1 (both included).  The title
+   capability allows the expression of only a single capability in each
+   alternative, since no more than a single-title field is permitted per
+   block.  Nevertheless, it is still allowed to express alternative
+   potential title configurations separated by a vertical bar ("|").
+
+   An endpoint includes a plus sign ("+") in the configuration attribute
+   to mandate support for this extension.  An endpoint that receives
+   this parameter prefixed with a plus sign and does not support this
+   extension MUST treat that potential configuration as not valid.
+
+   The title parameter to the actual configuration attribute ("a=acfg")
+   is formulated as a <sel-extension-config> with
+
+      ext-cap-name = "i"
+
+   hence
+
+         sel-extension-config =/ sel-title-config
+         sel-title-config = "i=" title-cap-num  ; as defined above.
+
+       Figure 13: Syntax of the title parameter in "acfg" attributes
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 15]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+3.1.3.2.  Option Tag
+
+   At present, it is difficult to envision a scenario in which the
+   "icap" attribute must be supported or the offer must be rejected.  In
+   most cases, if the icap attribute or its contents were to be ignored,
+   an offered configuration could still be chosen based on other
+   criteria such as configuration numbering.  However, one might imagine
+   an SDP offer that contained English and Spanish potential
+   configurations for an audio stream.  The session might be
+   unintelligible if the choice is based on configuration numbering,
+   rather than informed user selection.  Based on such considerations,
+   it may well prove useful to announce the ability to use the icap
+   attribute and its contents to select media configurations, or to
+   inform the user about the selected configuration(s).  Therefore, we
+   define a new option tag of "icap-v0" that identifies support for the
+   title capability.  This option tag SHOULD be added to other existing
+   option tags present in the "csup" and/or "creq" attributes in SDP,
+   according to the procedures defined in the SDP Capability Negotiation
+   Framework [RFC5939].  The discussion above suggests that "icap-v0"
+   will typically appear in a "csup" attribute, but rarely in a "creq"
+   attribute.
+
+3.2.  Session Level versus Media Level
+
+   The "bcap", "ccap", and "icap" attributes can appear at the SDP
+   session and/or media level.  Endpoints MUST interpret capabilities
+   declared at session level as part of the session level in the
+   resulting SDP for that particular configuration.  Endpoints MUST
+   interpret capabilities declared at media description as part of the
+   media level in the resulting SDP for that particular configuration.
+
+   The presence of the "bcap" capability for the same <bwtype> at both
+   the session and media level is subject to the same constraints and
+   restrictions specified in RFC 4566 [RFC4566] for the bandwidth
+   attribute "b=".
+
+   To avoid confusion, the <type-attr-num> for each "a=bcap", "a=ccap",
+   and "a=icap" line MUST be unique across all capability attributes of
+   the same type within the entire session description.
+
+
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 16]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+3.3.  Offer/Answer Model Extensions
+
+   In this section, we define extensions to the offer/answer model
+   defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP
+   Capability Negotiation [RFC5939] to allow for bandwidth, connection,
+   and title capabilities to be used with the SDP Capability Negotiation
+   Framework.
+
+3.3.1.  Generating the Initial Offer
+
+   When an endpoint generates an initial offer and wants to use the
+   functionality described in the current document, it first defines
+   appropriate values for the bandwidth, connection data, and/or title
+   capability attributes according to the rules defined in [RFC4566] for
+   "b=", "c=", and "i=" lines.  The endpoint then MUST include the
+   respective capability attributes and associated values in the SDP
+   offer.  The preferred configurations for each media stream are
+   identified following the media line in a "pcfg" attribute.  Bandwidth
+   and title capabilities may also be referenced in latent
+   configurations in an "lcfg" attribute, as defined in the SDP Media
+   Capabilities Negotiation [RFC6871].
+
+   Implementations are advised to pay attention to the port number that
+   is used in the "m=" line.  By default, a potential configuration that
+   includes a connection data capability will use the port number from
+   the "m=" line, unless the network type is "PSTN", in which case the
+   default port number used will be 9.
+
+   The offer SHOULD include the level of capability negotiation
+   extensions needed to support this functionality in a "creq"
+   attribute.
+
+3.3.2.  Generating the Answer
+
+   When the answering party receives the offer, and if it supports the
+   required capability negotiation extensions, it SHOULD select the most
+   preferred configuration it can support for each media stream and
+   build the answer accordingly, as defined in Section 3.6.2 of the SDP
+   Capability Negotiation [RFC5939].
+
+   If the connection data capability is used in a selected potential
+   configuration chosen by the answerer, that offer configuration MUST
+   by default use the port number from the actual offer configuration
+   (i.e., the "m=" line), unless the network type is "PSTN", in which
+   case the default port MUST be assumed to be 9.  Extensions may be
+   defined to negotiate the port number explicitly instead.
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 17]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+3.3.3.  Offerer Processing of the Answer
+
+   When the offerer receives the answer, it MUST process the media lines
+   according to normal SDP processing rules to identify the media
+   stream(s) accepted by the answer, if any, as defined in Section 3.6.3
+   of the SDP Capability Negotiation [RFC5939].  The "acfg" attribute,
+   if present, MUST be used to verify the proposed configuration used to
+   form the answer and to infer the lack of acceptability of
+   higher-preference configurations that were not chosen.
+
+3.3.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 SDP offer/answer [RFC3264] and in
+   accordance with the procedures defined in Section 3.6.4 of the SDP
+   Capability Negotiation [RFC5939].
+
+4.  Field Replacement Rules
+
+   To simplify the construction of SDP records, given the need to
+   include fields within the media description in question for endpoints
+   that do not support capabilities negotiation, we define some simple
+   field-replacement rules for those fields invoked by potential or
+   latent configurations.  In particular, any "i=" or "c=" lines invoked
+   by a configuration MUST replace the corresponding line, if present
+   within the media description in question.  Any "b=" line invoked by a
+   configuration MUST replace any "b=" of the same bandwidth type at the
+   media level, but not at the session level.
+
+5.  Security Considerations
+
+   This document provides an extension on top of the SDP [RFC4566], SDP
+   Offer/Answer Model [RFC3264], SDP Capability Negotiation Framework
+   [RFC5939], and SDP Media Capabilities Negotiation [RFC6871].  As
+   such, the security considerations of those documents apply.
+
+   The bandwidth capability attribute may be used for reserving
+   resources at endpoints and intermediaries that inspect SDP.
+   Modification of the bandwidth value by an attacker can lead to the
+   network being underutilized (too high bandwidth value) or congested
+   (too low bandwidth value).
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 18]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   Similarly, by modifying the alternative connection address(es), an
+   attacker would be able to direct media streams to a desired endpoint,
+   thus launching a version of the well-known voice hammer attack (see
+   Section 18.5.1 of [RFC5245]).
+
+   The title capability provides for alternative "i=" line information,
+   which is intended for human consumption.  However, manipulating the
+   textual information could be misused to provide false information,
+   leading to a bad user experience or the person using the service
+   making a wrong choice regarding the available media streams.
+
+   In case it is essential to protect the capability attribute values,
+   one of the security mechanisms proposed in [RFC5939] SHOULD be used.
+
+   The "i=" line, and thus the value carried in the title capability
+   attribute, is intended for human-readable description only.  It
+   should not be parsed programmatically.
+
+6.  IANA Considerations
+
+6.1.  New SDP Attributes
+
+   IANA has registered new attributes in the "att-field (both session
+   and media level)" subregistry of the "Session Description Protocol
+   (SDP) Parameters" registry, according to the following registration
+   form:
+
+      Attribute name:      bcap
+      Long form name:      Bandwidth Capability
+      Type of attribute:   Both media and session level
+      Subject to charset:  No
+      Purpose:             Negotiate session or media-level bandwidths
+      Appropriate values:  See RFC 7066, Section 3.1.1
+      Contact name:        Miguel A. Garcia
+                           Miguel.A.Garcia@ericsson.com
+
+      Attribute name:      ccap
+      Long form name:      Connection Data Capability
+      Type of attribute:   Both media and session level
+      Subject to charset:  No
+      Purpose:             Negotiate media-level connection data
+      Appropriate values:  See RFC 7066, Section 3.1.2
+      Contact name:        Miguel A. Garcia
+                           Miguel.A.Garcia@ericsson.com
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 19]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+      Attribute name:      icap
+      Long form name:      Title Capability
+      Type of attribute:   Both media and session level
+      Subject to charset:  Yes
+      Purpose:             Negotiate human-readable information
+                           describing the session or media
+      Appropriate values:  See RFC 7066, Section 3.1.3
+      Contact name:        Miguel A. Garcia
+                           Miguel.A.Garcia@ericsson.com
+
+6.2.  New Option Tags
+
+   IANA has added the new option tags "bcap-v0", "ccap-v0", and "icap-
+   v0", defined herein, to the "SDP Capability Negotiation Option Tag"
+   subregistry of the "Session Description Protocol (SDP) Parameters"
+   registry.
+
+6.3.  New SDP Capability Negotiation Configuration Parameters
+
+   IANA has added the new parameter identifiers "b" for "Bandwidth", "c"
+   for "Connection Data", and "i" for "Title" to the "SDP Capability
+   Negotiation Configuration Parameters" subregistry of the "Session
+   Description Protocol (SDP) Parameters" registry.  These parameters
+   are permitted in "lcfg", "acfg", and "pcfg" attributes.
+
+7.  Acknowledgments
+
+   Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson
+   for arguing for the existence of this document and reviewing it in
+   the early stages.  Thanks to Flemming Andreasen, Andrew Allen, and
+   Jonathan Lennox for a detailed review and many suggestions for
+   improvement.
+
+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.
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 20]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+   [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.
+
+   [RFC6871]  Gilman, R., Even, R., and F. Andreasen, "Session
+              Description Protocol (SDP) Media Capabilities
+              Negotiation", RFC 6871, February 2013.
+
+8.2.  Informative References
+
+   [RFC3108]  Kumar, R. and M. Mostafa, "Conventions for the use of the
+              Session Description Protocol (SDP) for ATM Bearer
+              Connections", RFC 3108, May 2001.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
+              Protocol (SDP) Label Attribute", RFC 4574, August 2006.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245, April
+              2010.
+
+   [SDP-CS]   Garcia, M. and S. Veikkolainen, "Session Description
+              Protocol (SDP) Extension for Setting Audio and Video Media
+              Streams over Circuit-Switched Bearers in the Public
+              Switched Telephone Network (PSTN)", Work in Progress, June
+              2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 21]
+
+RFC 7006           SDP Misc. Capabilities Negotiation     September 2013
+
+
+Authors' Addresses
+
+   Miguel A. Garcia-Martin
+   Ericsson
+   Calle Via de los Poblados 13
+   Madrid  28033
+   Spain
+
+   Phone: +34 91 339 1000
+   EMail: miguel.a.garcia@ericsson.com
+
+
+   Simo Veikkolainen
+   Nokia
+   P.O. Box 226
+   NOKIA GROUP, FI  00045
+   Finland
+
+   Phone: +358 50 486 4463
+   EMail: simo.veikkolainen@nokia.com
+
+
+   Robert R. Gilman
+   3243 W. 11th Ave. Dr.
+   Broomfield, Colorado  80020
+   U.S.A.
+
+   Phone: +1 303 898 9780
+   EMail: bob_gilman@comcast.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Garcia-Martin, et al.        Standards Track                   [Page 22]
+