| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2009.
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 a number of miscellaneous SDP capabilities. In particular, this memo provides a mechanism to negotiate media titles ("i=" line for each media), connection data ("c=" line), and media bandwidth ("b=" line).
1.
Introduction
2.
Conventions Used in This Document
3.
Protocol Description
3.1.
Extensions to SDP
3.1.1.
Bandwidth Capability
3.1.2.
Connection Data Capability
3.1.3.
Information Capability
3.2.
Session Level versus Media Level
4.
Field Replacement Rules
5.
IANA Considerations
5.1.
New SDP Attributes
5.2.
New Option Tags
6.
Security Considerations
7.
Acknowledgments
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The Session Description Protocol (SDP) (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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 a capability negotiation mechanism framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] that allows the endpoints to negotiate capabilities, such as support for Realtime Transport Protocol (RTP) (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [RFC3550] and Secure Realtime Transport Protocol (SRTP) (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711]. The SDP media capabilities (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [I‑D.ietf‑mmusic‑sdp‑media‑capabilities] provides negotiation capabilities to media lines as well.
This negotiation is embedded into the widely used SDP offer/answer procedures (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [RFC3264]. This memo provides the means to negotiate further capabilities than those specified in the SDP capability negotiation mechanism framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] and the SDP media capabilities (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [I‑D.ietf‑mmusic‑sdp‑media‑capabilities]. In particular, this memo provides a mechanism to negotiate media titles ("i="), connection data ("c="), and media bandwidth ("b="). It would have been possible to define a mechanism to negotiate media encryption keys ("k="). However, the usage of the media encryption keys ("k=") is highly discouraged in favour of other existing more sophisticated mechanisms. Therefore, we are not providing a mechanism to provide capabilities for media encryption keys ("k=") at this stage.
Since the three added capabilities are highly unconnected, it is not expected that implementations will support all three at the same time. Instead, it is expected that applications will choose their needed capability for their specific purpose. Due to this, we are writing the normative part pertaining to each capability in a self-contained section. In particular, Section 3.1.1 (Bandwidth Capability) describes the bandwidth capability extension, Section 3.1.2 (Connection Data Capability) describes the connection data capability extension, and Section 3.1.3 (Information Capability) describes the information capability extension. Separate option tags are defined for each capability.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.
| TOC |
| TOC |
The SDP Capability Negotiation Framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] and the SDP media capabilities (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [I‑D.ietf‑mmusic‑sdp‑media‑capabilities] specify attributes for negotiating SDP capabilities. These documents specify new attributes (e.g., 'acap', 'tcap', 'mcap') for achieving their purpose. In this document we define a number of new additional capability attributes for SDP lines of the the general form:
type=value
for types "i", "c", and "b". The corresponding capability attributes are defined as "icap", "ccap", and "bcap", respectively.
From the sub-rules of "a=" line in SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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 attributes may be referenced in potential configurations ("a=pcfg") or in latent configurations ("a=lcfg"), as productions conforming to the extension-config-list as defined in [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] (Andreasen, F., “SDP Capability Negotiation,” March 2010.).
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list ext-cap-name = 1*(ALPHA / DIGIT) ext-cap-list = 1*VCHAR ; defined in [RFC4234]
The optional "+" is used to indicate that the entire configuration, not just the parameter, must be ignored if the parameter is not supported. The attributes may be referenced in actual configurations as productions conforming to the sel-extension-config defined in [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] (Andreasen, F., “SDP Capability Negotiation,” March 2010.).
sel-extension-config = ext-cap-name "=" 1*VCHAR
The specific parameters are defined in the individual description of each capability, below.
It is not the intention of this work to negotiate these new capabilities at the session level, rather only at the media level. Therefore, capabilities referenced by any configuration attribute MUST appear at the media level when a configuration is "converted" to a corresponding media block. For this reason, the "icap" attribute is called the "media information capability". Specific values for each new attribute are described below.
| TOC |
According to RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] the bandwidth field denotes the proposed bandwidth to be used by the session or media. For what it concerns this memo, we focus on the bandwidth at the media level. This bandwidth field is specified in RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] according to 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 ordinal identifier of the bandwidth capability, and the other elements are as defined for the "b=" field in [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.).
This format satisfies the general attribute production rules in [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) according to the following Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] syntax:
att-field = "bcap" att-value = bw-cap-num 1*WSP bwtype ":" bandwidth bw-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive
Negotiation of bandwidth per media stream can be useful when negotiating media encoding capabilities with different bandwidths.
| TOC |
The SDP Capability Negotiation Framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] provides for the existence of the "pcfg" and "acfg" attributes, which can carry one or more potential configurations to be negotiated. The concept is extended by the the Media Capabilities Negotiation (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [I‑D.ietf‑mmusic‑sdp‑media‑capabilities] 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 [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] (Andreasen, F., “SDP Capability Negotiation,” March 2010.).
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) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] syntax:
extension-config-list = bandwidth-config-list bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR b-cap-list) bw-cap-list = bw-cap-num *("," b-cap-num) bw-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive
| Figure 1: 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 'b-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 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 2: Syntax of the bandwidth parameter in acfg attributes |
| TOC |
The SDP Capability Negotiation Framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] 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 "bcap-v0" that identifies support for the bandwidth 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 (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation].
| TOC |
According to SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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, the only network type defined is "IN", which indicates Internet network type. The address types "IP4" and "IP6" indicate the type of IP addresses.
SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] permits specification of connection data at the session or at the 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 ordinal identifier of the connection data capability, and the other elements are as defined in [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.).
This format corresponds to the [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) attribute production rules according to the following Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] syntax:
att-field = "ccap" att-value = conn-cap-num 1*WSP nettype SP addrtype SP connection-address conn-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive
The connection information capability can be used to negotiate the use of IPv4 or IPv6 addresses without resort to Interactive Connectivity Establishment(ICE) (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) [I‑D.ietf‑mmusic‑ice]. Note, however, that ICE provides for real-time reachability testing of multiple addresses, whereas use of the connection capability forces an early choice of connection address.
| TOC |
The SDP Capability Negotiation Framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] provides for the existence of the "pcfg" and "acfg" attributes, which can carry one or more potential configurations to be negotiated. The concept is extended by the the Media Capabilities Negotiation (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [I‑D.ietf‑mmusic‑sdp‑media‑capabilities] 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) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [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*DIGIT ; 1 to 2^32-1 inclusive
| Figure 3: 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, and hence 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 permitted per media block. Nevertheless, it is still allowed to express alternative potential connection configurations separated by a vertical bar ("|").
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 4: Syntax of the connection data parameter in acfg attributes |
| TOC |
The SDP Capability Negotiation Framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] 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 (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation].
| TOC |
RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] provides for the existence of an information field expressed in the format of the "i=" line, which can appear either at the session level or at the media level. An "i=" line that is present at the session level is known as the "session name", and its purpose is to convey a human-readable textual information about the session. We don't see much usage of capabilities related to the "i=" line at the session level.
The "i=" line in SDP can also appear at the media level, in which case it is used to label the media stream it is related to, so that it indicates the purpose of the media stream. In this case, it is foreseen that applications declaring capabilities related to different media lines also need to provide different labels to media streams that are substantially different. For example, if two media streams are offered one as alternative to the other, most likely their associated labels are different. Hence, there is value in defining a mechanism to provide labels of media streams as capabilities.
According to SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566], the media label has the following syntax:
"i="text
where "text" represents a human-readable text indicating the purpose of the media stream.
In this document we define a new capability attribute: the information media capability, "icap". This attribute lists information media labels as capabilities, according to the following definition:
"a=icap:" info-cap-num 1*WSP text
where <info-cap-num> is the ordinal identifier of the particular media information capability and <text> is a human-readable text that indicates the purpose of the media stream it is supposed to characterize.
As an example, one might use:
a=icap:1 Document Camera
to represent a purpose of a media stream identified with the capability number 1.
The media information capability attribute satisfies the general attribute production rules in [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) according to the following Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] syntax:
att-field = "icap" att-value = info-cap-num 1*WSP text ; text is defined in RFC 4566 info-cap-num = 1*DIGIT ; integer between 1 and 2^31-1
| TOC |
The SDP Capability Negotiation Framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] provides for the existence of the "pcfg" and "acfg" attributes, which can carry one or more potential configurations to be negotiated. The concept is extended by the the Media Capabilities Negotiation (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [I‑D.ietf‑mmusic‑sdp‑media‑capabilities] with an "lcfg" attribute that conveys latent configurations.
In this document, we define an <info-config-list> parameter to be used to convey information 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 = info-cap-list
This leads to the following definition for the information capability parameter:
extension-config-list = info-config-list info-config-list = "i=" info-cap-list info-cap-list = info-cap-num *(BAR info-cap-num) info-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive ; BAR defined in SDP capabilities ; negotiation
| Figure 5: Syntax of the information capability parameter in lcfg and pcfg attributes |
Each potential capability configuration contains a single information capability attribute number where 'info-cap-num' is the information capability number defined explicitly earlier in this document, and hence must be between 1 and 2^31-1 (both included). The information capability allows the expression of only a single capability in each alternative, since no more than a single information field is permitted per media block. Nevertheless, it is still allowed to express alternative potential information configurations separated by a vertical bar ("|").
| TOC |
The information field ("i=") in SDP, rather than providing information for a software application, provides information for a human user. Therefore, it is questionable whether the text in the information field or the information capability is relevant for negotiating SDP capabilities. In particular, unlike the bandwidth and the connection data capabilities, there are no compelling use cases that hint for the definition of an option tag for the information capability. This is because it is not expected that an endpoint would declare that the negotiation should fail if the information field (which is for human consumption) is not understood. As a consequence, we do not define an option tag associated to the information capability.
| TOC |
The icap, ccap, and bcap attributes can appear at the session level and/or at the media level, but MUST be interpreted as a media-level capability. To avoid confusion, the <type-attr-num> for each line must be unique across all capability attributes of the same type within the entire session description. As described below, these capability attributes may be referenced by acfg, pcfg and/or lcfg attributes.
| TOC |
To simplify the construction of SDP records, given the need to include fields at the base level 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-field or c-field invoked by a configuration MUST replace the corresponding field, if present at the base media level. Any b-field invoked by a configuration MUST replace any b-field of the same bandwidth type at the media level.
| TOC |
| TOC |
IANA is hereby requested to register the following new SDP attributes:
Attribute name: icap
Long form name: Information Capability
Type of attribute: Media-level
Subject to charset: No
Purpose: Negotiate human-readable media information
Appropriate values: See Section 3.1.3 (Information Capability)
Attribute name: ccap
Long form name: Connection Data Capability
Type of attribute: Media-level
Subject to charset: No
Purpose: Negotiate media-level connection data
Appropriate values: See Section 3.1.2 (Connection Data Capability)
Attribute name: bcap
Long form name: Bandwidth Capability
Type of attribute: Media-level
Subject to charset: No
Purpose: Negotiate media-level bandwidths
Appropriate values: See Section 3.1.1 (Bandwidth Capability)
| TOC |
IANA is hereby requested to add the new option tags "ccap-v0" and "bcap-v0", defined herein, to the SDP Capability Negotiation Option Tag Registry.
| TOC |
This document provides an extension on top of RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566], RFC 3264 (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [RFC3264], SDP Capability Negotiation Framework (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation], and SDP Media Capabilities Negotiation (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [I‑D.ietf‑mmusic‑sdp‑media‑capabilities]. As such, the security considerations of those documents apply.
| TOC |
Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson for arguing for the existence of this document and early reviewing it.
| TOC |
| TOC |
| [I-D.ietf-mmusic-sdp-capability-negotiation] | Andreasen, F., “SDP Capability Negotiation,” draft-ietf-mmusic-sdp-capability-negotiation-13 (work in progress), March 2010 (TXT). |
| [I-D.ietf-mmusic-sdp-media-capabilities] | Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” draft-ietf-mmusic-sdp-media-capabilities-09 (work in progress), February 2010 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3264] | Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” RFC 3264, June 2002 (TXT). |
| [RFC4566] | Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT). |
| [RFC5234] | Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT). |
| TOC |
| [I-D.ietf-mmusic-ice] | Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” draft-ietf-mmusic-ice-19 (work in progress), October 2007 (TXT). |
| [RFC3550] | Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF). |
| [RFC3711] | Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” RFC 3711, March 2004 (TXT). |
| TOC |
| 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 407 | |
| NOKIA GROUP, FI 00045 | |
| Finland | |
| Phone: | +358 50 486 4463 |
| Email: | simo.veikkolainen@nokia.com |
| Robert R. Gilman | |
| NDCI | |
| 3243 W. 11th Ave. Dr. | |
| Broomfield, Colorado 80020 | |
| U.S.A. | |
| Phone: | +1 303 898 9780 |
| Email: | bob_gilman@comcast.net |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.