From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6796.txt | 2411 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2411 insertions(+) create mode 100644 doc/rfc/rfc6796.txt (limited to 'doc/rfc/rfc6796.txt') diff --git a/doc/rfc/rfc6796.txt b/doc/rfc/rfc6796.txt new file mode 100644 index 0000000..b8547ad --- /dev/null +++ b/doc/rfc/rfc6796.txt @@ -0,0 +1,2411 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Hilt +Request for Comments: 6796 Bell Labs/Alcatel-Lucent +Category: Standards Track G. Camarillo +ISSN: 2070-1721 Ericsson + J. Rosenberg + jdrosen.net + D. Worley + Ariadne + December 2012 + + + A User Agent Profile Data Set for Media Policy + +Abstract + + This specification defines an XML document format to describe the + media properties of Session Initiation Protocol (SIP) sessions. + Examples for media properties are the codecs or media types used in + the session. This document also defines an XML document format to + describe policies that limit the media properties of SIP sessions. + +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/rfc6796. + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 1] + +RFC 6796 Media Policy Data Set December 2012 + + +Copyright Notice + + Copyright (c) 2012 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 ....................................................4 + 2. Terminology .....................................................5 + 3. Media Policy Data Set Format ....................................5 + 3.1. Namespace and Media Type ...................................5 + 3.2. Extensibility ..............................................5 + 3.3. Attributes .................................................6 + 3.3.1. The 'visibility' Attribute ..........................6 + 3.3.2. The 'direction' Attributes ..........................6 + 3.3.3. The 'q' Attribute ...................................6 + 3.3.4. The 'media-type' Attribute ..........................7 + 3.3.5. The 'label' Attribute ...............................7 + 3.3.6. The 'enabled' Attribute .............................7 + 4. Session Info Documents ..........................................7 + 4.1. Mapping between SDP and Session Info Documents .............8 + 4.2. The Element ................................10 + 4.3. The Element .....................................10 + 4.3.1. The Element ...............................10 + 4.4. The Element ........................11 + 4.4.1. The Element ...................12 + 4.4.2. The Element ....................13 + 4.4.3. The Element ....................13 + 5. Session Policy Documents .......................................14 + 5.1. Merging Session Policies ..................................14 + 5.1.1. Single Value Selection .............................14 + 5.1.2. Merging Sets .......................................15 + 5.1.3. Local Policy Server Selection ......................16 + 5.2. The Element ..............................16 + 5.3. The Element .........................16 + 5.4. The Element ........................17 + 5.5. The Element ..............................17 + 5.6. The Element .............................18 + + + +Hilt, et al. Standards Track [Page 2] + +RFC 6796 Media Policy Data Set December 2012 + + + 5.7. The Element .................................18 + 6. Common Media Policy Data Set Elements ..........................19 + 6.1. The Element ..................................19 + 6.2. The Element .......................................19 + 6.2.1. The Element ...................20 + 6.2.2. The Element .......................20 + 6.3. The Element ......................................20 + 6.4. The Element ..............................21 + 6.5. The Element ...............................21 + 6.6. The Element ....................................22 + 6.7. The Element .....................................23 + 6.7.1. The Element ....................23 + 6.7.2. The Element ..............................23 + 6.7.3. The Element .................................23 + 6.7.4. The Element ..........................23 + 6.7.5. The Element ................................24 + 6.8. Other Session Properties ..................................24 + 7. Examples .......................................................25 + 7.1. Session Policy Documents ..................................25 + 7.2. Session Information Documents .............................25 + 7.2.1. Example 1 ..........................................25 + 7.2.2. Example 2 ..........................................26 + 8. RELAX NG Definition ............................................29 + 9. Security Considerations ........................................37 + 10. IANA Considerations ...........................................38 + 10.1. Media Type Registration ..................................38 + 10.2. RELAX NG Schema Registration .............................39 + 10.3. URN Sub-Namespace Registration ...........................39 + 11. References ....................................................40 + 11.1. Normative References .....................................40 + 11.2. Informative References ...................................41 + Appendix A. Acknowledgements ......................................42 + + + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 3] + +RFC 6796 Media Policy Data Set December 2012 + + +1. Introduction + + Within the Session Initiation Protocol (SIP) [RFC3261], "A Framework + for Session Initiation Protocol (SIP) User Agent Profile Delivery" + [RFC6080] and "A Framework for SIP Session Policies" [RFC6794] define + mechanisms to convey session policies and configuration information + from a network server to a user agent. An important piece of the + information conveyed to the user agent relates to the media + properties of the SIP sessions set up by the user agent. Examples + for these media properties are the codecs and media types used, the + media-intermediaries to be traversed, or the maximum bandwidth + available for media streams. + + This specification defines a document format for media properties of + SIP sessions: the Media Policy Data Set Format (MPDF). This format + can be used in two ways. First, it can be used to describe the + properties of a given SIP session (e.g., the media types and codecs + used). These MPDF documents are called session info documents and + they are usually created based on the session description of a + session. Second, the MPDF format can be used to define policies for + SIP sessions in a session policy document. A session policy document + defines properties for a session (e.g., the media types allowed in a + session), independent of a specific session description. + + If used with "A Framework for SIP Session Policies" [RFC6794], + session info documents are used in conjunction with session-specific + policies. A session info document is created by a user agent (UA) + based on the current session description and submitted to the policy + server. The policy server examines the session info document, + modifies it if necessary (e.g., by removing video streams if video is + not permitted), and returns the possibly modified session info + document to the UA. Session policy documents, on the other hand, are + used to describe session-independent policies that can be submitted + to the UA independent of a specific session. + + The two types of MPDF documents, session information and session + policy documents, share the same set of XML elements to describe + session properties. Since these elements are used in different + contexts for session info and session policy documents, two different + root elements exist for the two document types: is the + root element for session information documents and + is the root element for session policy documents. + + A user agent can receive multiple session policy documents from + different sources. This can lead to a situation in which the user + agent needs to apply multiple session policy documents to the same + session. This standard specifies merging rules for those XML + elements that can be present in session policy documents. It should + + + +Hilt, et al. Standards Track [Page 4] + +RFC 6796 Media Policy Data Set December 2012 + + + be noted that these merging rules are part of the semantics of a + session policy XML element. User agents implement the merging rules + as part of implementing the element semantics. As a consequence, it + is not possible to build an entity that can mechanically merge two + session policy documents without understanding the semantics of all + elements in the input documents. + + Merging rules are not needed for elements of session information + documents since they are created by one source and describe a + specific session. + +2. Terminology + + 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 RFC 2119 [RFC2119]. + +3. Media Policy Data Set Format + + This section discusses fundamental properties of the Media Policy + Data Set Format (MPDF). + +3.1. Namespace and Media Type + + The MPDF format is based on XML [W3C.REC-xml-20081126]. An MPDF + document MUST be well-formed and MUST be valid according to schemas, + including extension schemas, available to the validator and + applicable to the XML document. MPDF documents MUST be based on XML + 1.0 and MUST be encoded using UTF-8. + + MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The + namespace URIs for elements defined in this specification are URNs + [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] + and extended by [RFC3688]. The namespace URN for the MPDF schema is: + + urn:ietf:params:xml:ns:mediadataset + + The media type for the Media Policy Data Set Format is: + + application/media-policy-dataset+xml + +3.2. Extensibility + + The MPDF format can be extended using XML extension mechanisms if + additional media properties are needed. In particular, elements from + different XML namespaces MAY be present within a MPDF document for + the purposes of extensibility; elements or attributes from unknown + namespaces MUST be ignored. + + + +Hilt, et al. Standards Track [Page 5] + +RFC 6796 Media Policy Data Set December 2012 + + +3.3. Attributes + + The following attributes can be used with elements of the MPDF + format. The specification of each MPDF element lists which of these + attributes can be used. If an element bears an attribute that may + not be used with it, the user agent MUST ignore the attribute. + +3.3.1. The 'visibility' Attribute + + The attribute 'visibility' specifies whether or not the user agent is + advised to display the property value to the user. This is used to + hide setting values that the administrator may not want the user to + see or know. The 'visibility' attribute has two possible values: + + o visible: specifies that display of the property value is not + restricted. This is the default value of the attribute if it is + not specified. + + o hidden: Specifies that the user agent is advised not to display + the property value. Display of the property value may be allowed + using special administrative interfaces, but it is not appropriate + for the ordinary user. + +3.3.2. The 'direction' Attributes + + Some properties are unidirectional and only apply to messages or data + streams transmitted into one direction. For example, a property for + media streams can be restricted to outgoing media streams only. + Unidirectional properties can be expressed by adding a 'direction' + attribute to the respective element. + + The 'direction' attribute can have the following values: + + o recvonly: the property only applies to incoming streams. + + o sendonly: the property only applies to outgoing streams. + + o sendrecv: the property applies to streams in both directions. + This is the default value that is used if the 'direction' + attribute is omitted. + +3.3.3. The 'q' Attribute + + It is possible to express a preference for a certain value relative + to the other values within a set of multiple values that are allowed + within a property. For example, it is possible to express that the + codecs G.711 and G.729 are allowed, but G.711 is preferred. + Preferences are to be expressed by adding a 'q' attribute to a + + + +Hilt, et al. Standards Track [Page 6] + +RFC 6796 Media Policy Data Set December 2012 + + + property element. The 'q' attribute is only allowed in elements that + specify allowed values (as opposed to elements that specify forbidden + values). + + The value of the 'q' attribute is a decimal number within the range + of 0 to 1, inclusive, with two or fewer decimal places. An element + with a higher 'q' value is preferred over one with a lower 'q' value. + +3.3.4. The 'media-type' Attribute + + The media-type attribute is used to define that an element only + applies to streams of a certain media type, as defined in Section + 8.2.1 of [RFC4566]. For example, it may only apply to audio streams. + The value of the 'media-type' attribute MUST be the media type, such + as audio, video, text, or application. + +3.3.5. The 'label' Attribute + + The label attribute is used to identify a specific media stream. The + value of the label attribute is a token, whose syntax is defined in + [RFC4574]. The token can be chosen freely; however, it MUST be + unique among all elements in a session-info document. + +3.3.6. The 'enabled' Attribute + + The 'enabled' attribute specifies whether or not the user agent is + allowed to establish a media stream. This boolean attribute has two + possible values: + + o yes: specifies that the media stream can be established. This is + the default value of the attribute if it is not specified. + + o no: specifies that the user agent MUST NOT establish the media + stream. + +4. Session Info Documents + + Session info documents describe key properties of a SIP session such + as the media streams used in the session. Session info documents are + typically created based on a session description expressed using + Session Description Protocol (SDP) [RFC4566] or an SDP offer/answer + pair [RFC3264]. + + Session info documents can be used for session-specific policies + [RFC6794]. In this usage, a UA creates a session info document based + on its session description(s) and sends this document to the policy + server. The policy server modifies this document according to the + policies that apply to the described session and returns a version of + + + +Hilt, et al. Standards Track [Page 7] + +RFC 6796 Media Policy Data Set December 2012 + + + the session info document that is compliant to the policies. For + example, if video streams are not permissible under current policies + and the UA submits a session info document that contains a video + stream, the policy server will disable (i.e., enabled="no") the video + stream in the session info document that it returns to the UA. + + Session info documents use the root element. They use + elements described in this section and common elements described in + Section 6. + + Elements that are only present in session info documents do not + require merging rules. If used in the context of session-specific + policies, session info documents are sent to one policy server at a + time only; therefore, a UA does not need to merge multiple session + info documents into one. A policy server needs to modify a session + info document it has received according to its policies. The + modification of session info documents is determined by the local + policies of the policy server and is, thus, outside the scope of this + standard. + + A policy server can completely reject a session by returning a + session info document with an empty element: + + + +4.1. Mapping between SDP and Session Info Documents + + This section specifies how to map information in a session + description or an SDP offer/answer pair [RFC3264] to session info + documents. It also specifies how to map a session info document into + a session description. Note that these mapping rules do not include + rules for all elements that need to be present in a session info + document or in a session description. That is, some of those + elements are generated following their associated general rules + (e.g., the general rules to generate SDP "v=" and "t=" lines). + + A UA with a session description that needs to create a session info + document uses the data in the session description and maps it + following the rules below. A UA with an SDP offer/answer pair that + needs to create a session info document uses the data that has been + agreed in the offer/answer exchange. + + A UA MUST create a separate element for each "m=" line in a + session description or SDP offer/answer pair; the order of the + elements corresponds to the order of the "m=" lines. For a + session description, the UA MUST insert the media type from the "m=" + line into a element and MUST create a element + for each codec listed in the "m=" line. For an SDP offer/answer + + + +Hilt, et al. Standards Track [Page 8] + +RFC 6796 Media Policy Data Set December 2012 + + + pair, the UA MUST insert a element for each of the codecs + that were agreed upon for the particular stream in the offer/answer + exchange. The elements MUST have 'q' attributes with values + that decrease with the order the codecs are given in the "m=" line. + (Other than the ordering restriction, the particular values used are + not specified by this document.) + + The UA MUST create a element for each stream using + the port taken from the "m=" line and the address from the + corresponding "c=" line of the local session description. The UA + SHOULD create a element using the port and address + from the "m=" and "c=" lines for the same stream taken from the + remote session description if this session description is available. + (The local SDP is the one sent by the UA; the remote SDP is the one + received from the remote UA.) + + The contains information that may be considered + sensitive from a privacy standpoint. A UA configured not to + disclose that information would not include the + element in its session info documents. + + The numeric value in a "b=CT:..." attribute in a session description + is used to set the content of a element with the direction + attribute value corresponding to which SDP contains the "b=" + attribute. + + The numeric value in a "b=AS:..." attribute at the session level in a + session description is used to set the content of a + element with the direction attribute value corresponding to the SDP + which contains the "b=" attribute. + + The numeric value in a "b=AS:..." attribute at the media level in a + media description is used to set the content of a + element child of the appropriate element, with the direction + attribute value corresponding to the SDP which contains the "b=" + attribute. + + An "a=label:..." attribute [RFC4574] is used to set the 'label' + attribute of the appropriate element. + + The mapping from a session info document to a session description + follows the same rules in the reverse direction. + + For any particular "m=" line, the codecs MUST be listed in decreasing + order of the values of the 'q' attributes of the corresponding + elements. + + + + + +Hilt, et al. Standards Track [Page 9] + +RFC 6796 Media Policy Data Set December 2012 + + +4.2. The Element + + The element describes the properties of a specific SIP + session. The element MAY contain the optional + and elements, and multiple (including zero) + , , , , + and elements, as well as elements from other namespaces. + +4.3. The Element + + The element is a container that is used to describe the + media streams used in a session. A element contains zero + or more elements. Each element describes the + properties (e.g., media type, codecs, and IP addresses and ports) of + a single media stream. + +4.3.1. The Element + + The element describes a specific media stream. It contains + the media type, codecs, and the hostname(s) or IP address(es) and + port(s) of this stream. + + The hostname(s) or IP address(es) and port number(s) of a stream + correspond to the ones listed in the session description(s). A UA + that generates a element MUST insert the hostname/port found + in the local session description for this media stream into the + local-host-port element. The UA SHOULD insert the hostname/port of + the remote session description into the element, + if the remote session description is available to the UA. If not, + the UA generates a stream element that only contains the element. + + This element MAY have the direction, label, and enabled attributes + (see Section 3.3). + + The 'label' attribute is used to identify a specific media stream. + The value of the label attribute is a token that is unique among all + elements in a session-info document and whose syntax is + defined in [RFC4566]. + + The 'enabled' attribute specifies whether or not the user agent is + allowed to establish a media stream. + + The element MUST contain one element, one or + more elements and one element. The + element MUST contain zero or one + elements. + + + + +Hilt, et al. Standards Track [Page 10] + +RFC 6796 Media Policy Data Set December 2012 + + +4.3.1.1. The Element + + The element contains the hostname or IP address and + the receiving port number of the media stream in the local session + description. The hostname or IP address is separated from the port + by a ":". An example is: "host.example.com:49562". + + The hostname or IP address of element is found in the "c=" element + for the stream in the local session description. The port number is + found in the "m=" element. + +4.3.1.2. The Element + + The element is structured exactly as the element. However, it identifies the hostname or IP + address and receiving port number of the media stream in the remote + session description. + +4.4. The Element + + The element expresses a policy for routing + media streams through media intermediaries. The purpose of the + element is to tell the UA to send media + streams through a chain of media intermediaries. The manner in which + the UA arranges for a media stream to pass through the intermediaries + depends on the type of intermediary. + + The element is a container that lists all + media intermediaries to be traversed. Media intermediaries should be + traversed in the order in which they appear in this list. The + topmost entry should be traversed first, the last entry should be + traversed last. + + Different types of intermediaries exist. These intermediaries are + not necessarily interoperable and it may not be possible to chain + them in an arbitrary order. A element SHOULD + therefore only contain intermediary elements of the same type. + + This element MAY have the 'direction' attribute (see Section 3.3). + + Multiple elements MUST NOT be present in a + container unless each applies to a different set of streams (e.g., + one element for incoming and one for outgoing + streams). The element MUST contain one or + more elements defining a specific media intermediary, such as or . + + + + + +Hilt, et al. Standards Track [Page 11] + +RFC 6796 Media Policy Data Set December 2012 + + + Note: it is not intended that the element + replace connectivity discovery mechanisms such as Interactive + Connectivity Establishment (ICE). Instead of finding media relays + that provide connectivity, this element defines a policy for media + intermediaries that should be traversed. The set of + intermediaries defined in the element and + the ones discovered through ICE may overlap but don't have to. + +4.4.1. The Element + + A fixed intermediary relies on pre-configured forwarding rules. The + user agent simply sends media to the first media intermediary listed. + It can assume that this media intermediary has been pre-configured + with a forwarding rule for the media stream and knows where to + forward the packets. The configuration of forwarding rules in the + intermediary must be done through other means. + + The contents of a element MUST be echoed to all + policy servers that provide policies for a session. That is, if + multiple policy servers provide policies for the same session, this + element needs to be forwarded to all of them, possibly in a second + round of session-specific policy subscriptions as described in + [RFC6794] in the "Contacting the Policy Server" section. + + The element MUST contain one + element and MAY contain multiple optional elements. + +4.4.1.1. The Element + + The element contains the hostname or IP address and + port number of a media intermediary. The UA uses this hostname/IP + address and port to send its media streams to the intermediary. The + hostname or IP address is separated from the port by a ":". + + If a protocol uses multiple subsequent ports (e.g., RTP), the lowest + port number SHOULD be included in the element. All + additional port numbers SHOULD be identified in + elements. + +4.4.1.2. The Element + + If a protocol uses multiple subsequent ports (e.g., RTP), the lowest + port number SHOULD be included in the element. All + additional port numbers SHOULD be identified in + elements. + + + + + + +Hilt, et al. Standards Track [Page 12] + +RFC 6796 Media Policy Data Set December 2012 + + +4.4.2. The Element + + The Traversal Using Relays around NAT (TURN) [RFC5766] protocol + provides a mechanism for inserting a relay into the media path. + Although the main purpose of TURN is NAT traversal, it is possible + for a TURN relay to perform other media intermediary functionalities. + The user agent establishes a binding on the TURN server and uses this + binding to transmit and receive media. + + The element MUST contain one + element and MAY contain multiple optional elements + and zero or one each of the , , and + elements. If no element is present, UDP is assumed. + +4.4.2.1. The Element + + The element contains the shared secret needed to + authenticate at the media intermediary. + +4.4.2.2. The Element + + The element contains the user ID needed to authenticate to the + media intermediary. + +4.4.2.3. The Element + + The element contains the name of the transport to be used + for communicating with the TURN server. This document defines the + values "tcp" and "udp" for use in the element. Other + specifications may define additional values. + +4.4.3. The Element + + The Message Session Relay Protocol (MSRP) Relay Extensions [RFC4976] + define a means for incorporating relays into the media path of an + MSRP [RFC4975] session. MSRP is explicitly designed for a variety of + purposes, including policy enforcement. + + The element MUST contain one element, + and may contain zero or one of each of the and + elements. + + + + + + + + + + +Hilt, et al. Standards Track [Page 13] + +RFC 6796 Media Policy Data Set December 2012 + + +4.4.3.1. The Element + + The element contains a URI that indicates the MSRP server + to use for an intermediary. The UA uses this URI to authenticate + with the MSRP relay, and then uses the URI it learns through that + authentication process for any MSRP media it sends or receives. The + URIs in the element MUST have a scheme of "msrps:". + +5. Session Policy Documents + + Session policy documents describe policies for SIP sessions. Session + policy documents are independent of any specific session description + and express general policies for SIP sessions. A session policy + document is used to determine if a SIP session is policy-conformant + and can be used to modify the session, if needed, to conform to the + described policies. + + Session policy documents can be used to encode session-independent + policies [RFC6794]. In this usage, a policy server creates a session + policy document and passes this document to a UA. The UA applies the + policies defined to the SIP sessions it is establishing. For + example, a session policy document can contain an element that + prohibits the use of video. To set up a session that is compliant to + this policy, a UA does not include the video media type in its SDP + offer or answer. + + Session policy documents use the root element. They + use elements described in this section and common elements described + in Section 6. + +5.1. Merging Session Policies + + A UA may receive session policy documents from multiple sources; + multiple session policy documents can be merged into a single session + policy document that expresses the logical AND of the policies. + +5.1.1. Single Value Selection + + Properties that have a single value (e.g., the maximum bandwidth + allowed) require that a common value be determined for this property + during the merging process. The merging rules for determining this + value need to be defined individually for each element in the schema + definition (e.g., select the lowest maximum bandwidth). + + + + + + + + +Hilt, et al. Standards Track [Page 14] + +RFC 6796 Media Policy Data Set December 2012 + + +5.1.2. Merging Sets + + The , , + and elements are containers that hold a set of + media-type/codec elements. The values defined in these containers + MUST be merged to determine the set of media types/codecs that are + permissible in a session. Note that for a particular codec, the + element (see Section 6.2.2) allows identifying a + particular encoding or profile of the codec. Therefore, when the + element is present, what is allowed or excluded is + the particular encoding or profile. Other encodings or profiles of + the same codec are unaffected. + + To merge the media-types-* and codecs-* containers, a UA MUST apply + all containers it has received one after the other to the set of + media types/codecs it supports. After applying media-types-*/ + codecs-* elements, the UA has the list of media types/codecs that are + allowed in a session. The containers MAY be applied in any order. + However, each time a container is applied to the set of media types/ + codecs allowed, this set MUST stay the same or be reduced. Media + types/codecs cannot be added during this process. + + The following example illustrates the merging process for two data + sets. In this example, the UA supports the following set of audio + codecs: PCMA, PCMU, and G729. After applying session policy document + 1, the UA removes PCMA as it is disallowed by this policy. The + remaining set of codecs is PCMU and G729. Session policy document 2 + disallows all codecs that are not listed. After applying this + policy, the set of codecs allowed is G729. + + Session Policy Document 1: + + audio/PCMA + + + Session Policy Document 2: + + audio/PCMA + audio/G729 + + + It is possible that two session policy documents define non- + overlapping sets of allowed media types or codecs. The resulting + merged set would be empty, which is illegal according to the schema + definition of the media-type/codec elements. This constitutes a + conflict that cannot be resolved automatically. If these properties + are enforced by both networks, the UA will not be able to set up a + session. + + + +Hilt, et al. Standards Track [Page 15] + +RFC 6796 Media Policy Data Set December 2012 + + + The combined set of media types/codecs MUST again be valid and well- + formed according to the schema definitions. A conflict occurs if the + combined property set is not a well-formed document after the merging + process is completed. + +5.1.3. Local Policy Server Selection + + Some properties require that only values from the local policy server + are used. The local policy server is the policy server that is in + the local domain of the user agent. + + If policy documents are delivered through the configuration framework + [RFC6080], the value received through a subscription using the + "local-network" profile-type SHOULD used. Values received through + other profile-type subscriptions SHOULD be discarded. + + If policy documents are delivered through the session-specific policy + mechanism [RFC6794] the value received from the policy server + identified by the Local Policy Server URI SHOULD used. Values + received from other policy servers SHOULD be discarded. + +5.2. The Element + + The element describes a policy that applies to SIP + sessions. The element MAY contain the optional + and elements and multiple (including zero) + , , , + , , , , and + elements as well as elements from other namespaces. + +5.3. The Element + + The element is a container that is used to + define the set of media types (e.g., audio, video) that are allowed + in a session. All media types that are not listed in this container + are not permitted in a session. A specific media type is allowed by + adding the corresponding element to this container. + + This element MAY have the 'direction' and 'visibility' attributes + (see Section 3.3). + + Multiple elements MUST NOT be present in a + container element unless each applies to a different set of streams + (e.g., one element for incoming and one for + outgoing streams). The element MUST contain + zero or more elements. + + + + + +Hilt, et al. Standards Track [Page 16] + +RFC 6796 Media Policy Data Set December 2012 + + + A element MUST NOT be used in a container that + contains a element. The absence of both + elements in a container indicates no restrictions regarding media + types. + + Merging of session-policy documents: containers + are merged as described in "Merging Sets" Section 5.1.2. + +5.4. The Element + + The element is a container that is used to + define the set of media types (e.g., audio, video) that are not + permitted in a session. All media types that are not listed in this + container are allowed and can be used in a session. A specific media + type is excluded from a session by adding the corresponding element to this container. + + This element MAY have the 'direction' and 'visibility' attributes + (see Section 3.3). + + Multiple elements MUST NOT be present in a + container element unless each applies to a different set of streams + (e.g., one element for incoming and one for + outgoing streams). The element MUST contain + zero or more elements. + + A element MUST NOT be used in a container that + contains a element. The absence of both + elements in a container indicates no restrictions regarding media + types. + + Merging of session-policy documents: + containers are merged as described in "Merging Sets" Section 5.1.2. + +5.5. The Element + + The element is a container that is used to define + the set of codecs that may be used in a session. All codecs not + listed in the element are disallowed and MUST NOT be + used in a session. A policy MUST allow the use of at least one codec + per media type. A specific codec is allowed by adding the + corresponding element to this container. + + The element MAY have the 'direction' and + 'visibility' attributes (see Section 3.3). + + + + + + +Hilt, et al. Standards Track [Page 17] + +RFC 6796 Media Policy Data Set December 2012 + + + Multiple elements MUST NOT be present in a container + element unless each applies to a different set of streams (e.g., one + element for incoming and one for outgoing streams). + The element MUST contain zero or more + elements. + + A element MUST NOT be used in a container that + contains a element. The absence of both elements + in a container indicates no restrictions regarding codecs. + + Merging of session-policy documents: containers are + merged as described in "Merging Sets" Section 5.1.2. + +5.6. The Element + + The element is a container that is used to define + the set of codecs that are disallowed in a session. All codecs not + listed in the element are permitted and MAY be used + in a session. A specific codec is disallowed by adding the + corresponding element to this container. + + The element MAY have the 'direction' and + 'visibility' attributes (see Section 3.3). + + Multiple elements MUST NOT be present in a + container element unless each applies to a different set of streams + (e.g., one element for incoming and one for + outgoing streams). The element MUST contain zero + or more elements. + + A element MUST NOT be used in a container that + contains a element. The absence of both elements in + a container indicates no restrictions regarding codecs. + + Merging of session-policy documents: containers are + merged as described in "Merging Sets" Section 5.1.2. + +5.7. The Element + + Domains often require that a user agent only uses ports in a certain + range for media streams. The element defines a policy + for the ports a user agent can use for media. The value of this + element consists of the decimal representation of a start port number + and an end port number, separated by a hyphen ("-"). The start/end + port numbers are the first/last port numbers that can be used, that + is, the range is inclusive. The start/end port numbers must be in + the range 1 to 65535 (inclusive). + + + + +Hilt, et al. Standards Track [Page 18] + +RFC 6796 Media Policy Data Set December 2012 + + + As with other policy elements, there are values of the + element that allow no sessions. This happens if the start port + number is greater than the end port number. + + The default value for is "1-65535". + + This element MAY have the 'visibility' attribute (see Section 3.3). + + Merging of session-policy documents: the permitted ranges specified + by the two policies are set-intersected. If the resulting set is + empty, the resulting element value MUST be any allowed + value with a start port number greater than the end port number. + +6. Common Media Policy Data Set Elements + + This section describes common XML elements that are used in session + info and session policy documents to encode the media properties of + SIP sessions. + +6.1. The Element + + The element identifies a specific media type. The value + of this element MUST be the name of a media type, as defined in + Section 8.2.1 of [RFC4566], such as audio, video, text, or + application. + + This element MAY have the 'q' attribute (see Section 3.3). + + If used in a session policy document inside a + element, the media types defined MAY be used in a session. If used + in a session policy document inside a element, + the media types defined MUST NOT be used in a session. + +6.2. The Element + + The element identifies a specific codec. The content of this + element MUST be a media type and subtype (e.g., audio/PCMA [RFC4856] + or video/H263 [RFC4629]), possibly with parameters. + + The element MAY have the 'q' attribute (see Section 3.3). + + If used in a session policy document inside a + element, the codec defined MAY be used in a session. If used in a + session policy document inside a element, the codec + defined MUST NOT be used in a session. + + The element MUST contain one element and + MAY contain multiple optional elements. + + + +Hilt, et al. Standards Track [Page 19] + +RFC 6796 Media Policy Data Set December 2012 + + +6.2.1. The Element + + The element contains a media type and subtype + that identifies a media format [RFC4566] (e.g., a codec). For audio + and video streams, the value of this element MUST be a media type and + subtype that is registered as an RTP Payload Type [RFC4855] separated + by a forward slash ("/"), e.g., audio/PCMA, audio/G726-16 [RFC4856], + or video/H263 [RFC4629]. For other media types, SDP sometimes + encodes the actual media format as part of the transport protocol + field (e.g., TCP/MSRP [RFC4975] and TCP/TLS/BFCP [RFC4583]). In + these cases, this element MUST contain the media type and the media + format part (e.g., message/msrp and application/bfcp). + +6.2.2. The Element + + The element may be needed for some codecs to + identify a particular encoding or profile. The value of this element + MUST be a name-value pair containing the name and the value of a + media type parameter for the codec [RFC4855]. The name and value are + separated by an equals sign ("="). For example, the parameter + "profile=0" can be used to specify a specific profile for the codec + video/H263-2000 [RFC4629]. + +6.3. The Element + + The element defines the overall maximum bandwidth in + kilobits per second (i.e., 1024 bits per second) an entity can/will + use for media streams at any point in time. It defines an upper + limit for the total bandwidth an entity can/will use for the + transmission of media streams. The limit corresponds to the sum of + the maximum session bandwidth of all sessions a UA may set up in + parallel. + + The bandwidth limit given in the element includes the + bandwidth needed for lower-layer transport and network protocols + (e.g., UDP and IP). + + The element MAY have the 'direction' attribute (see + Section 3.3). + + If used in a element, the element MAY also + have the 'visibility' attribute (see Section 3.3). + + If the element occurs multiple times in a container element, + each instance MUST apply to a different set of media streams (i.e., + one element for outgoing and one for incoming streams). + + + + + +Hilt, et al. Standards Track [Page 20] + +RFC 6796 Media Policy Data Set December 2012 + + + Merging of session-policy documents: the lowest value MUST + be used. + +6.4. The Element + + The element defines the maximum bandwidth in + kilobits per second (i.e., 1024 bits per second) an entity can/will + use for media streams in the described session. It defines an upper + limit for the total bandwidth of a single session. This limit + corresponds to the sum of the maximum stream bandwidth of all media + streams in a session. + + The bandwidth limit given in the element includes + the bandwidth needed for lower-layer transport and network protocols + (e.g., UDP and IP). + + The element MAY have the 'direction' attribute (see + Section 3.3). + + If used in a element, the element + MAY also have the 'visibility' attribute (see Section 3.3). + + If the element occurs multiple times in a container + element, each instance MUST apply to a different set of media streams + (i.e., one element for outgoing and one for incoming + streams). + + Merging of session-policy documents: the lowest + value MUST be used. + +6.5. The Element + + The element defines the maximum bandwidth in kilobits + per second (i.e., 1024 bits per second) an entity can/will use for + each media stream in the described session. + + The bandwidth limit given in the element includes the + bandwidth needed as encapsulated in IP (i.e., the RTP, UDP, and IP + overheads are included). + + The element MAY have the 'direction' and 'media-type' + attributes (see Section 3.3). + + If used in a element, the element + MAY also have the visibility attribute (see Section 3.3). + + If used in a element, the element MAY + also have the label attribute. + + + +Hilt, et al. Standards Track [Page 21] + +RFC 6796 Media Policy Data Set December 2012 + + + The media-type attribute is used to define that the + element only applies to streams of a certain media type (e.g., audio + streams). + + The element is used to define a bandwidth limit for a + specific media stream. The use of this attribute requires that the + element that represents the media stream to which this + bandwidth limit applies also has a 'label' attribute. A + element with a 'label' attribute applies only to the + stream element that has a 'label' attribute with the same value. If + no matching element exists, then the element + MUST be ignored. + + If the element occurs multiple times in a container + element, each instance MUST apply to a different set of media streams + (i.e., one element for outgoing and one for incoming + streams). + + Merging of session-policy documents: the lowest value + MUST be used. + +6.6. The Element + + The element contains a Differentiated Services Codepoint + (DSCP) [RFC2474] value that should be used to populate the IP DS + field of media packets. The contains a decimal integer + value that represents a 6-bit field and therefore ranges from 0 to + 63. + + This element MAY have the 'direction' and 'media-type' attributes + (see Section 3.3)). + + If used in a element, the element MAY + also have the 'visibility' attribute (see Section 3.3). + + The 'media-type' attribute is used to specify that the + element only applies to streams of a certain media type (e.g., audio + streams). + + The element is optional and MAY occur multiple times + inside a container. If the element occurs multiple times, + each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). + + + + + + + + +Hilt, et al. Standards Track [Page 22] + +RFC 6796 Media Policy Data Set December 2012 + + + Merging of session-policy documents: the local domain of the user + agent has precedence over other domains and its DSCP value MUST be + used. During the merging process, element values from + local policy server selected as described in "Local Policy Server + Selection" Section 5.1.3 are used. + +6.7. The Element + + The element provides context information about a session + policy or session information document. + + The element MAY contain multiple elements and one + element. It can also contain optional and + elements. + + If used in a element, the element MAY also + contain a element. + + Merging of session-policy documents: the resulting element + MUST be determined by local policy. + +6.7.1. The Element + + The element contains the URI (including the URI + scheme) of the policy server that has issued this policy. + +6.7.2. The Element + + The element contains a URI that is a contact address (e.g., + a SIP URI or mailto URI) by which a human representative of the + issuer of this document can be reached. + +6.7.3. The Element + + The element provides a short textual description of the policy + or session that should be intelligible to the human user. + +6.7.4. The Element + + The element contains the request-URI (including the URI + scheme) of the dialog-initiating request of the session. + + The element is only permitted inside + documents and, thus, MUST NOT be included in session policy + documents. + + + + + + +Hilt, et al. Standards Track [Page 23] + +RFC 6796 Media Policy Data Set December 2012 + + +6.7.5. The Element + + The element provides a mechanism for a policy server to + return an opaque string to a UA. Such a string is sometimes needed + to construct a Policy-ID header that ensures that all policy requests + concerning a single session are routed to the same policy server. + The use of this token is described in "A Framework for Session + Initiation Protocol (SIP) Session Policies" [RFC6794]. The syntax + for the token value is defined in Section 4.4.5.1 of RFC 6794 + [RFC6794], which builds on the syntax defined in Section 25.1 of RFC + 3261 [RFC3261]. (Note that the token value is encodable as a SIP URI + parameter value, although some characters may require escaping). + +6.8. Other Session Properties + + A number of additional elements have been proposed for a media + property language. These elements are deemed to be outside the scope + of this format. However, they may be defined in extensions of MPDF + or other profile data sets. + + o maximum number of streams + + o maximum number of sessions + + o maximum number of streams per session + + o external address and port + + o media transport protocol + + o outbound proxy + + o SIP methods + + o SIP option tags + + o SIP transport protocol + + o body disposition + + o body format + + o body encryption + + + + + + + + +Hilt, et al. Standards Track [Page 24] + +RFC 6796 Media Policy Data Set December 2012 + + +7. Examples + +7.1. Session Policy Documents + + The following example is a session policy document that allows the + use of audio and video and prohibits the use of other media types. + It allows the use of any codec except G.723 and G.729. + + + + sips:policy@biloxi.example.com + sip:policy_manager@example.com + Access network policies + + + audio + video + + + + audio/G729 + + + audio/G723 + + + + +7.2. Session Information Documents + + The following examples contain session descriptions and the session + information documents that represent these sessions. + +7.2.1. Example 1 + + In this example, a session info document is created based on one + session description. This session info document would be created, + for example, by a UA that has composed an offer and is now contacting + a policy server. + + Local session description: + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.somewhere.example + s= + c=IN IP4 host.somewhere.example + t=0 0 + m=audio 49562 RTP/AVP 0 1 3 + + + +Hilt, et al. Standards Track [Page 25] + +RFC 6796 Media Policy Data Set December 2012 + + + a=rtpmap:0 PCMU/8000 + a=rtpmap:1 1016/8000 + a=rtpmap:3 GSM/8000 + m=video 51234 RTP/AVP 31 34 + a=rtpmap:31 H261/90000 + a=rtpmap:34 H263/90000 + + MPDF document: + + + + sip:alice@somewhere.example + session information + + + + audio + + audio/PCMU + + + audio/1016 + + + audio/GSM + + host.somewhere.example:49562 + + + video + + video/H261 + + + video/H263 + + host.somewhere.example:51234 + + + + +7.2.2. Example 2 + + In this example, a session info document is created that represents + two session descriptions (i.e., an offer and answer). This session + info document would be created, for example, by a UA that has + received an answer from another UA and is now contacting a policy + server. + + + +Hilt, et al. Standards Track [Page 26] + +RFC 6796 Media Policy Data Set December 2012 + + + Local session description: + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.somewhere.example + s= + c=IN IP4 host.somewhere.example + t=0 0 + m=audio 49562 RTP/AVP 0 1 3 + a=rtpmap:0 PCMU/8000 + a=rtpmap:1 1016/8000 + a=rtpmap:3 GSM/8000 + m=video 51234 RTP/AVP 31 34 + a=rtpmap:31 H261/90000 + a=rtpmap:34 H263/90000 + + Remote session description: + + v=0 + o=bob 2890844730 2890844730 IN IP4 host.anywhere.example + s= + c=IN IP4 host.anywhere.example + t=0 0 + m=audio 52124 RTP/AVP 0 3 + a=rtpmap:0 PCMU/8000 + a=rtpmap:3 GSM/8000 + m=video 50286 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + MPDF document that represents the local and the remote session + description: + + + + sip:alice@somewhere.example + session information + + + + audio + + audio/PCMU + + + audio/GSM + + host.somewhere.example:49562 + host.anywhere.example:52124 + + + + +Hilt, et al. Standards Track [Page 27] + +RFC 6796 Media Policy Data Set December 2012 + + + + video + + video/H261 + + host.somewhere.example:51234 + host.anywhere.example:50286 + + + + + The following MPDF document is a modified version of the above + document, which can be returned by a policy server. This document + reflects a policy that defines a maximum session bandwidth of 192 + kbit and a maximum bandwidth for the H261 video stream of 128 kbit. + + + + sip:alice@somewhere.example + modified session information + + + + audio + + audio/PCMU + + + audio/GSM + + host.somewhere.example:49562 + host.anywhere.example:52124 + + + video + + video/H261 + + host.somewhere.example:51234 + host.anywhere.example:50286 + + + 128 + 192 + + + + + + + +Hilt, et al. Standards Track [Page 28] + +RFC 6796 Media Policy Data Set December 2012 + + +8. RELAX NG Definition + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 29] + +RFC 6796 Media Policy Data Set December 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 30] + +RFC 6796 Media Policy Data Set December 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 31] + +RFC 6796 Media Policy Data Set December 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 32] + +RFC 6796 Media Policy Data Set December 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 33] + +RFC 6796 Media Policy Data Set December 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 34] + +RFC 6796 Media Policy Data Set December 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + hidden + visible + + + + + + + + sendonly + recvonly + sendrecv + + + + + + + +Hilt, et al. Standards Track [Page 35] + +RFC 6796 Media Policy Data Set December 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + visibility + direction + q + media-type + label + enabled + + + + + + + + + + + context + streams + max-bw + + + +Hilt, et al. Standards Track [Page 36] + +RFC 6796 Media Policy Data Set December 2012 + + + max-session-bw + max-stream-bw + media-intermediaries + qos-dscp + local-ports + media-types-allowed + media-types-excluded + media-type + codecs-allowed + codecs-excluded + + + + + + + + + + + + + + + + + + + + + + + +9. Security Considerations + + Section 5 of [RFC6794] discusses security aspects related to the + transfer of session policy information between user agents and policy + servers, including their authentication and the use of TLS between + them. In particular, a UA needs to check the server's certificate + and only accept policies from severs from which the UA is configured + to accept policies. Section 7 of RFC 3470 [RFC3470] provides general + security considerations regarding the transport of XML documents in + network protocols. Session info and session policy information can + be sensitive information. The protocol used to distribute session + info and session policy documents SHOULD ensure authentication, + confidentiality, and message integrity. The use of [RFC6795] to + distribute session info and session policy document meets these + requirements. + + + +Hilt, et al. Standards Track [Page 37] + +RFC 6796 Media Policy Data Set December 2012 + + + An attacker could attempt to modify session policy documents that + were sent to a client so that their processing by the client would be + more costly (e.g., in terms of merging policies). The attacker could + also attempt to create its own fake policy documents and send them to + the client with the same purpose or in order to get the client to + comply with those fake policies as part of a Denial-of-Service (DoS) + attack. The protocol used to distribute session policy documents + SHOULD ensure authentication, privacy, and message integrity. The + use of [RFC6795] to distribute session policy document meets these + requirements. + + The element can contain a shared secret needed to + authenticate at a media intermediary. The privacy of documents + containing this element MUST be preserved when they are sent between + a server and a UA. When [RFC6795] is used to distribute these + documents, encryption as defined in [RFC3261] (i.e., TLS or S/MIME) + MUST be used. + +10. IANA Considerations + + This document registers a new media type (application/ + media-policy-dataset+xml), a new RELAX NG schema, and a new XML + namespace. + +10.1. Media Type Registration + + Media type name: application + + Media subtype name: media-policy-dataset+xml + + Mandatory parameters: none + + Optional parameters: Same as charset parameter of application/xml as + specified in RFC 3023 [RFC3023]. + + Encoding considerations: Same as encoding considerations of + application/xml as specified in RFC 3023 [RFC3023]. + + Security considerations: See Section 10 of RFC 3023 [RFC3023] and + Section 9 of this specification. + + Interoperability considerations: none. + + Published specification: This document. + + Applications that use this media type: This document type is used to + convey session description and media policy information between SIP + user agents and a domain. + + + +Hilt, et al. Standards Track [Page 38] + +RFC 6796 Media Policy Data Set December 2012 + + + Additional Information: + + Magic Number: None + + File Extension: .mpf or .xml + + Macintosh file type code: "TEXT" + + Personal and email address for further information: Volker Hilt + + + Intended usage: COMMON + + Author/Change controller: The IETF. + +10.2. RELAX NG Schema Registration + + This specification registers a schema. The schema can be found as + the sole content of Section 8. + + URI: urn:ietf:params:xml:schema:mediadataset + + Registrant Contact: IETF RAI area , Volker Hilt + + + RELAX NG Schema: The RELAX NG schema to be registered is contained in + Section 8. + +10.3. URN Sub-Namespace Registration + + This section registers a new XML namespace, as per the guidelines in + [RFC3688]. + + URI: The URI for this namespace is + urn:ietf:params:xml:ns:mediadataset. + + Registrant Contact: IETF RAI area , Volker Hilt + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 39] + +RFC 6796 Media Policy Data Set December 2012 + + + XML: + + BEGIN + + + + + + Media Policy Data Set Namespace + + +

