RFC 6796
A User Agent Profile Data Set for Media Policy
RFC 6796: A User Agent Profile Data Set for Media Policy 🎀
Okay bestie, let's get the basics! 💖 This one is by V. Hilt (Bell Labs/Alcatel-Lucent), G. Camarillo (Ericsson), J. Rosenberg (jdrosen.net), and D. Worley (Ariadne). It's a Standards Track doc published in December 2012, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates. 🦋
Abstract
okay so this spec defines an XML document format that describes the media properties of Session Initiation Protocol (SIP) sessions 📞 Things like the codecs or media types used in the session are the kinds of properties we mean. It also defines a second XML document format for policies that limit those media properties. 🔥
Status of This Memo
This is an Internet Standards Track document. ✨
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741. 🌸
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6796. 💅
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) as in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for 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 they come 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
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 ......................................421. Introduction ✨
okay so the Session Initiation Protocol (SIP) [RFC3261] is the base here 📞. Then "A Framework for Session Initiation Protocol (SIP) User Agent Profile Delivery" [RFC6080] and "A Framework for SIP Session Policies" [RFC6794] define the mechanisms for sending session policies and config info from a network server to a user agent. 🧚 A big chunk of that info is about the media properties of the SIP sessions the user agent sets up. Examples are the codecs and media types used, the media-intermediaries to go through, or the max bandwidth available for media streams. It's giving organized! 💅
This spec defines a document format for those media properties of SIP sessions, called the Media Policy Data Set Format (MPDF) 🎀. It can be used in two ways. First, it can describe the properties of one specific SIP session, like the media types and codecs used. These MPDF documents are called session info documents, and they're usually made from the session description of a session. Second, MPDF can define policies for SIP sessions in a session policy document. A session policy document sets properties for a session (like which media types are allowed) without being tied to any one session description. 🌈
If you use it with "A Framework for SIP Session Policies" [RFC6794], session info documents work together with session-specific policies. A user agent (UA) makes a session info document from the current session description and submits it to the policy server 🖥️. The policy server checks it, changes it if needed (for example, removing video streams if video isn't permitted), and sends the possibly changed document back to the UA. Session policy documents are different: they describe session-independent policies that can be sent to the UA whether or not there's a specific session. 💖
The two types of MPDF documents, session information and session policy, share the same set of XML elements for describing session properties. Those elements get used in different contexts, so there are two root elements: <session-info> is the root for session information documents, and <session-policy> is the root for session policy documents. 🦋
A user agent can get multiple session policy documents from different sources. That can mean the UA has to apply several session policy documents to the same session 😭. This standard specifies merging rules for the XML elements that can show up in session policy documents. It should 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. So it's 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 aren't needed for elements of session information documents, since one source creates them and they describe one 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 covers the fundamental properties of the Media Policy Data Set Format (MPDF). 💜
3.1. Namespace and Media Type 🎀
MPDF is based on XML [W3C.REC-xml-20081126]. An MPDF document MUST be well-formed, and it MUST be valid according to schemas (including extension schemas) that are available to the validator and apply to the XML document. MPDF documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. 🫶
MPDF uses XML namespaces [W3C.REC-xml-names-19990114]. The namespace URIs for elements defined in this spec 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:mediadatasetAnd the media type for the Media Policy Data Set Format is:
application/media-policy-dataset+xml3.2. Extensibility 🧚
MPDF can be extended with XML extension mechanisms if more media properties are needed. In particular, elements from different XML namespaces MAY be present within an MPDF document for extensibility purposes. Elements or attributes from unknown namespaces MUST be ignored. 🌈
💖 That's part 1 of 8, bestie! More parts are coming, so stay tuned. 🦋
3.3. Attributes
okay so attributes are the little extra details you can slap onto MPDF elements 💅 each MPDF element's spec tells you which attributes it's allowed to use 🎀 and if an element has an attribute it isn't supposed to have, the user agent MUST ignore that attribute 🙈 no drama, just skip it
3.3.1. The 'visibility' Attribute
the visibility attribute is about whether the user agent is advised to show the property value to the user 👀 it's basically there so admins can hide settings they don't want the user to see or know about 🔒 it has two possible values:
visible: showing the property value isn't restricted ✨ this is the default if the attribute isn't specifiedhidden: the user agent is advised not to display the property value 🙈 admins might still be able to show it through special administrative interfaces, but it's not really meant for the ordinary user
3.3.2. The 'direction' Attributes
some properties only make sense in one direction 🦋 like a media stream property that should only apply to outgoing streams. you can express that by adding a direction attribute to the element ✨
the direction attribute can have these values:
recvonly: the property only applies to incoming streamssendonly: the property only applies to outgoing streamssendrecv: the property applies to streams in both directions 💖 this is the default ifdirectionis left out
3.3.3. The 'q' Attribute
sometimes you want to say "I like this one more" 💅 like when a set of values is allowed but you have a favourite. for example, you can say the codecs G.711 and G.729 are both allowed, but G.711 is preferred 🎧 you do that by adding a q attribute to a property element. the q attribute is only allowed on elements that specify allowed values (not the ones that specify forbidden values) 🚫
the value of q is a decimal number from 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 says an element only applies to streams of a certain media type, as defined in Section 8.2.1 of [RFC4566] 🎶 so it could, for example, 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 🏷️ its value is a token, and the syntax for that token is defined in [RFC4574]. you can pick the token freely, but it MUST be unique among all <stream> elements in a session-info document 🫶
3.3.6. The 'enabled' Attribute
the enabled attribute says whether or not the user agent is allowed to establish a media stream 🚦 it's a boolean, so there are two values:
yes: the media stream can be established 💚 this is the default if the attribute isn't specifiedno: the user agent MUST NOT establish the media stream 🛑
4. Session Info Documents
session info documents describe key properties of a SIP session, like the media streams used in it 🎬 they're typically created from a session description written in Session Description Protocol (SDP) [RFC4566], or from an SDP offer/answer pair [RFC3264] 📝
they can also be used for session-specific policies [RFC6794] 🔐 here's the vibe: a UA builds a session info document from its session description(s) and sends it to the policy server 📮 the policy server tweaks it to match the policies for that session and sends back a compliant version 💅 for example, if video streams aren't permitted under current policies and the UA sends a document with a video stream, the policy server disables it (i.e., enabled="no") in the copy it returns to the UA 🎥🚫
session info documents use the <session-info> root element 🌸 they use the elements described in this section, plus the common elements described in Section 6 🧩
elements that only show up in session info documents don't need merging rules 🧠 and if they're used for session-specific policies, session info documents go to one policy server at a time, so a UA doesn't need to merge several into one 🙌 a policy server needs to modify a session info document it received according to its policies. how it does that is decided by the server's local policies, so it's outside the scope of this standard 🤷♀️
a policy server can completely reject a session by sending back 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 explains how to map information from a session description or an SDP offer/answer pair [RFC3264] into session info documents, and how to map a session info document back into a session description 🗺️ heads up: these mapping rules don't cover every element that has to be in a session info document or a session description 🙈 some of those elements get generated following their own general rules (like the general rules for making SDP "v=" and "t=" lines).
a UA with a session description that needs a session info document uses the data in that session description and maps it following the rules below 📋 a UA with an SDP offer/answer pair that needs a session info document uses the data that was 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 matches 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 pair, the UA MUST insert a <codec> element for each of the codecs that were agreed upon for that particular stream in the offer/answer exchange. the <codec> elements MUST have 'q' attributes with values that decrease in the order the codecs are given in the "m=" line 📉 (other than that ordering restriction, the particular values used aren't 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 in the remote session description, if that remote session description is available 📡 (the local SDP is the one the UA sent, and the remote SDP is the one it received from the remote UA.)
⚠️ the<remote-host-port>contains info 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 sets the content of a <max-bw> element, with the direction attribute value matching whichever SDP contains the "b=" attribute 💪
the numeric value in a "b=AS:..." attribute at the session level of a session description sets the content of a <max-session-bw> element, with the direction attribute value matching the SDP that contains the "b=" attribute 📊 the numeric value in a "b=AS:..." attribute at the media level of a media description sets the content of a <max-stream-bw> element, which is a child of the appropriate <stream> element, with the direction attribute value matching the SDP that contains the "b=" attribute ✨
an "a=label:..." attribute [RFC4574] sets the label attribute of the appropriate <stream> element 🏷️
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 🎶
4.2. The <session-info> Element
the <session-info> element describes the properties of a specific SIP session 💜 it 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's 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 it isn't, 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 🏷️ its value is a token that's 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. 💅
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 the 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 💌
okay so <remote-host-port> is basically the twin of <local-host-port> 👯♀️ same exact structure, no cap! The only difference is that it tells you 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 is all about policy 💅 it says how media streams get routed through media intermediaries. Its whole purpose is to tell the UA to send media streams through a chain of media intermediaries. How the UA actually sets that up depends on what kind of intermediary it's dealing with 🧚
this element is a container that lists every media intermediary that needs to be traversed. Media intermediaries should be traversed in the order they show up in this list. The topmost entry should be traversed first, and the last entry should be traversed last 🫶
different types of intermediaries exist 👀 they aren't 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 one applies to a different set of streams (e.g., one <media-intermediaries> element for incoming streams 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>.
🚨 psst, important: the<media-intermediaries>element is not meant to replace connectivity discovery mechanisms like Interactive Connectivity Establishment (ICE). Instead of hunting down media relays that provide connectivity, this element defines a policy for which media intermediaries should be traversed. The intermediaries defined in the<media-intermediaries>element and the ones discovered through ICE may overlap, but they don't have to.
4.4.1. The <fixed-intermediary> Element 🍓
a fixed intermediary relies on pre-configured forwarding rules. The user agent just sends media to the first media intermediary listed. It can assume that this intermediary has been pre-configured with a forwarding rule for the media stream and knows where to forward the packets. Configuring those 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 means 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 holds 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 🦄
same vibe as above, bestie 🫶 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.2. The <turn-intermediary> Element 🎀
the Traversal Using Relays around NAT (TURN) [RFC5766] protocol gives you a way to insert a relay into the media path. Its main purpose is NAT traversal, but a TURN relay can also perform other media intermediary functionalities. The user agent establishes a binding on the TURN server and uses that 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, plus 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 working relays into the media path of an MSRP [RFC4975] session. MSRP is explicitly designed for a variety of purposes, including policy enforcement, which is very on-brand for it 💅
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.
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. They're independent of any specific session description and express general policies for SIP sessions. A session policy document is used to figure out whether a SIP session is policy-conformant, and it can be used to modify the session, if needed, so it follows the described policies ✨
session policy documents can encode session-independent policies [RFC6794]. In this usage, a policy server creates a session policy document and passes it to a UA. The UA applies the policies defined to the SIP sessions it's establishing. For example, a session policy document can contain an element that prohibits the use of video. To set up a session that's compliant with 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 the elements described in this section, plus the 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 that 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).
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) lets you identify a particular encoding or profile of the codec. So when the <mime-parameter> element is present, what's allowed or excluded is that 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 because this policy disallows it. 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's 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 is a conflict that can't be resolved automatically. If these properties are enforced by both networks, the UA won't be able to set up a session 😭
🚨 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
Okay bestie, this one is the guest list for media types 🎀 <media-types-allowed> is a container that defines which media types (think audio, video) are allowed in a session. Anything NOT on the list is a no-go in the session 🚫 A specific media type gets in by adding its <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 one applies to a different set of streams. For example, you could have one for incoming streams and one for outgoing streams 📥📤 The <media-types-allowed> element MUST contain zero or more <media-type> elements 💜
A <media-types-allowed> element MUST NOT be used in a container that also contains a <media-types-excluded> element. Like, you can't have a guest list AND a block list in the same container 🙅♀️ If a container has neither element, there are no restrictions on media types at all ✨
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
This is the opposite vibe 💅 <media-types-excluded> is a container that defines the media types that are NOT permitted in a session. Anything not listed in here is allowed and can be used in the session 🌸 A specific media type gets blocked by adding its <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 one applies to a different set of streams (e.g., one for incoming streams 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. Same energy as before: pick a guest list or a block list, not both 🙈 If a container has neither, there are 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
Now we're getting into codecs 🧚 <codecs-allowed> is a container that defines the set of codecs that may be used in a session. Any codec NOT listed here is disallowed and MUST NOT be used in a session 🚫 Also, a policy MUST allow at least one codec per media type, so nobody gets left with zero options 🫶 A specific codec is allowed by adding its <codec> element to this container.
The <codecs-allowed> element MAY have the direction and visibility attributes (see Section 3.3) 💜
Multiple <codecs-allowed> elements MUST NOT be present in a container element unless each one applies to a different set of streams (e.g., one for incoming streams 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. If a container has neither element, there are 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
Mirror image time 🪞 <codecs-excluded> is a container that defines the codecs that are disallowed in a session. Any codec NOT listed here is permitted and MAY be used in a session 🌸 A specific codec gets disallowed by adding its <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 one applies to a different set of streams (e.g., one for incoming streams 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. If a container has neither element, there are 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
Okay, real talk: domains often insist that a user agent only uses ports in a certain range for media streams 🔒 That's what <local-ports> is for. It defines the policy for which ports a user agent can use for media 🎯 The value is the decimal form of a start port number and an end port number, separated by a hyphen (-). Both numbers are inclusive, so they're the first and last ports you can actually use 💖 The start and end port numbers must be in the range 1 to 65535 (inclusive) 🔢
Like other policy elements, some values of <local-ports> allow no sessions at all. That happens when 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 is all about the common XML elements used in session info and session policy documents to describe the media properties of SIP sessions 🧚 Think of it as the shared vocabulary everybody needs to speak 💜
6.1. The <media-type> Element
<media-type> identifies a specific media type 🎀 Its value 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 it's used in a session policy document inside a <media-types-allowed> element, the media types defined MAY be used in a session ✨ If it's used inside a <media-types-excluded> element, the media types defined MUST NOT be used in a session 🚫
6.2. The <codec> Element
<codec> identifies a specific codec 🍓 Its content MUST be a media type and subtype (e.g., audio/PCMA [RFC4856] or video/H263 [RFC4629]), possibly with parameters 💖
This element MAY have the q attribute (see Section 3.3) 🦋
If it's used in a session policy document inside a <codecs-allowed> element, the codec defined MAY be used in a session. If it's used 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 🌸
6.2.1. The <media-type-subtype> Element
<media-type-subtype> contains a media type and subtype that identifies a media format [RFC4566] (e.g., a codec) 🎶 For audio and video streams, its value MUST be a media type and subtype that is registered as an RTP Payload Type [RFC4855], separated by a forward slash (/). For example: 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 🧁 Its value 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
<max-bw> defines the overall maximum bandwidth, in kilobits per second (i.e., 1024 bits per second), that an entity can/will use for media streams at any point in time 📶 It's an upper limit for the total bandwidth an entity can/will use for transmitting 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 in <max-bw> 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 it's 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 streams and one for incoming streams) 📥📤
Merging of session-policy documents: the lowest <max-bw> value MUST be used 🏆
6.4. The <max-session-bw> Element
<max-session-bw> defines the maximum bandwidth, in kilobits per second (i.e., 1024 bits per second), that an entity can/will use for media streams in the described session 🎬 It's 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 in <max-session-bw> 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 it's 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 streams 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 🎀
okay so <max-stream-bw> is the bandwidth cap for each media stream in the session 🦋 It's measured in kilobits per second, and a kilobit here means 1024 bits per second. The limit includes everything the stream needs once it's encapsulated in IP, so the RTP, UDP, and IP overheads all count toward it 🧚
This element MAY have the direction and media-type attributes (see Section 3.3). If it's used in a <session-policy> element, it MAY also have the visibility attribute (see Section 3.3) 👀 If it's used in a <session-info> element, it MAY also have the label attribute 🏷️
The media-type attribute lets you say the cap only applies to streams of a certain type, like audio streams 🎵
Now the label thing, which is kind of the whole point 💅 To target one specific stream, the <stream> element it refers to has to have a label attribute too. A <max-stream-bw> with a label only applies to the stream whose label has the same value. If there's no matching <stream> element, the <max-stream-bw> MUST be ignored 🙈
If <max-stream-bw> shows up more than once in the same container, each instance MUST apply to a different set of media streams. Think one for outgoing streams and one for incoming streams 🌸
When session-policy documents get merged, the lowest <max-stream-bw> value MUST be used 📉 Lowest wins, no debate 👑
6.6. The <qos-dscp> Element ✨
<qos-dscp> holds a Differentiated Services Codepoint (DSCP) [RFC2474] value that should be used to fill in the IP DS field of media packets 🧚 It's a decimal integer representing a 6-bit field, so it runs from 0 to 63 🔢
This element MAY have the direction and media-type attributes (see Section 3.3)). If it's used in a <session-policy> element, it MAY also have the visibility attribute (see Section 3.3) 💜
The media-type attribute narrows it down to streams of a certain type, like audio streams 🎧
<qos-dscp> is optional, and it MAY occur multiple times inside a container. If it does, each instance MUST apply to a different media stream. For example, one for audio and one for video 🎬
Merging of session-policy documents goes like this: the local domain of the user agent wins over other domains, and its DSCP value MUST be used 🏠 During merging, the <qos-dscp> values come from the local policy server chosen as described in "Local Policy Server Selection" Section 5.1.3 🫶
6.7. The <context> Element 🌈
<context> gives you context info about a session policy or session information document 📝
It MAY contain multiple <contact> elements and one <info> element. It can also hold optional <policy-server-URI> and <token> elements 💅
If it's used in a <session-info> element, <context> MAY also contain a <request-URI> element 🎯
When session-policy documents get merged, the resulting <context> element MUST be determined by local policy 🔒
6.7.1. The <policy-server-URI> Element
This element holds the URI (including the URI scheme) of the policy server that issued this policy 🖥️
6.7.2. The <contact> Element
This one holds a URI that's a contact address, like a SIP URI or a mailto URI, so a human rep from the issuer of the document can be reached 📬
6.7.3. The <info> Element
<info> is a short text description of the policy or session. It should be readable by the human user 🥰
6.7.4. The <request-URI> Element
<request-URI> holds the request-URI (including the URI scheme) of the dialog-initiating request of the session 📞
It's only allowed inside <session-info> documents, so it MUST NOT be included in session policy documents 🚫
6.7.5. The <token> Element
<token> is how a policy server hands an opaque string back to a UA 🔑 Sometimes that string is needed to build a Policy-ID header, which makes sure every policy request for a single session goes to the same policy server 🧩 The whole token thing 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 can be encoded as a SIP URI parameter value, though some characters may need escaping 🫧)
6.8. Other Session Properties 🦄
Lots of extra elements have been floated for a media property language. They're outside the scope of this format, but they may be defined in extensions of MPDF or other profile data sets 🔮 Here's the list of ideas that didn't make the cut:
- maximum number of streams
- maximum number of sessions
- maximum number of streams per session
- external address and port
- media transport protocol
- outbound proxy
- SIP methods
- SIP option tags
- SIP transport protocol
- body disposition
- body format
- body encryption
7. Examples 🍓
7.1. Session Policy Documents 💖
This example is a session policy document that allows audio and video and prohibits other media types 🎶 It allows 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 🌷
These examples have session descriptions and the session information documents that represent them 🫶
7.2.1. Example 1 ⭐
In this one, a session info document gets created from one session description. A UA would make this document after composing an offer and then 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
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/90000MPDF 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 one, a session info document represents two session descriptions, an offer and an answer. A UA would make this after getting an answer from another UA and then 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
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/90000Remote 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/90000MPDF document that represents the local and remote session descriptions:
<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>
<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 MPDF document below is a modified version of the one above, and a policy server can return it 🪄 It reflects a policy with 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>8. RELAX NG Definition 🧚♀️
Okay bestie, this part is all RELAX NG 💅 The schema is basically a bouncer with a clipboard: it checks every element and attribute before letting it into the session info or policy docs 🎀
<?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"/>
</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" />
<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>
<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>
<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" />
</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" />
</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>
<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>
<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 🔐
Okay, bestie, security is where things get serious 😭 Read this part carefully! 💅
Section 5 of [RFC6794] digs into security for moving session policy information between user agents and policy servers, including how they authenticate each other and how TLS gets used between them. The big deal here is that a UA needs to check the server's certificate and only accept policies from servers it's been configured to trust 🫶 Section 7 of RFC 3470 [RFC3470] has the general security stuff for carrying XML documents over network protocols. Session info and session policy information can be sensitive, so this matters a LOT 💀 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 documents meets these requirements ✨
An attacker could try to tamper with session policy documents sent to a client so that the client has to do more expensive processing with them, like merging policies. The attacker could also try to make up its own fake policy documents and send them to the client, either for the same goal or to trick the client into following 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 documents meets these requirements, periodt 💜
The <shared-secret> element can hold a shared secret that's needed to authenticate at a media intermediary. Documents containing this element MUST have their privacy preserved whenever they're sent between a server and a UA 🔥 When [RFC6795] is used to distribute these documents, encryption as defined in [RFC3261] (that is, TLS or S/MIME) MUST be used. No skipping this one, bestie 🫶
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. Three registrations in one go, we're so productive 💅
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.
- 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. You can find the schema as the sole content of Section 8, so go check it out 👑
- 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, following the guidelines in [RFC3688]. Slay the paperwork ✨
- 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>
- 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>
END11. 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.
- [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.
- [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.
Appendix A. Acknowledgements 🫶
Huge thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach, and Ben Campbell for the discussions and suggestions 💜 Also a big shoutout 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. The real MVPs 👑✨
Authors' Addresses ✨
okay bestie, the brains behind this one 🫶 here's where you can find each of them 💖
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.comand that's the whole RFC, periodt 💅🦋
📦 where this page comes from
- ietf: rfc6796 2012-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms