summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6796.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6796.txt')
-rw-r--r--doc/rfc/rfc6796.txt2411
1 files changed, 2411 insertions, 0 deletions
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 <session-info> Element ................................10
+ 4.3. The <streams> Element .....................................10
+ 4.3.1. The <stream> Element ...............................10
+ 4.4. The <media-intermediaries> Element ........................11
+ 4.4.1. The <fixed-intermediary> Element ...................12
+ 4.4.2. The <turn-intermediary> Element ....................13
+ 4.4.3. The <msrp-intermediary> 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 <session-policy> Element ..............................16
+ 5.3. The <media-types-allowed> Element .........................16
+ 5.4. The <media-types-excluded> Element ........................17
+ 5.5. The <codecs-allowed> Element ..............................17
+ 5.6. The <codecs-excluded> Element .............................18
+
+
+
+Hilt, et al. Standards Track [Page 2]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ 5.7. The <local-ports> Element .................................18
+ 6. Common Media Policy Data Set Elements ..........................19
+ 6.1. The <media-type> Element ..................................19
+ 6.2. The <codec> Element .......................................19
+ 6.2.1. The <media-type-subtype> Element ...................20
+ 6.2.2. The <mime-parameter> Element .......................20
+ 6.3. The <max-bw> Element ......................................20
+ 6.4. The <max-session-bw> Element ..............................21
+ 6.5. The <max-stream-bw> Element ...............................21
+ 6.6. The <qos-dscp> Element ....................................22
+ 6.7. The <context> Element .....................................23
+ 6.7.1. The <policy-server-URI> Element ....................23
+ 6.7.2. The <contact> Element ..............................23
+ 6.7.3. The <info> Element .................................23
+ 6.7.4. The <request-URI> Element ..........................23
+ 6.7.5. The <token> 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: <session-info> is the
+ root element for session information documents and <session-policy>
+ 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 <stream> 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 <session-info> 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 <session-info> element:
+
+ <session-info></session-info>
+
+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 <stream> element for each "m=" line in a
+ session description or SDP offer/answer pair; the order of the
+ <stream> 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 <media-type> element and MUST create a <codec> 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 <codec> element for each of the codecs
+ that were agreed upon for the particular stream in the offer/answer
+ exchange. The <codec> 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 <local-host-port> 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 <remote-host-port> 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 <remote-host-port> contains information that may be considered
+ sensitive from a privacy standpoint. A UA configured not to
+ disclose that information would not include the <remote-host-port>
+ 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 <max-bw> 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 <max-session-bw>
+ 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 <max-stream-bw>
+ element child of the appropriate <stream> 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 <stream> 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
+ <codec> elements.
+
+
+
+
+
+Hilt, et al. Standards Track [Page 9]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+4.2. The <session-info> Element
+
+ The <session-info> element describes the properties of a specific SIP
+ session. The <session-info> element MAY contain the optional
+ <context> and <streams> elements, and multiple (including zero)
+ <max-bw>, <max-session-bw>, <max-stream-bw>, <media-intermediaries>,
+ and <qos-dscp> elements, as well as elements from other namespaces.
+
+4.3. The <streams> Element
+
+ The <streams> element is a container that is used to describe the
+ media streams used in a session. A <streams> element contains zero
+ or more <stream> elements. Each <stream> element describes the
+ properties (e.g., media type, codecs, and IP addresses and ports) of
+ a single media stream.
+
+4.3.1. The <stream> Element
+
+ The <stream> 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 <stream> 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 <remote-host-port> element,
+ if the remote session description is available to the UA. If not,
+ the UA generates a stream element that only contains the <local-host-
+ port> 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
+ <stream> 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 <stream> element MUST contain one <media-type> element, one or
+ more <codec> elements and one <local-host-port> element. The
+ <stream> element MUST contain zero or one <remote-host-port>
+ elements.
+
+
+
+
+Hilt, et al. Standards Track [Page 10]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+4.3.1.1. The <local-host-port> Element
+
+ The <local-host-port> 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 <remote-host-port> Element
+
+ The <remote-host-port> element is structured exactly as the <local-
+ host-port> 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 <media-intermediaries> Element
+
+ The <media-intermediaries> element expresses a policy for routing
+ media streams through media intermediaries. The purpose of the
+ <media-intermediaries> 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 <media-intermediaries> 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 <media-intermediaries> element SHOULD
+ therefore only contain intermediary elements of the same type.
+
+ This element MAY have the 'direction' attribute (see Section 3.3).
+
+ Multiple <media-intermediaries> elements MUST NOT be present in a
+ container unless each applies to a different set of streams (e.g.,
+ one <media-intermediaries> element for incoming and one for outgoing
+ streams). The <media-intermediaries> element MUST contain one or
+ more elements defining a specific media intermediary, such as <fixed-
+ intermediary> or <turn-intermediary>.
+
+
+
+
+
+Hilt, et al. Standards Track [Page 11]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ Note: it is not intended that the <media-intermediaries> 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 <media-intermediaries> element and
+ the ones discovered through ICE may overlap but don't have to.
+
+4.4.1. The <fixed-intermediary> 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 <fixed-intermediary> 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 <fixed-intermediary> element MUST contain one <int-host-port>
+ element and MAY contain multiple optional <int-addl-port> elements.
+
+4.4.1.1. The <int-host-port> Element
+
+ The <int-host-port> 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 <int-host-port> element. All
+ additional port numbers SHOULD be identified in <int-addl-port>
+ elements.
+
+4.4.1.2. The <int-addl-port> Element
+
+ If a protocol uses multiple subsequent ports (e.g., RTP), the lowest
+ port number SHOULD be included in the <int-host-port> element. All
+ additional port numbers SHOULD be identified in <int-addl-port>
+ elements.
+
+
+
+
+
+
+Hilt, et al. Standards Track [Page 12]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+4.4.2. The <turn-intermediary> 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 <turn-intermediary> element MUST contain one <int-host-port>
+ element and MAY contain multiple optional <int-addl-port> elements
+ and zero or one each of the <shared-secret>, <user>, and <transport>
+ elements. If no <transport> element is present, UDP is assumed.
+
+4.4.2.1. The <shared-secret> Element
+
+ The <shared-secret> element contains the shared secret needed to
+ authenticate at the media intermediary.
+
+4.4.2.2. The <user> Element
+
+ The <user> element contains the user ID needed to authenticate to the
+ media intermediary.
+
+4.4.2.3. The <transport> Element
+
+ The <transport> 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 <transport> element. Other
+ specifications may define additional values.
+
+4.4.3. The <msrp-intermediary> 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 <msrp-intermediary> element MUST contain one <msrp-uri> element,
+ and may contain zero or one of each of the <shared-secret> and <user>
+ elements.
+
+
+
+
+
+
+
+
+
+
+Hilt, et al. Standards Track [Page 13]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+4.4.3.1. The <msrp-uri> Element
+
+ The <msrp-uri> 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 <msrp-uri> 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 <session-policy> 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 <media-types-allowed>, <media-types-excluded>, <codecs-allowed>
+ and <codecs-excluded> 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
+ <mime-parameter> element (see Section 6.2.2) allows identifying a
+ particular encoding or profile of the codec. Therefore, when the
+ <mime-parameter> 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:
+ <codecs-excluded>
+ <codec><media-type-subtype>audio/PCMA</media-type-subtype></codec>
+ </codecs-excluded>
+
+ Session Policy Document 2:
+ <codecs-allowed>
+ <codec><media-type-subtype>audio/PCMA</media-type-subtype></codec>
+ <codec><media-type-subtype>audio/G729</media-type-subtype></codec>
+ </codecs-allowed>
+
+ 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 <session-policy> Element
+
+ The <session-policy> element describes a policy that applies to SIP
+ sessions. The <session-policy> element MAY contain the optional
+ <context> and <local-ports> elements and multiple (including zero)
+ <media-types-allowed>, <media-types-excluded>, <codecs-allowed>,
+ <codecs-excluded>, <max-bw>, <max-session-bw>, <max-stream-bw>, and
+ <qos-dscp> elements as well as elements from other namespaces.
+
+5.3. The <media-types-allowed> Element
+
+ The <media-types-allowed> 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 <media-type> element to this container.
+
+ This element MAY have the 'direction' and 'visibility' attributes
+ (see Section 3.3).
+
+ Multiple <media-types-allowed> elements MUST NOT be present in a
+ container element unless each applies to a different set of streams
+ (e.g., one <media-types-allowed> element for incoming and one for
+ outgoing streams). The <media-types-allowed> element MUST contain
+ zero or more <media-type> elements.
+
+
+
+
+
+Hilt, et al. Standards Track [Page 16]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ A <media-types-allowed> element MUST NOT be used in a container that
+ contains a <media-types-excluded> element. The absence of both
+ elements in a container indicates no restrictions regarding media
+ types.
+
+ Merging of session-policy documents: <media-types-allowed> containers
+ are merged as described in "Merging Sets" Section 5.1.2.
+
+5.4. The <media-types-excluded> Element
+
+ The <media-types-excluded> 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 <media-
+ type> element to this container.
+
+ This element MAY have the 'direction' and 'visibility' attributes
+ (see Section 3.3).
+
+ Multiple <media-types-excluded> elements MUST NOT be present in a
+ container element unless each applies to a different set of streams
+ (e.g., one <media-types-excluded> element for incoming and one for
+ outgoing streams). The <media-types-excluded> element MUST contain
+ zero or more <media-type> elements.
+
+ A <media-types-excluded> element MUST NOT be used in a container that
+ contains a <media-types-allowed> element. The absence of both
+ elements in a container indicates no restrictions regarding media
+ types.
+
+ Merging of session-policy documents: <media-types-excluded>
+ containers are merged as described in "Merging Sets" Section 5.1.2.
+
+5.5. The <codecs-allowed> Element
+
+ The <codecs-allowed> 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 <codecs-allowed> 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 <codec> element to this container.
+
+ The <codecs-allowed> 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 <codecs-allowed> elements MUST NOT be present in a container
+ element unless each applies to a different set of streams (e.g., one
+ <codecs-allowed> element for incoming and one for outgoing streams).
+ The <codecs-allowed> element MUST contain zero or more <codec>
+ elements.
+
+ A <codecs-allowed> element MUST NOT be used in a container that
+ contains a <codecs-excluded> element. The absence of both elements
+ in a container indicates no restrictions regarding codecs.
+
+ Merging of session-policy documents: <codecs-allowed> containers are
+ merged as described in "Merging Sets" Section 5.1.2.
+
+5.6. The <codecs-excluded> Element
+
+ The <codecs-excluded> 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 <codecs-excluded> element are permitted and MAY be used
+ in a session. A specific codec is disallowed by adding the
+ corresponding <codec> element to this container.
+
+ The <codecs-excluded> element MAY have the 'direction' and
+ 'visibility' attributes (see Section 3.3).
+
+ Multiple <codecs-excluded> elements MUST NOT be present in a
+ container element unless each applies to a different set of streams
+ (e.g., one <codecs-excluded> element for incoming and one for
+ outgoing streams). The <codecs-excluded> element MUST contain zero
+ or more <codec> elements.
+
+ A <codecs-excluded> element MUST NOT be used in a container that
+ contains a <codecs-allowed> element. The absence of both elements in
+ a container indicates no restrictions regarding codecs.
+
+ Merging of session-policy documents: <codecs-excluded> containers are
+ merged as described in "Merging Sets" Section 5.1.2.
+
+5.7. The <local-ports> Element
+
+ Domains often require that a user agent only uses ports in a certain
+ range for media streams. The <local-ports> 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 <local-ports>
+ element that allow no sessions. This happens if the start port
+ number is greater than the end port number.
+
+ The default value for <local-ports> 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 <local-ports> 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 <media-type> Element
+
+ The <media-type> 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 <media-types-allowed>
+ element, the media types defined MAY be used in a session. If used
+ in a session policy document inside a <media-types-excluded> element,
+ the media types defined MUST NOT be used in a session.
+
+6.2. The <codec> Element
+
+ The <codec> 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 <codec> element MAY have the 'q' attribute (see Section 3.3).
+
+ If used in a session policy document inside a <codecs-allowed>
+ element, the codec defined MAY be used in a session. If used in a
+ session policy document inside a <codecs-excluded> element, the codec
+ defined MUST NOT be used in a session.
+
+ The <codec> element MUST contain one <media-type-subtype> element and
+ MAY contain multiple optional <mime-parameter> elements.
+
+
+
+Hilt, et al. Standards Track [Page 19]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+6.2.1. The <media-type-subtype> Element
+
+ The <media-type-subtype> 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 <mime-parameter> Element
+
+ The <mime-parameter> 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 <max-bw> Element
+
+ The <max-bw> 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 <max-bw> element includes the
+ bandwidth needed for lower-layer transport and network protocols
+ (e.g., UDP and IP).
+
+ The <max-bw> element MAY have the 'direction' attribute (see
+ Section 3.3).
+
+ If used in a <session-policy> element, the <max-bw> element MAY also
+ have the 'visibility' attribute (see Section 3.3).
+
+ If the <max-bw> element occurs multiple times in a container element,
+ each instance MUST apply to a different set of media streams (i.e.,
+ one <max-bw> 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 <max-bw> value MUST
+ be used.
+
+6.4. The <max-session-bw> Element
+
+ The <max-session-bw> 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 <max-session-bw> element includes
+ the bandwidth needed for lower-layer transport and network protocols
+ (e.g., UDP and IP).
+
+ The <max-session-bw> element MAY have the 'direction' attribute (see
+ Section 3.3).
+
+ If used in a <session-policy> element, the <max-session-bw> element
+ MAY also have the 'visibility' attribute (see Section 3.3).
+
+ If the <max-session-bw> element occurs multiple times in a container
+ element, each instance MUST apply to a different set of media streams
+ (i.e., one <max-session-bw> element for outgoing and one for incoming
+ streams).
+
+ Merging of session-policy documents: the lowest <max-session-bw>
+ value MUST be used.
+
+6.5. The <max-stream-bw> Element
+
+ The <max-stream-bw> 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 <max-stream-bw> element includes the
+ bandwidth needed as encapsulated in IP (i.e., the RTP, UDP, and IP
+ overheads are included).
+
+ The <max-stream-bw> element MAY have the 'direction' and 'media-type'
+ attributes (see Section 3.3).
+
+ If used in a <session-policy> element, the <max-stream-bw> element
+ MAY also have the visibility attribute (see Section 3.3).
+
+ If used in a <session-info> element, the <max-stream-bw> 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 <max-stream-bw>
+ element only applies to streams of a certain media type (e.g., audio
+ streams).
+
+ The <max-stream-bw> element is used to define a bandwidth limit for a
+ specific media stream. The use of this attribute requires that the
+ <stream> element that represents the media stream to which this
+ bandwidth limit applies also has a 'label' attribute. A
+ <max-stream-bw> element with a 'label' attribute applies only to the
+ stream element that has a 'label' attribute with the same value. If
+ no matching <stream> element exists, then the <max-stream-bw> element
+ MUST be ignored.
+
+ If the <max-stream-bw> element occurs multiple times in a container
+ element, each instance MUST apply to a different set of media streams
+ (i.e., one <max-stream-bw> element for outgoing and one for incoming
+ streams).
+
+ Merging of session-policy documents: the lowest <max-stream-bw> value
+ MUST be used.
+
+6.6. The <qos-dscp> Element
+
+ The <qos-dscp> element contains a Differentiated Services Codepoint
+ (DSCP) [RFC2474] value that should be used to populate the IP DS
+ field of media packets. The <qos-dscp> 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 <session-policy> element, the <qos-dscp> element MAY
+ also have the 'visibility' attribute (see Section 3.3).
+
+ The 'media-type' attribute is used to specify that the <qos-dscp>
+ element only applies to streams of a certain media type (e.g., audio
+ streams).
+
+ The <qos-dscp> element is optional and MAY occur multiple times
+ inside a container. If the <qos-dscp> element occurs multiple times,
+ each instance MUST apply to a different media stream (i.e., one <qos-
+ dscp> 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, <qos-dscp> element values from
+ local policy server selected as described in "Local Policy Server
+ Selection" Section 5.1.3 are used.
+
+6.7. The <context> Element
+
+ The <context> element provides context information about a session
+ policy or session information document.
+
+ The <context> element MAY contain multiple <contact> elements and one
+ <info> element. It can also contain optional <policy-server-URI> and
+ <token> elements.
+
+ If used in a <session-info> element, the <context> element MAY also
+ contain a <request-URI> element.
+
+ Merging of session-policy documents: the resulting <context> element
+ MUST be determined by local policy.
+
+6.7.1. The <policy-server-URI> Element
+
+ The <policy-server-URI> element contains the URI (including the URI
+ scheme) of the policy server that has issued this policy.
+
+6.7.2. The <contact> Element
+
+ The <contact> 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 <info> Element
+
+ The <info> element provides a short textual description of the policy
+ or session that should be intelligible to the human user.
+
+6.7.4. The <request-URI> Element
+
+ The <request-URI> element contains the request-URI (including the URI
+ scheme) of the dialog-initiating request of the session.
+
+ The <request-URI> element is only permitted inside <session-info>
+ 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 <token> Element
+
+ The <token> 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.
+
+ <session-policy xmlns="urn:ietf:params:xml:ns:mediadataset">
+ <context>
+ <policy-server-URI>sips:policy@biloxi.example.com</policy-server-URI>
+ <contact>sip:policy_manager@example.com</contact>
+ <info>Access network policies</info>
+ </context>
+ <media-types-allowed>
+ <media-type>audio</media-type>
+ <media-type>video</media-type>
+ </media-types-allowed>
+ <codecs-excluded>
+ <codec>
+ <media-type-subtype>audio/G729</media-type-subtype>
+ </codec>
+ <codec>
+ <media-type-subtype>audio/G723</media-type-subtype>
+ </codec>
+ </codecs-excluded>
+ </session-policy>
+
+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:
+
+ <session-info xmlns="urn:ietf:params:xml:ns:mediadataset">
+ <context>
+ <contact>sip:alice@somewhere.example</contact>
+ <info>session information</info>
+ </context>
+ <streams>
+ <stream>
+ <media-type>audio</media-type>
+ <codec q="1.0">
+ <media-type-subtype>audio/PCMU</media-type-subtype>
+ </codec>
+ <codec q="0.9">
+ <media-type-subtype>audio/1016</media-type-subtype>
+ </codec>
+ <codec q="0.8">
+ <media-type-subtype>audio/GSM</media-type-subtype>
+ </codec>
+ <local-host-port>host.somewhere.example:49562</local-host-port>
+ </stream>
+ <stream>
+ <media-type>video</media-type>
+ <codec q="1.0">
+ <media-type-subtype>video/H261</media-type-subtype>
+ </codec>
+ <codec q="0.9">
+ <media-type-subtype>video/H263</media-type-subtype>
+ </codec>
+ <local-host-port>host.somewhere.example:51234</local-host-port>
+ </stream>
+ </streams>
+ </session-info>
+
+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:
+
+ <session-info xmlns="urn:ietf:params:xml:ns:mediadataset">
+ <context>
+ <contact>sip:alice@somewhere.example</contact>
+ <info>session information</info>
+ </context>
+ <streams>
+ <stream>
+ <media-type>audio</media-type>
+ <codec q="1.0">
+ <media-type-subtype>audio/PCMU</media-type-subtype>
+ </codec>
+ <codec q="0.9">
+ <media-type-subtype>audio/GSM</media-type-subtype>
+ </codec>
+ <local-host-port>host.somewhere.example:49562</local-host-port>
+ <remote-host-port>host.anywhere.example:52124</remote-host-port>
+ </stream>
+
+
+
+Hilt, et al. Standards Track [Page 27]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ <stream>
+ <media-type>video</media-type>
+ <codec q="1.0">
+ <media-type-subtype>video/H261</media-type-subtype>
+ </codec>
+ <local-host-port>host.somewhere.example:51234</local-host-port>
+ <remote-host-port>host.anywhere.example:50286</remote-host-port>
+ </stream>
+ </streams>
+ </session-info>
+
+ 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.
+
+ <session-info xmlns="urn:ietf:params:xml:ns:mediadataset">
+ <context>
+ <contact>sip:alice@somewhere.example</contact>
+ <info>modified session information</info>
+ </context>
+ <streams>
+ <stream label='1'>
+ <media-type>audio</media-type>
+ <codec q="1.0">
+ <media-type-subtype>audio/PCMU</media-type-subtype>
+ </codec>
+ <codec q="0.9">
+ <media-type-subtype>audio/GSM</media-type-subtype>
+ </codec>
+ <local-host-port>host.somewhere.example:49562</local-host-port>
+ <remote-host-port>host.anywhere.example:52124</remote-host-port>
+ </stream>
+ <stream label='2'>
+ <media-type>video</media-type>
+ <codec q="1.0">
+ <media-type-subtype>video/H261</media-type-subtype>
+ </codec>
+ <local-host-port>host.somewhere.example:51234</local-host-port>
+ <remote-host-port>host.anywhere.example:50286</remote-host-port>
+ </stream>
+ </streams>
+ <max-stream-bw label='2'>128</max-stream-bw>
+ <max-session-bw>192</max-session-bw>
+ </session-info>
+
+
+
+
+
+
+Hilt, et al. Standards Track [Page 28]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+8. RELAX NG Definition
+
+ <?xml version="1.0"?>
+ <grammar xmlns="http://relaxng.org/ns/structure/1.0"
+ ns="urn:ietf:params:xml:ns:mediadataset"
+ datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
+
+ <start>
+ <choice>
+ <element name="session-info">
+ <interleave>
+ <optional>
+ <ref name="ElementStreams"/>
+ </optional>
+ <zeroOrMore>
+ <ref name="ElementMaxBandwidth"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementMaxSessionBandwidth"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementMaxStreamBandwidth"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementMediaIntermediaries"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementQoSDSCP"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementAny"/>
+ </zeroOrMore>
+ </interleave>
+ </element>
+
+ <element name="session-policy">
+ <interleave>
+ <optional>
+ <ref name="ElementContext"/>
+ </optional>
+ <optional>
+ <ref name="ElementLocalPorts"/>
+ </optional>
+ <zeroOrMore>
+ <ref name="ElementMediaTypesAllowed"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementMediaTypesExcluded"/>
+
+
+
+Hilt, et al. Standards Track [Page 29]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementCodecsAllowed"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementCodecsExcluded"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementMaxBandwidth"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementMaxSessionBandwidth"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementMaxStreamBandwidth"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementQoSDSCP"/>
+ </zeroOrMore>
+ <zeroOrMore>
+ <ref name="ElementAny"/>
+ </zeroOrMore>
+ </interleave>
+ </element>
+ </choice>
+ </start>
+
+ <define name="ElementMediaTypesAllowed">
+ <element name="media-types-allowed">
+ <ref name="PolicyGeneralAttributes"/>
+ <zeroOrMore>
+ <ref name="ElementMediaType"/>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="ElementMediaTypesExcluded">
+ <element name="media-types-excluded">
+ <ref name="PolicyGeneralAttributes"/>
+ <zeroOrMore>
+ <ref name="ElementMediaType"/>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="ElementMediaType">
+ <element name="media-type">
+ <data type="string" />
+
+
+
+Hilt, et al. Standards Track [Page 30]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ <optional>
+ <ref name="AttributeQ"/>
+ </optional>
+ <optional>
+ <ref name="AttributeGeneric"/>
+ </optional>
+ </element>
+ </define>
+
+ <define name="ElementCodecsAllowed">
+ <element name="codecs-allowed">
+ <ref name="PolicyGeneralAttributes"/>
+ <zeroOrMore>
+ <ref name="ElementCodec"/>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="ElementCodecsExcluded">
+ <element name="codecs-excluded">
+ <ref name="PolicyGeneralAttributes"/>
+ <zeroOrMore>
+ <ref name="ElementCodec"/>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="ElementCodec">
+ <element name="codec">
+ <optional>
+ <ref name="AttributeQ"/>
+ </optional>
+ <optional>
+ <ref name="AttributeGeneric"/>
+ </optional>
+ <element name="media-type-subtype">
+ <data type="string" />
+ </element>
+ <zeroOrMore>
+ <element name="mime-parameter">
+ <data type="string" />
+ </element>
+ </zeroOrMore>
+ </element>
+ </define>
+
+
+
+
+
+
+Hilt, et al. Standards Track [Page 31]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ <define name="ElementStreams">
+ <element name="streams">
+ <optional>
+ <ref name="AttributeGeneric"/>
+ </optional>
+ <zeroOrMore>
+ <ref name="ElementStream"/>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="ElementStream">
+ <element name="stream">
+ <optional>
+ <ref name="AttributeDirection"/>
+ </optional>
+ <optional>
+ <ref name="AttributeLabel"/>
+ </optional>
+ <optional>
+ <ref name="AttributeEnabled"/>
+ </optional>
+ <optional>
+ <ref name="AttributeGeneric"/>
+ </optional>
+ <ref name="ElementMediaType"/>
+ <oneOrMore>
+ <ref name="ElementCodec"/>
+ </oneOrMore>
+ <element name="local-host-port">
+ <data type="string" />
+ </element>
+ <optional>
+ <element name="remote-host-port">
+ <data type="string" />
+ </element>
+ </optional>
+ </element>
+ </define>
+
+ <define name="ElementMaxBandwidth">
+ <element name="max-bw">
+ <data type="integer" />
+ <ref name="PolicyGeneralAttributes"/>
+ </element>
+ </define>
+
+
+
+
+
+Hilt, et al. Standards Track [Page 32]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ <define name="ElementMaxSessionBandwidth">
+ <element name="max-session-bw">
+ <data type="integer" />
+ <ref name="PolicyGeneralAttributes"/>
+ </element>
+ </define>
+
+ <define name="ElementMaxStreamBandwidth">
+ <element name="max-stream-bw">
+ <data type="integer" />
+ <ref name="PolicyGeneralAttributes"/>
+ <optional>
+ <ref name="AttributeMediaType"/>
+ </optional>
+ <optional>
+ <ref name="AttributeLabel"/>
+ </optional>
+ </element>
+ </define>
+
+ <define name="ElementMediaIntermediaries">
+ <element name="media-intermediaries">
+ <ref name="PolicyGeneralAttributes"/>
+ <oneOrMore>
+ <choice>
+ <element name="fixed-intermediary">
+ <element name="int-host-port">
+ <data type="string" />
+ </element>
+ <zeroOrMore>
+ <element name="int-addl-port">
+ <data type="integer" />
+ </element>
+ </zeroOrMore>
+ </element>
+
+ <element name="turn-intermediary">
+ <element name="int-host-port">
+ <data type="string" />
+ </element>
+ <zeroOrMore>
+ <element name="int-addl-port">
+ <data type="integer" />
+ </element>
+ </zeroOrMore>
+ <zeroOrMore>
+ <element name="shared-secret">
+ <data type="string" />
+
+
+
+Hilt, et al. Standards Track [Page 33]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ </element>
+ </zeroOrMore>
+ </element>
+ </choice>
+ </oneOrMore>
+ </element>
+ </define>
+
+ <define name="ElementQoSDSCP">
+ <element name="qos-dscp">
+ <data type="integer" />
+ <ref name="PolicyGeneralAttributes"/>
+ <optional>
+ <ref name="AttributeMediaType"/>
+ </optional>
+ </element>
+ </define>
+
+ <define name="ElementLocalPorts">
+ <element name="local-ports">
+ <data type="string" />
+ <interleave>
+ <optional>
+ <ref name="AttributeVisibility"/>
+ </optional>
+ <optional>
+ <ref name="AttributeGeneric"/>
+ </optional>
+ </interleave>
+ </element>
+ </define>
+
+ <define name="ElementContext">
+ <element name="context">
+ <interleave>
+ <optional>
+ <element name="info">
+ <data type="string" />
+ </element>
+ </optional>
+ <optional>
+ <element name="policy-server-URI">
+ <data type="string" />
+ </element>
+ </optional>
+ <optional>
+ <element name="token">
+ <data type="token" />
+
+
+
+Hilt, et al. Standards Track [Page 34]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ </element>
+ </optional>
+ <optional>
+ <element name="request-URI">
+ <data type="string" />
+ </element>
+ </optional>
+ <zeroOrMore>
+ <element name="contact">
+ <data type="string" />
+ </element>
+ </zeroOrMore>
+ </interleave>
+ </element>
+ </define>
+
+ <define name="PolicyGeneralAttributes">
+ <optional>
+ <ref name="AttributeVisibility"/>
+ </optional>
+ <optional>
+ <ref name="AttributeDirection"/>
+ </optional>
+ <optional>
+ <ref name="AttributeGeneric"/>
+ </optional>
+ </define>
+
+
+ <define name="AttributeVisibility">
+ <attribute name="visibility">
+ <choice>
+ <value>hidden</value>
+ <value>visible</value>
+ </choice>
+ </attribute>
+ </define>
+
+ <define name="AttributeDirection">
+ <attribute name="direction">
+ <choice>
+ <value>sendonly</value>
+ <value>recvonly</value>
+ <value>sendrecv</value>
+ </choice>
+ </attribute>
+ </define>
+
+
+
+
+Hilt, et al. Standards Track [Page 35]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ <define name="AttributeQ">
+ <attribute name="q">
+ <data type="decimal" />
+ </attribute>
+ </define>
+
+ <define name="AttributeMediaType">
+ <attribute name="media-type">
+ <data type="string" />
+ </attribute>
+ </define>
+
+ <define name="AttributeLabel">
+ <attribute name="label">
+ <data type="string" />
+ </attribute>
+ </define>
+
+ <define name="AttributeEnabled">
+ <attribute name="enabled">
+ <data type="boolean" />
+ </attribute>
+ </define>
+
+ <define name="AttributeGeneric">
+ <zeroOrMore>
+ <attribute>
+ <anyName>
+ <except>
+ <name ns="">visibility</name>
+ <name ns="">direction</name>
+ <name ns="">q</name>
+ <name ns="">media-type</name>
+ <name ns="">label</name>
+ <name ns="">enabled</name>
+ </except>
+ </anyName>
+ </attribute>
+ </zeroOrMore>
+ </define>
+
+ <define name="ElementAny">
+ <element>
+ <anyName>
+ <except>
+ <name>context</name>
+ <name>streams</name>
+ <name>max-bw</name>
+
+
+
+Hilt, et al. Standards Track [Page 36]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ <name>max-session-bw</name>
+ <name>max-stream-bw</name>
+ <name>media-intermediaries</name>
+ <name>qos-dscp</name>
+ <name>local-ports</name>
+ <name>media-types-allowed</name>
+ <name>media-types-excluded</name>
+ <name>media-type</name>
+ <name>codecs-allowed</name>
+ <name>codecs-excluded</name>
+ </except>
+ </anyName>
+ <ref name="anyExtension"/>
+ </element>
+ </define>
+
+ <define name="anyExtension">
+ <zeroOrMore>
+ <choice>
+ <element>
+ <anyName/>
+ <ref name="anyExtension"/>
+ </element>
+ <attribute>
+ <anyName/>
+ </attribute>
+ <text/>
+ </choice>
+ </zeroOrMore>
+ </define>
+
+ </grammar>
+
+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 <shared-secret> 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
+ <volker.hilt@bell-labs.com>
+
+ 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 <rai@ietf.org>, Volker Hilt
+ <volker.hilt@bell-labs.com>
+
+ 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 <rai@ietf.org>, Volker Hilt
+ <volker.hilt@bell-labs.com>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hilt, et al. Standards Track [Page 39]
+
+RFC 6796 Media Policy Data Set December 2012
+
+
+ XML:
+
+ BEGIN
+ <?xml version="1.0"?>
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
+ "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="content-type"
+ content="text/html;charset=iso-8859-1"/>
+ <title>Media Policy Data Set Namespace</title>
+ </head>
+ <body>
+ <h1>Namespace for Media Policy Data Sets</h1>
+ <h2>urn:ietf:params:xml:ns:mediadataset</h2>
+ <p>See <a href="http://www.rfc-editor.org/rfc/rfc6796.txt">
+ RFC 6796</a>.</p>
+ </body>
+ </html>
+ 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,
+ <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+ [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,
+ <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
+
+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]
+