Namespace for Media Policy Data Sets

+

urn:ietf:params:xml:ns:mediadataset

+

See + RFC 6796.

+ + + END + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + December 1998. + + [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media + Types", RFC 3023, January 2001. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + June 2002. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + + + +Hilt, et al. Standards Track [Page 40] + +RFC 6796 Media Policy Data Set December 2012 + + + [RFC4574] Levin, O. and G. Camarillo, "The Session Description + Protocol (SDP) Label Attribute", RFC 4574, August 2006. + + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, February 2007. + + [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message + Session Relay Protocol (MSRP)", RFC 4975, September 2007. + + [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions + for the Message Sessions Relay Protocol (MSRP)", RFC 4976, + September 2007. + + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using + Relays around NAT (TURN): Relay Extensions to Session + Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. + + [RFC6795] Hilt, V. and G. Camarillo, "A Session Initiation Protocol + (SIP) Event Package for Session-Specific Policies", + RFC 6795, December 2012. + + [W3C.REC-xml-20081126] + Sperberg-McQueen, C., Yergeau, F., Maler, E., Bray, T., + and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth + Edition)", World Wide Web Consortium Recommendation REC- + xml-20081126, November 2008, + . + + [W3C.REC-xml-names-19990114] + Hollander, D., Bray, T., and A. Layman, "Namespaces in + XML", World Wide Web Consortium First Edition REC-xml- + names-19990114, January 1999, + . + +11.2. Informative References + + [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, + August 1999. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for + the Use of Extensible Markup Language (XML) + within IETF Protocols", BCP 70, RFC 3470, January 2003. + + + + +Hilt, et al. Standards Track [Page 41] + +RFC 6796 Media Policy Data Set December 2012 + + + [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format + for Binary Floor Control Protocol (BFCP) Streams", + RFC 4583, November 2006. + + [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. + Even, "RTP Payload Format for ITU-T Rec", RFC 4629, + January 2007. + + [RFC4856] Casner, S., "Media Type Registration of Payload Formats in + the RTP Profile for Audio and Video Conferences", + RFC 4856, February 2007. + + [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session + Initiation Protocol User Agent Profile Delivery", + RFC 6080, March 2011. + + [RFC6794] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework + for Session Initiation Protocol (SIP) Session Policies", + RFC 6794, December 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hilt, et al. Standards Track [Page 42] + +RFC 6796 Media Policy Data Set December 2012 + + +Appendix A. Acknowledgements + + Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach, + and Ben Campbell for the discussions and suggestions. Many thanks to + Roni Even, Mary Barnes, Yaron Sheffer, Pete McCann, and Henry S. + Thompson for reviewing the document and to Jari Urpalainen for + helping with the RELAX NG schema. + +Authors' Addresses + + Volker Hilt + Bell Labs/Alcatel-Lucent + Lorenzstrasse 10 + 70435 Stuttgart + Germany + + EMail: volker.hilt@bell-labs.com + + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + Jonathan Rosenberg + jdrosen.net + Monmouth, NJ + USA + + EMail: jdrosen@jdrosen.net + + + Dale R. Worley + Ariadne Internet Services, Inc. + 738 Main St. + Waltham, MA 02451 + US + + EMail: worley@ariadne.com + + + + + + + + +Hilt, et al. Standards Track [Page 43] + -- cgit v1.2.3