One document matched: draft-ietf-sipping-media-policy-dataset-11.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2141 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml'>
<!ENTITY rfc2648 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2648.xml'>
<!ENTITY rfc2474 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml'>
<!ENTITY rfc3023 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3023.xml'>
<!ENTITY rfc3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
<!ENTITY rfc4855 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml'>
<!ENTITY rfc4856 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4856.xml'>
<!ENTITY rfc4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY rfc4629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4629.xml'>
<!ENTITY rfc3688 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml'>
<!ENTITY rfc4574 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4574.xml'>
<!ENTITY rfc4975 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4975.xml'>
<!ENTITY rfc4976 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4976.xml'>
<!ENTITY rfc5766 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml'>
<!ENTITY w3c.REC-xml-20040204 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-20040204.xml'>
<!ENTITY w3c.REC-xml-names-19990114 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-names-19990114'>
<!ENTITY i-d.ietf-sipping-config-framework PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-config-framework.xml'>
<!ENTITY i-d.ietf-sip-session-policy-framework PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-session-policy-framework.xml'>
]>
<rfc ipr='trust200902' category='std' docName='draft-ietf-sipping-media-policy-dataset-11'>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc sortrefs='yes'?>
<front>
<title abbrev='Media Policy Dataset'>A User Agent Profile Data Set for Media Policy</title>
<author initials='V.H.' surname='Hilt' fullname='Volker Hilt'>
<organization>Bell Labs/Alcatel-Lucent</organization>
<address>
<postal>
<street>791 Holmdel-Keyport Rd</street>
<city>Holmdel</city> <region>NJ</region>
<code>07733</code>
<country>USA</country>
</postal>
<email>volkerh@bell-labs.com</email>
</address>
</author>
<author initials='D.W.' surname='Worley' fullname='Dale R. Worley'>
<organization>Avaya Inc.</organization>
<address>
<postal>
<street>600 Technology Park Dr.</street>
<city>Billerica</city> <region>MA</region>
<code>01821</code>
<country>US</country>
</postal>
<email>dworley@avaya.com</email>
</address>
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Gonzalo.Camarillo@ericsson.com</email>
</address>
</author>
<author initials='J.R.' surname='Rosenberg' fullname='Jonathan Rosenberg'>
<organization>jdrosen.net</organization>
<address>
<postal>
<city>Monmouth</city><region>NJ</region>
<country>USA</country>
</postal>
<email>jdrosen@jdrosen.net</email>
</address>
</author>
<date month="February" year="2011" />
<area>Transport</area>
<workgroup>SIPPING Working Group</workgroup>
<keyword>SIP</keyword>
<keyword>Session Policy</keyword>
<keyword>Data Set</keyword>
<abstract>
<t>This specification defines a document format for the media
properties of Session Initiation Protocol (SIP) sessions. Examples
for media properties are the codecs or media types used in a
session. This document format is based on XML and can be used to
describe the properties of a specific SIP session or to define
policies that are then applied to SIP sessions.</t>
</abstract>
</front>
<middle>
<section title="Open Revision Items">
<t>This version of this Internet-Draft is largely the same as the
previous version. It has been submitted primarily to maintain the
draft as active. A number of significant open issues are
described in this section.</t>
<section title="Media Types">
<section title="Require Registration">
<t>In -10, all media type names that are mentioned in a MPDF are explicitly required to be IANA-registered. Technically, this means that experimental or private-use types can not be used, even in situations where all participants are aware of non-registered media types. In practice, people will go ahead and use them anyway. I am proposing to remove the "registered" requirement.</t>
</section>
<section title="Terminology">
<t>In a number of places, media types are called "MIME types". The latter is common usage, but it is not official, and as RFC 4288 makes clear, media types are independent of their use within MIME. I've fixed the wording of the draft in a number of places to correct this.</t>
</section>
<section title="Rename the <mime-type> child of <codec>">
<t>There is an element <mime-type> that is a child of the <codec> element that carries a media type and subtype. The natural fix would be to change this to <media-type>, but there is already an element of that name that is a child of <stream> that carries a media type (without subtype). I would like a name that means "media type and subtype", but I can't think of a short one. Suggestions?</t>
</section>
</section>
<section title="Remove reference to uaprofile.rng">
<t>The Relax NG schema given in draft-ietf-sipping-media-policy-dataset includes "uaprofile.rng". As far as I can figure out, uaprofile.rng is the schema defined in draft-ietf-sipping-profile-datasets, which has been abandoned. So we need to remove the reference to uaprofile.rng. It's possible that there are things defined in that schema that need to be either deleted from draft-ietf-sipping-media-policy-dataset, or copied from the abandoned draft into the schema in draft-ietf-sipping-media-policy-dataset.</t>
<t>If anyone has further information about this, please tell me.</t>
</section>
<section title="Remove <property-set>">
<t>I have updated the text of draft-ietf-sipping-media-policy-dataset-11 to consistently use "property-set" rather than sometimes using "property_set". However, it seems to me that the <property-set> element serves no use (now that sipping-profile-datasets has been abandoned). The draft says that each <session-info> and <session-policy> appears in a <property-set>, and <property-set> can contain more than one of each. But there seems to be no practical use for this grouping; the semantics of <session-info> and <session-policy> is completely standalone.</t>
<t>So I am proposing eliminating the <property-set> element entirely, making <session-info> and <session-policy> into top-level elements.</t>
</section>
<section title="Specifying Sets">
<t>There are many properties for which the values are sets of primitive values. The current syntax for specifying sets is awkward. In addition, it is not permitted to specify a set containing zero elements. Sessions containing empty sets are not useful to write, but it is easy to generate them when applying a policy to a <session-info>. So the syntax for set values needs to be updated.</t>
</section>
<section title="Specifying Bandwidth Limitations">
<t>Looking at the XML of draft-ietf-sipping-media-policy-dataset, I see this paragraph:</t>
<figure>
<artwork><![CDATA[
<!--
<t>If a b= line is present for a media stream, this line MUST be
used to create the bandwidth elements.</t>
-->
]]></artwork>
</figure>
<t>SDP provides "b=" lines for specifying bandwidth limitations. Similarly, MPD provides <max-bw>, <max-session-bw>, and <max-stream-bw> elements, and the draft states that they are equivalent to various forms of the b= line. Should we require that when SDP is translated into MPD that the bandwidth limitations be translated?</t>
</section>
<section title="Rejecting a media stream">
<t>In draft-ietf-sipping-media-policy-dataset-10 there is no explicit way to indicate that a stream has been rejected (which is needed to correspond to an m= line in SDP where the port number is 0). Implicitly, this can be done by setting the port number in the <local-host-port> or <remote-host-port> to 0. But that is pretty ugly. I propose that we introduce an attribute of the <stream> element to indicate that a stream has been rejected/disabled:</t>
<figure>
<artwork><![CDATA[
<stream enabled="no">
]]></artwork>
</figure>
<t>The default value of "enabled" would be "yes".</t>
<t>This resolves the problem of how a policy server would modify a <session-info> to make it conform to a policy if one of the <stream>s contradicted the policy: The policy server would put enabled="no" onto the <stream>.</t>
<t>For consistency, a policy server could effectively reject a proposed session by rejecting all of the streams within it. This would be slightly different than rejecting the session as a whole by returning an empty session-info document, <session-info/>. This distinction corresponds to the difference between an SDP offer/answer negotiation failing, and the negotiation succeeding but the answer rejecting all the m= lines in the SDP.</t>
</section>
<section title="The implied boolean logic of policy operations">
<t>I am starting work on a messy part of the media policy dataset
definition: Specifying the logic when a policy is applied to a
session-info, and also specifying how two policies are combined to
apply jointly to session-infos. The goal is to implement one's
intuitive expectations while introducing as few special cases as
possible.</t>
<t>My current analysis is:
<list style="symbols">
<t>The primary operation is applying a session-policy to a session-info
to produce a possibly more restricted session-info. This is done by
applying the session-policy to each stream in turn, which may
"restrict" the stream (in regard to bandwidth, codecs, etc.).</t>
<t>A stream may be restricted to the point that it permits no media
whatsoever. Such "null" streams are all logically equivalent,
although a null stream can be represented in many different ways.
When translated back into SDP, a null stream becomes a rejected
m= line.</t>
<t>The different <stream> elements in a session-policy are effectively
ORed together, in that the policy intends to permit any stream that
conforms to *any one* of the <stream> elements. This is necessary
because e.g. a session-policy can contain one <stream> that specifies
audio media and restricts the codecs permitted for audio, and
another <stream> that specifies video media and restricts the codecs
permitted for video.</t>
<t>Thus, applying a session-policy to a stream involves applying each
session-policy <stream> to the stream, and then choosing the "best"
result. In practice, we expect that the streams admitted by the
session-policy <stream> elements to be disjoint (e.g., one is for
audio, one is for video), so the result of applying any but one
<stream> will be a null stream, and the "best" result will be the
only non-null result.</t>
<t>The alternative strategy of "unioning" the results of applying each
<stream> element cannot be used because it can allow the resulting
session to exceed all of the <stream> element policies. Consider
the policy
<figure>
<artwork><![CDATA[
<streams>
<stream> codecs: audio/foo, bandwidth: 10 </stream>
<stream> codecs: audio/foo,audio/bar, bandwidth: 1 </stream>
</streams>
]]></artwork>
</figure>
applied to the requested stream "codecs: audio/foo,audio/bar,
bandwidth: 10". The result of restricting with the first <stream>
is "codecs: audio/foo, bandwidth: 10" and the result of restricting
with the second <stream> is "codecs: audio/foo,audio/bar, bandwidth:
1". The union of the two (the "smallest" stream that contains them
both) is "codecs: audio/foo,audio/bar, bandwidth: 10", which is not
allowed by either <stream>.</t>
<t>Within this context, combining two policies to form a joint policy
that enforces both their restrictions simultaneously is simple: The
resulting policy is made by "intersecting" all possible pairs of
<stream>s, one from the first policy and one from the second policy.
(Intersections that result in null policies can be dropped from the
result.)</t>
<t>I haven't studied the role of the directional attributes yet, but
currently I believe that a bidirectional session-info <stream> can
be treated as an abbreviation for two session-info <stream>s, one in
each direction, and a bidirectional session-policy <stream> can be
treated similarly. Or, directionality can be treated as an
attribute with two possible values, *with identical results*.</t>
</list>
</t>
</section>
</section>
<section title="Introduction">
<t>The Framework for Session Initiation Protocol (SIP) <xref
target="RFC3261"/> User Agent Profile Delivery <xref
target="I-D.ietf-sipping-config-framework" /> and the Framework
for SIP Session Policies <xref
target="I-D.ietf-sip-session-policy-framework" /> 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.</t>
<t>This specification defines a document format for media
properties of SIP sessions, the Media Policy Dataset 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.</t>
<t>If used with the Framework for SIP Session Policies <xref
target="I-D.ietf-sip-session-policy-framework" />, session info
documents are used in conjunction with session-specific
policies. A session info document is created by a 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.</t>
<t>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.</t>
<t>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 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.</t>
<t>Merging rules are not needed for elements of session
information documents since they are created by one source and
describe a specific session.</t>
</section>
<section title="Terminology">
<t>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
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Media Policy Dataset Format">
<t>This section discusses fundamental properties of the Media
Policy Dataset Format (MPDF).</t>
<section title="Namespace and Media Type">
<t>The MPDF format is based on XML <xref
target="W3C.REC-xml-20040204" />. A 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.</t>
<t>MPDF makes use of XML namespaces <xref
target="W3C.REC-xml-names-19990114" />. The namespace URIs for
schemas defined in this specification are <xref
target="RFC2141">URNs</xref>, using the namespace identifier
'ietf' defined by <xref target="RFC2648" /> and extended by
<xref target="RFC3688"/>. The namespace
URN for the MPDF schema is:</t>
<t><list style="empty">
<t>urn:ietf:params:xml:ns:mediadataset</t>
</list></t>
<t>The media type for the Media Policy Dataset Format is:</t>
<t><list style="empty">
<t>application/media-policy-dataset+xml</t>
</list></t>
</section>
<section title="Extensibility">
<t>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.</t>
</section>
<section title="Attributes" anchor="sec:attributes">
<t>The following attributes can be used with elements of the
MPDF format. For each MPDF element it is defined, which of these
attributes can be used. Attributes that are not defined for an
element MUST be ignored.</t>
<section title="The 'visibility' Attribute">
<t>The attribute "visibility" specifies whether or not the
user agent is permitted 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:</t>
<t><list style='symbols'>
<t>visible: specifies that display of the property value is
not restricted. This is the default value of the attribute
if it is not specified.</t>
<t>hidden: Specifies that the user agent SHOULD NOT display
the property value. Display of the property value may be
allowed using special administrative interfaces, but is not
appropriate to the ordinary user.</t>
</list></t>
</section>
<section title="The 'direction' Attributes">
<t>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.</t>
<t>The 'direction' attribute can have the following values:</t>
<t><list style='symbols'>
<t>recvonly: the property only applies to incoming messages/streams.</t>
<t>sendonly: the property only applies to outgoing messages/streams.</t>
<t>sendrecv: the property applies to messages/streams in
both directions. This is the default value that is used if
the 'direction' attribute is omitted.</t>
</list></t>
</section>
<section title="The 'q' Attribute">
<t>It should be possible to express a preference for a certain
value, if multiple values are allowed within a property. For
example, it should be possible to express that the codecs
G.711 and G.729 are allowed, but G.711 is preferred.
Preferences can be expressed by adding a 'q' attribute to a
property element. Elements derived from the "setting" element
for which multiple occurrences and values are allowed SHOULD
have a "q" attribute if the order is significant. Typically
these elements are contained in an element derived from the
"setting_container" element. The 'q' attribute is only
meaningful if the 'policy' attribute set to 'allowed'. It
must be ignored in all other cases.</t>
<t>An element with a higher 'q' value is preferred over one
with a lower 'q' value. 'q' attribute values range from 0 to
1. The default value is 0.5.</t>
</section>
<section title="The 'label' Attribute" anchor="sec:stream-label">
<t>Some properties only apply to a specific media stream. The
stream to which a property applies MUST be identifiable
through a label <xref target="RFC4574" />. Per-stream
properties can be expressed by adding a 'label' attribute to
the respective element. Such a property only applies to the
identified stream. If there is no stream with this label, the
element must be ignored.</t>
<t>Per-stream properties require that the labels of media
streams are known to the creator of a document (i.e., the
profile delivery/policy server). These labels are part of the
session description.</t>
</section>
</section>
</section>
<section title="Session Info Documents">
<t>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 an <xref
target="RFC4566">SDP</xref> session description or an SDP
offer/answer pair <xref target="RFC3264" />.</t>
<t>Session info documents can be used for session-specific
policies <xref target="I-D.ietf-sip-session-policy-framework"
/>. In this usage, a UA creates a session info document based on
its SDP 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 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 the video
stream in the session info document that it returns
to the UA.</t>
<t>Session info documents use the <session-info>
root element. They use elements described in this section and common
elements described in <xref target="sec:elements" />.</t>
<t>Elements that are only present in session info document 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 outside the scope
of this standard.</t>
<t>A policy server can completely reject a session by returning an
session info document with an empty <session-info> element: </t>
<t><list style="empty">
<t><session-info><\session-info></t>
</list></t>
<section title="Mapping SDP to Session Info Documents">
<t>If a UA has an SDP offer as well as an answer <xref
target="RFC3264" /> and wants to create a session info document,
the UA MUST use the answer to fill in the elements of the session
info document except for the remote-host-port and
local-host-port elements, which are taken from the remote and
local session description respectively. (The local
session description is the one sent by the UA;
the remote session description is the one received
from the remote UA.)</t>
<t>The following rules describe the creation of session info
documents based on SDP description(s) for a few exemplary
elements. Other elements are created following the same
principles.</t>
<t>A UA MUST create a separate <stream> element for each
m= line in an SDP description; the order of the <stream>
elements corresponds to the order of the m= lines.
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.</t>
<t>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 MUST 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.</t>
<t>The mapping from a session info document to a SDP description
follows the same rules in the reverse direction.</t>
<!--
<t>If a b= line is present for a media stream, this line MUST be
used to create the bandwidth elements.</t>
-->
</section>
<section title="The <session-info> Element">
<t>The <session-info> element describes the properties of
a specific SIP session.
The <session-info> element MAY contain one optional
<streams>, <context> 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. The MPDF elements are
defined in <xref target="sec:elements" />.</t>
</section>
<section title="The <streams> Element">
<t>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.</t>
<section title="The <stream> Element">
<t>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.</t>
<t>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 MUST 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. </t>
<t>This element MAY have the following attributes (see <xref
target="sec:attributes" />): direction, label.</t>
<t>The label attribute is used to identify a specific media
stream in a session description. The value of the label
attribute is a token. The token can be chosen freely, however,
it MUST be unique among all <stream> element in a
session-info document. If a label attribute <xref
target="RFC4574"/> is present in the SDP description, its
value MUST be used as the label attribute value of the
corresponding <stream> element.</t>
<t>The <stream> element MUST contain one
<media-type> element, one or more <codec> elements
and one <local-host-port> element. The <stream>
element MAY contain one <remote-host-port> element.</t>
<section title="The <local-host-port> Element">
<t>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".</t>
<t>The hostname or IP address of element is found in the c=
element for the stream in the local SDP description. The
port number is found in the m= element.</t>
</section>
<section title="The <remote-host-port> Element">
<t>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.</t>
</section>
</section>
</section>
<section title="The <media-intermediaries> Element">
<t>The <media-intermediaries> element expresses a policy
for routing a media stream through a media intermediary. The
purpose of the <media-intermediaries> element is to tell
the UA to send a media stream through one (or a chain of) media
intermediaries. Instead of sending the media directly to its
final destination, the UA specifies a source route, which
touches each intermediary and then reaches the final
recipient. If there are N hops, including the final recipient,
there needs to be a way for the media stream to specify N
destinations.</t>
<t>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. </t>
<t>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.</t>
<t>This element MAY have the following attributes (see <xref
target="sec:attributes" />): direction.</t>
<t>Multiple <media-intermediaries> elements MAY only be
present in a container if 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>.</t>
<t><list style="empty">
<t>Note: it is not intended that the
<media-intermediaries> element replaces connectivity
discovery mechanisms such as 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.</t>
</list></t>
<section title="The <fixed-intermediary> Element">
<t>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
to. The configuration of forwarding rules in the intermediary
must be done through other means.</t>
<t>The contents of a <fixed-intermediary> element MUST
be echoed to all policy servers that provide policies for a
session. I.e., 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
<xref target="I-D.ietf-sip-session-policy-framework" /> in
section Contacting the Policy Server.</t>
<t>The <fixed-intermediary> element MUST contain one
<int-host-port> element and MAY contain multiple optional
<int-addl-port> elements.</t>
<section title="The <int-host-port> Element">
<t>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 ":".</t>
<t>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.</t>
</section>
<section title="The <int-addl-port> Element">
<t>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.</t>
</section>
</section>
<section title="The <turn-intermediary> Element">
<t>The TURN <xref target="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.</t>
<t>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.</t>
<section title="The <shared-secret> Element">
<t>The <shared-secret> element contains the shared
secret needed to authenticate at the media intermediary.</t>
</section>
<section title="The <user> element">
<t>The <user> element contains the user ID needed to
authenticate to the media intermediary.</t>
</section>
<section title="The <transport> Element">
<t>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.</t>
</section>
</section>
<section title="The <msrp-intermediary> Element">
<t>The MSRP Relay Extensions <xref target="RFC4976"/> define a
means for incorporating relays into the media path of an MSRP
<xref target="RFC4975"/> session. MSRP is explicitly designed
for a variety of purposes, including policy enforcement.</t>
<t>The <msrp-intermediary> element MUST contain one
<msrp-uri> element, and may contain zero or one each of
the <shared-secret> and <user> elements.</t>
<section title="The <msrp-uri> Element">
<t>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. Only URIs with a
scheme of "msrps:" are valid in the <msrp-uri>
element.</t>
</section>
</section>
</section>
</section>
<section title="Session Policy Documents">
<t>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.</t>
<t>Session policy documents can be used to encode
session-independent policies
<xref target="I-D.ietf-sip-session-policy-framework" />. 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 media type video in its SDP offer or
answer. </t>
<t>Session policy documents use the <session-policy>
root element. They use elements described in this section and common
elements described in <xref target="sec:elements" />.</t>
<section title="Merging Session Policies" anchor="sec:merging">
<t>A UA may receive session policy documents from multiple
sources; multiple session policy documents can be merged into a
single session policy document which expresses the logical AND
of the policies.</t>
<section title="Single Value Selection">
<t>Properties that have a single value (e.g., the maximum
bandwidth allowed) require that a common value is 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).</t>
</section>
<section title="Merging Sets" anchor="sec:setmerge">
<t>The media-types-allowed, media-types-excluded,
codecs-allowed and codecs-excluded are containers that contain
a set of media-types/codecs. The values defined in these
containers need to be merged to determine the set of
media-types/codecs that are permissible in a session.</t>
<t>To merge the media-types-* and codecs-* containers a UA
needs to apply all containers it has received one after the
other 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 can 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.</t>
<t>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.</t>
<t><figure><artwork><![CDATA[
Session Policy Document 1:
<codecs-excluded>
<codec><mime-type>audio/PCMA</mime-type></codec>
</codecs>
Session Policy Document 2:
<codecs-allowed>
<codec><mime-type>audio/PCMA</mime-type></codec>
<codec><mime-type>audio/G729</mime-type></codec>
</codecs>
]]></artwork></figure></t>
<t>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-types/codecs
element. 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.</t>
<t>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.</t>
</section>
<section title="Local Policy Server Selection" anchor="sec:localselect">
<t>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.</t>
<t>If policy documents are delivered through the configuration
framework <xref target="I-D.ietf-sipping-config-framework" />,
the value received through a subscription using the
"local-network" profile-type is used. Values received through
other profile-type subscriptions are discarded.</t>
<t>If policy documents are delivered through the
session-specific policy mechanism
<xref target="I-D.ietf-sip-session-policy-framework" /> the
value received from the policy server identified by the Local
Policy Server URI are used. Values received from other policy
servers are discarded.</t>
</section>
</section>
<section title="The <session-policy> Element">
<t>The <session-policy> element describes a policy that
applies to SIP sessions.
The <session-policy> element MAY contain one optional
<context> and <local-ports> element 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. The MPDF elements are defined in
<xref target="sec:elements" />.</t>
</section>
<section title="The <media-types-allowed> Element">
<t>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.</t>
<t>This element MAY have the following attributes (see <xref
target="sec:attributes" />): direction, visibility.</t>
<t>Multiple <media-types-allowed> elements MAY only be present in
a container element if 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 one or more <media-type> elements. </t>
<t>A <media-types-allowed> element MUST NOT be used in a
container that contains a <media-types-excluded>
element.</t>
<t><list style="empty">
<t>Merging of session-policy documents:
<media-types-allowed> containers are merged as described
in "Merging Sets" <xref target="sec:setmerge" />.</t>
</list></t>
</section>
<section title="The <media-types-excluded> Element">
<t>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.</t>
<t>This element MAY have the following attributes (see <xref
target="sec:attributes" />): direction, visibility.</t>
<t>Multiple <media-types-excluded> elements MAY only be present in
a container element if 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 one or more <media-type> elements. </t>
<t>A <media-types-excluded> element MUST NOT be used in a
container that contains a <media-types-allowed>
element.</t>
<t><list style="empty">
<t>Merging of session-policy documents:
<media-types-excluded> containers are merged as
described in "Merging Sets" <xref target="sec:setmerge" />.</t>
</list></t>
</section>
<section title="The <codecs-allowed> Element">
<t>The <codecs-allowed> element is a container that is
used to define the set of codecs that may be used in a
session. All codes 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.</t>
<t>The <codecs-allowed> element MAY have the following attributes
(see <xref target="sec:attributes" />): direction, visibility.</t>
<t>Multiple <codecs-allowed> elements MAY only be present in a
container element if 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 one
or more <codec> elements.</t>
<t>A <codecs-allowed> element MUST NOT be used in a
container that contains a <codecs-excluded>
element.</t>
<t><list style="empty">
<t>Merging of session-policy documents: <codecs-allowed>
containers are merged as described in "Merging Sets"
<xref target="sec:setmerge" />.</t>
</list></t>
</section>
<section title="The <codecs-excluded> Element">
<t>The <codecs-excluded> element is a container that is
used to define the set of codecs that are disallowed in a
session. All codes 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.</t>
<t>The <codecs-excluded> element MAY have the following attributes
(see <xref target="sec:attributes" />): direction, visibility.</t>
<t>Multiple <codecs-excluded> elements MAY only be present in a
container element if 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 one
or more <codec> elements.</t>
<t>A <codecs-excluded> element MUST NOT be used in a
container that contains a <codecs-allowed>
element.</t>
<t><list style="empty">
<t>Merging of session-policy documents:
<codecs-excluded> containers are merged as described in
"Merging Sets" <xref target="sec:setmerge" />.</t>
</list></t>
</section>
<section title="The <local-ports> Element">
<t>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 a start port and an
end port separated by a "-". The start/end port is the
first/last port that can be used.</t>
<t>This element MAY have the following attributes (see <xref
target="sec:attributes" />): visibility.</t>
<t><list style="empty">
<t>Merging of session-policy documents: the local domain of
the user agent has precedence over other domains and its local
ports value is used. During the merging process,
<local-ports> element values from local policy server
selected as described in "Local Policy Server Selection"
<xref target="sec:localselect" /> are used.</t>
</list></t>
</section>
</section>
<section title="Common Media Policy Dataset Elements" anchor="sec:elements">
<t>This section describes common XML elements that are used in session
info and session policy documents to encode the media properties
of SIP sessions.</t>
<section title="The <media-type> Element" anchor="sec:mediatype">
<t>The <media-type> element identifies a specific media
type. The value of this element MUST be the name of a
media type, such as 'audio', 'video', 'text', or 'application'. </t>
<t>This element MAY have the following attribute (see
<xref target="sec:attributes" />): q.</t>
<t>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.</t>
</section>
<section title="The <codec> Element">
<t>The <codec> element identifies a specific codec. The
content of this element MUST be a media type and subtype (e.g.,
audio/PCMA <xref target="RFC4856"/> or video/H263
<xref target="RFC4629"/>), possibly with parameters.</t>
<t>The <codec> element MAY have the following attribute
(see <xref target="sec:attributes" />): q.</t>
<t>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.</t>
<t>The <codec> element MUST contain one <mime-type>
element and MAY contain multiple optional <mime-parameter>
elements.</t>
<section title="The <mime-type> Element">
<t>The <mime-type> element contains a media type and subtype that
identifies a codec. The value of this element MUST be a
media type and subtype
<xref target="RFC4855" /> separated by a "/"
(e.g., audio/PCMA, audio/G726-16 <xref target="RFC4856"/> or
video/H263 <xref target="RFC4629"/>). </t>
</section>
<section title="The <mime-parameter> Element">
<t>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 <xref target="RFC4855" />. The name and value
are separated by a "=". For example, the parameter
"profile=0" can be used to specify a specific profile for
the codec "video/H263-2000" <xref target="RFC4629"/>.</t>
</section>
</section>
<section title="The <max-bw> Element">
<t>The <max-bw> element defines the overall maximum
bandwidth in kilobits 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.</t>
<t>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).</t>
<t>The <max-bw> element MAY have the following
attribute (see <xref target="sec:attributes" />): direction.</t>
<t>If used in a <session-policy> element, the
<max-bw> element MAY have the following additional
attribute (see <xref target="sec:attributes" />): visibility.</t>
<t>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).</t>
<t><list style="empty">
<t>Merging of session-policy documents: the lowest
max-bw value is used.</t>
</list></t>
</section>
<!--
<section title="The <max-bw-ti> Element">
<t>The <max-bw-ti> element defined as the <max-bw>
element with the following exceptions.</t>
<t>The given bandwidth limit is transport independent and
therefore does not include include the bandwidth needed for
lower-layer transport and network protocols (e.g., UDP and
IP).</t>
<t>The bandwidth limit is given in bits per second (i.e., not in
kilobits per second).</t>
<t>The <max-bw-ti> element MAY have the following
attribute (see <xref target="sec:attributes" />): pprate.</t>
<t>The <max-bw-ti> element has an optional attribute
'maxprate'. The "maxprate" value is the maximum packet rate
calculated over all the declared media streams. If this can't
be measured (stored media) or estimated (live), the sum of all
media level values provides a ceiling value.</t>
<t>All other attributes and merging rules are defined as for the
<max-bw> element.</t>
</section>
-->
<section title="The <max-session-bw> Element">
<t>The <max-session-bw> element defines the maximum
bandwidth in kilobits 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.</t>
<t>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).</t>
<t>The value of the <max-session-bw> element is
equivalent to the CT bandwidth in the b= line of an <xref
target="RFC4566">SDP</xref> announcement.</t>
<t>The <max-session-bw> element MAY have the
following attribute (see <xref target="sec:attributes" />):
direction.</t>
<t>If used in a <session-policy> element, the
<max-session-bw> element MAY have the following
additional attribute (see <xref target="sec:attributes" />):
visibility.</t>
<t>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).</t>
<t><list style="empty">
<t>Merging of session-policy documents: the lowest
max-session-bw value is used.</t>
</list></t>
</section>
<section title="The <max-stream-bw> Element">
<t>The <max-stream-bw> element defines the maximum
bandwidth in kilobits per second an entity can/will use for each
media stream in the described session.</t>
<t>The bandwidth limit given in the <max-stream-bw>
element includes the bandwidth needed for lower-layer transport
and network protocols (e.g., UDP and IP).</t>
<t>The value of the <max-stream-bw> element is
equivalent to the AS bandwidth in the b= line of an <xref
target="RFC4566">SDP</xref> announcement.</t>
<t>The <max-stream-bw> element MAY have the
following attribute (see <xref target="sec:attributes" />):
direction, media-type.</t>
<t>If used in a <session-policy> element, the
<max-stream-bw> element MAY have the following
additional attribute (see <xref target="sec:attributes" />):
visibility.</t>
<t>If used in a <session-info> element, the
<max-stream-bw> element MAY have the following additional
attribute: label.</t>
<t>The media-type attribute is used to define that the
<max-stream-bw> element only applies to streams of
a certain media type. 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'.</t>
<t>The label attribute 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.</t>
<t>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).</t>
<t><list style="empty">
<t>Merging of session-policy documents: the lowest
max-stream-bw value is used.</t>
</list></t>
</section>
<section title="The <qos-dscp> Element">
<t>The <qos-dscp> element contains an Differentiated
Services Codepoint (DSCP) <xref target="RFC2474" /> value that
should be used to populate the IP DS field of media packets. The
<qos-dscp> contains an integer value that represents a 6
bit field and therefore ranges from 0 to 63.</t>
<t>This element MAY have the following attributes (see <xref
target="sec:attributes" />): direction, media-type.</t>
<t>If used in a <session-policy> element, the
<qos-dscp> element MAY have the following additional
attribute (see <xref target="sec:attributes" />):
visibility.</t>
<t>The media-type attribute is used to define that
<qos-dscp> element only applies to streams of a certain
media type. For example, it may only apply to audio streams. The
value of the 'media-type' attribute MUST be the name of a
media type, such as 'audio', 'video', 'text', or 'application'.</t>
<!--
<t><list style="empty">
<t>Open issue: need a better way to express per-stream
qos-dscps.</t>
</list></t>
-->
<t>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).</t>
<t><list style="empty">
<t>Merging of session-policy documents: the local domain of
the user agent has precedence over other domains and its
DSCP value is used. During the merging process,
<qos-dscp> element values from local policy server selected as
described in "Local Policy Server Selection"
<xref target="sec:localselect" /> are used.</t>
</list></t>
</section>
<section title="The <context> Element">
<t>The <context> element provides context information
about a session policy or session information document.</t>
<t>The <context> element MAY contain multiple
<contact> and one <info> element.</t>
<t>If used in a <session-policy> element, the
<context> element MAY also contain a
<policy-server-URI> element.</t>
<t>If used in a <session-info> element, the
<context> element MAY also contain a <request-URI>
and a <token> element.</t>
<t><list style="empty">
<t>Merging of session-policy documents: the <context>
element is not subject to merging.</t>
</list></t>
<section title="The <policy-server-URI> Element">
<t>The <policy-server-URI> element contains the URI of
the policy server that has issued this policy.</t>
<t>The <policy-server-URI> element is only defined
inside a <session-policy> element.</t>
</section>
<section title="The <contact> Element">
<t>The <contact> element contains a contact address
(e.g., a SIP URI or email address) under which the issuer of
this document can be reached.</t>
</section>
<section title="The <info> Element">
<t>The <info> element provides a short textual
description of the policy or session that should be
intelligible to the human user.</t>
</section>
<!--
<section title="The <call-ID> Element">
<t>The <call-ID> element contains the call-ID (as
defined in <xref target="RFC3261">RFC3261</xref>) of the
session that is described in this document. The
<call-ID> element is only defined inside a
<session-info> element.</t>
<t>The <dialog-ID> element is optional in a
<context> element. The <dialog-ID> element MUST
contain a <call-ID> and a <local-tag> and MAY
contain a <remote-tag> element.</t>
<t>The <local-tag> element contains the local tag (as
defined in <xref target="RFC3261">RFC3261</xref>) of the
session the policies are for.</t>
<t>The <remote-tag> element contains the remote tag (as
defined in <xref target="RFC3261">RFC3261</xref>) of the
session the policies are for. If the remote tag element is
omitted, the policies apply to all sessions that have the
given call-ID and local tag.</t>
<t>Local and remote tags are defined from the viewpoint of the
recipient of the document. </t>
</section>
-->
<section title="The <request-URI> Element">
<t>The <request-URI> element identifies the request-URI
the dialog initiating request of a session is sent to.</t>
<t>The <request-URI> element is only defined inside a
<session-info> element.</t>
</section>
<section title="The <token> Element">
<t>The <token> element provides a mechanism for a policy
server to return an opaque token to a UA. This is sometimes
needed to ensure that all requests for a session are routed to
the same policy server. The use of this token is described in
the Framework for SIP Session Policies <xref
target="I-D.ietf-sip-session-policy-framework" />.</t>
<t>The <token> element is only defined inside a
<session-info> element.</t>
</section>
</section>
<section title="Other Session Properties">
<t>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.</t>
<t><list style="symbols">
<t>maximum number of streams</t>
<t>maximum number of sessions</t>
<t>maximum number of streams per session</t>
<t>external address and port</t>
<t>media transport protocol</t>
<t>outbound proxy</t>
<t>SIP methods</t>
<t>SIP option tags</t>
<t>SIP transport protocol</t>
<t>body disposition</t>
<t>body format</t>
<t>body encryption</t>
</list></t>
</section>
</section>
<section title="Examples">
<section title="Session Policy Documents">
<t>The following example describes 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.</t>
<t><figure><artwork><![CDATA[
<session-policy>
<context>
<policy-server-URI>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>
<codecs-excluded>
<codec><mime-type>audio/G729</mime-type></codec>
<codec><mime-type>audio/G723</mime-type></codec>
</codecs>
</session-policy>
]]></artwork></figure></t>
</section>
<section title="Session Information Documents">
<t>The following examples contain session descriptions and the
session information documents that represent these
sessions. </t>
<section title="Example 1">
<t>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.</t>
<t>Local SDP session description:</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
<t>MPDF document:</t>
<figure><artwork><![CDATA[
<session-info>
<context>
<contact>sip:alice@somewhere.example</contact>
<info>session information</info>
</context>
<streams>
<stream>
<media-type>audio</media-type>
<codec><mime-type>audio/PCMU</mime-type></codec>
<codec><mime-type>audio/1016</mime-type></codec>
<codec><mime-type>audio/GSM</mime-type></codec>
<local-host-port>host.somewhere.example:49562</local-host-port>
</stream>
<stream>
<media-type>video</media-type>
<codec><mime-type>video/H261</mime-type></codec>
<codec><mime-type>video/H263</mime-type></codec>
<local-host-port>host.somewhere.example:51234</local-host-port>
</stream>
</streams>
</session-info>
]]></artwork></figure>
</section>
<section title="Example 2" anchor="sec:example2">
<t>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.</t>
<t>Local SDP session description:</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
<t>Remote SDP session description:</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
<t>MPDF document that represents the local and the remote
session description:</t>
<figure><artwork><![CDATA[
<session-info>
<context>
<contact>sip:alice@somewhere.example</contact>
<info>session information</info>
</context>
<streams>
<stream>
<media-type>audio</media-type>
<codec><mime-type>audio/PCMU</mime-type></codec>
<codec><mime-type>audio/GSM</mime-type></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><mime-type>video/H261</mime-type></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>
]]></artwork></figure>
<t>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. </t>
<!--
In addition, it requires the media
to be sent through a media intermediary.This is indicated
through changed remote and local addresses, as described in
<xref target="sec:intermediaries" />.</t>
-->
<figure><artwork><![CDATA[
<session-info>
<context>
<contact>sip:alice@somewhere.example</contact>
<info>modified session information</info>
</context>
<streams>
<stream label='1'>
<media-type>audio</media-type>
<codec><mime-type>audio/PCMU</mime-type></codec>
<codec><mime-type>audio/GSM</mime-type></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><mime-type>video/H261</mime-type></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>
]]></artwork></figure>
</section>
</section>
</section>
<section title="Relax NG Definition">
<t>This section needs to be updated.</t>
<t><figure> <artwork><![CDATA[
<?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">
<define name="PropertySetExtension" combine="interleave">
<choice>
<element name="session-info">
<ref name="SettingContainerAttributes"/>
<optional>
<ref name="ElementContext"/>
</optional>
<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>
</element>
<element name="session-policy">
<ref name="SettingContainerAttributes"/>
<optional>
<ref name="ElementContext"/>
</optional>
<optional>
<ref name="ElementLocalPorts"/>
</optional>
<zeroOrMore>
<ref name="ElementMediaTypes"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementCodecs"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxSessionBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxStreamBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementQoSDSCP"/>
</zeroOrMore>
</element>
</choice>
</define>
<define name="ElementMediaTypes">
<element name="media-types">
<ref name="PolicyGeneralAttributes"/>
<optional>
<ref name="SettingContainerAttributes"/>
</optional>
<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="AttributePolicy"/>
</optional>
<optional>
<ref name="AttributeGeneric"/>
</optional>
</element>
</define>
<define name="ElementCodecs">
<element name="codecs">
<ref name="PolicyGeneralAttributes"/>
<optional>
<ref name="SettingContainerAttributes"/>
</optional>
<zeroOrMore>
<ref name="ElementCodec"/>
</zeroOrMore>
</element>
</define>
<define name="ElementCodec">
<element name="codec">
<optional>
<ref name="AttributeQ"/>
</optional>
<optional>
<ref name="AttributePolicy"/>
</optional>
<optional>
<ref name="AttributeGeneric"/>
</optional>
<element name="mime-type">
<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>
<oneOrMore>
<ref name="ElementStream"/>
</oneOrMore>
</element>
</define>
<define name="ElementStream">
<element name="stream">
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeLabel"/>
</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="domain">
<data type="string" />
</element>
</optional>
<optional>
<element name="request-URI">
<data type="string" />
</element>
</optional>
<optional>
<element name="token">
<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="AttributeMediaType">
<attribute name="media-type">
<data type="string" />
</attribute>
</define>
<define name="AttributeLabel">
<attribute name="label">
<data type="string" />
</attribute>
</define>
</grammar>
]]></artwork></figure></t>
<!--
<t><figure> <artwork><![CDATA[
<?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">
<include href="uaprofile.rng">
<define name="ElementGenericSetting">
<ref name="ElementGenericMediaSetting"/>
</define>
<define name="ElementGenericSettingContainer">
<ref name="ElementGenericMediaSettingContainer"/>
</define>
</include>
<define name="ElementGenericMediaSettingContainer">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns="urn:ietf:params:xml:ns:mediadataset"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="SettingContainerAttributes"/>
<!-- container can have containers or settings not both -->
<choice>
<zeroOrMore>
<ref name="ElementGenericMediaSetting"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementGenericMediaSettingContainer"/>
</zeroOrMore>
</choice>
</element>
</define>
<define name="ElementGenericMediaSetting">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns="urn:ietf:params:xml:ns:mediadataset"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="SettingAttributes"/>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
<zeroOrMore>
<choice>
<text/>
<ref name="ElementGenericMediaSetting"/>
</choice>
</zeroOrMore>
</element>
</define>
<define name="PropertySetExtensionInfo" combine="interleave">
<optional>
<element name="session-info">
<ref name="SettingContainerAttributes"/>
<optional>
<ref name="ElementContext"/>
</optional>
<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>
</element>
</optional>
</define>
<define name="PropertySetExtensionPolicy" combine="interleave">
<optional>
<element name="session-policy">
<ref name="SettingContainerAttributes"/>
<optional>
<ref name="ElementContext"/>
</optional>
<optional>
<ref name="ElementLocalPorts"/>
</optional>
<zeroOrMore>
<ref name="ElementMediaTypes"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementCodecs"/>
</zeroOrMore>
<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>
</element>
</optional>
</define>
<define name="ElementMediaTypes">
<element name="media-types">
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeExcludedPolicy"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
<ref name="ElementMediaType"/>
</element>
</define>
<define name="ElementMediaType">
<element name="media-type">
<data type="string" />
<interleave>
<optional>
<ref name="AttributeQ"/>
</optional>
<optional>
<ref name="AttributePolicy"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementCodecs">
<element name="codecs">
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeExcludedPolicy"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
<ref name="ElementCodec"/>
</element>
</define>
<define name="ElementCodec">
<element name="codec">
<interleave>
<optional>
<ref name="AttributeQ"/>
</optional>
<optional>
<ref name="AttributePolicy"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
<element name="mime-type">
<data type="string" />
</element>
<zeroOrMore>
<element name="mime-parameter">
<data type="string" />
</element>
</zeroOrMore>
</element>
</define>
<define name="ElementStreams">
<element name="streams">
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
<oneOrMore>
<ref name="ElementStream"/>
</oneOrMore>
</element>
</define>
<define name="ElementStream">
<element name="stream">
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
<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" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementSessionMaxBandwidth">
<element name="max-session-bw">
<data type="integer" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementMaxStreamBandwidth">
<element name="max-stream-bw">
<data type="integer" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementMediaIntermediaries">
<element name="media-intermediaries">
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
<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" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeMediaType"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementLocalPorts">
<element name="local-ports">
<data type="string" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementContext">
<element name="context">
<interleave>
<optional>
<element name="info">
<data type="string" />
</element>
</optional>
<optional>
<element name="domain">
<data type="string" />
</element>
</optional>
<optional>
<element name="request-URI">
<data type="string" />
</element>
</optional>
<zeroOrMore>
<element name="contact">
<data type="string" />
</element>
</zeroOrMore>
</interleave>
</element>
</define>
</grammar>
]]></artwork></figure></t>
-->
<!--
<t><figure> <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:mediadataset"
xmlns:tns="urn:ietf:params:xml:ns:mediadataset"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:spds="http://sipfoundry.org/schema/profile-data-sets-00">
<xs:attributeGroup name="single_stream_attributes" >
<xs:attribute name="stream-label"
type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:attributeGroup name="media_type_attributes" >
<xs:attribute name="media-type"
type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:element name="session-policy">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:context"
minOccurs="0" maxOccurs="1"/>
<xs:element ref="tns:media-types"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:codecs"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:media-intermediaries"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:max-bw"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:qos-dscp"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:local-ports"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="context">
<xs:complexType>
<xs:sequence>
<xs:element name="domain" type="xs:anyURI" minOccurs="0"
maxOccurs="1"/>
<xs:element name="contact" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="info" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="media-types"
substitutionGroup="spds:setting_container">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:media-type"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="codecs"
substitutionGroup="spds:setting_container">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:codec"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="media-intermediaries"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:fixed-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:turn-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="max-bw"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:positiveInteger" />
</xs:simpleContent>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:media_type_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="qos-dscp"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:integer" >
<xs:minInclusive value="0" />
<xs:maxInclusive value="63" />
</xs:restriction>
</xs:simpleContent>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
<xs:attributeGroup ref="tns:media_type_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="local-ports"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:string" />
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="media-type"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:string" />
</xs:simpleContent>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="codec"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="mime-type" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="mime-parameter" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="fixed-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="turn-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="shared-secret" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="ipinip-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="iploose-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
</xs:schema>
]]></artwork></figure></t>
-->
</section>
<section title="Security Considerations" anchor="sec:security">
<t>Session policy information can be sensitive information. The
protocol used to distribute session policy information SHOULD
ensure privacy, message integrity and authentication. Furthermore,
the protocol SHOULD provide access controls which restrict who can
see who else's session policy information. </t>
</section>
<section title="IANA Considerations" anchor="sec:iana">
<t>This document registers a new media type,
application/media-policy-dataset+xml, and a new XML
namespace. </t>
<section title="Media Type Registration">
<t>Media type name: application</t>
<t>Media subtype name: media-policy-dataset+xml</t>
<t>Mandatory parameters: none</t>
<t>Optional parameters: Same as charset parameter
application/xml as specified in <xref target="RFC3023">RFC
3023</xref>.</t>
<t>Encoding considerations: Same as encoding considerations of
application/xml as specified in <xref target="RFC3023">RFC
3023</xref>. </t>
<t>Security considerations: See Section 10 of <xref
target="RFC3023">RFC 3023</xref> and <xref
target="sec:security"/> of this specification. </t>
<t>Interoperability considerations: none.</t>
<t>Published specification: This document.</t>
<t>Applications which use this media type: This document type
has been used to convey media policy information between SIP user
agents and a domain.</t>
<t>Additional Information:</t>
<t>Magic Number: None</t>
<t>File Extension: .mpf or .xml</t>
<t>Macintosh file type code: "TEXT"</t>
<t>Personal and email address for further information: Volker
Hilt,
<![CDATA[<volkerh@bell-labs.com>]]>
</t>
<t>Intended usage: COMMON</t>
<t>Author/Change controller: The IETF.</t>
</section>
<section title="URN Sub-Namespace Registration">
<t>This section registers a new XML namespace, as per the
guidelines in <xref target="RFC3688"/></t>
<t>URI: The URI for this namespace is
urn:ietf:params:xml:ns:mediadataset.</t>
<t>Registrant Contact: IETF, SIPPING working
group, <![CDATA[<sipping@ietf.org>]]>, Volker Hilt,
<![CDATA[<volkerh@bell-labs.com>]]> </t>
<t>
<figure> <artwork><![CDATA[
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 Dataset Namespace</title>
</head>
<body>
<h1>Namespace for Media Policy Datasets</h1>
<h2>urn:ietf:params:xml:ns:mediadataset</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]></artwork></figure>
</t>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc4855;
&rfc4566;
&w3c.REC-xml-names-19990114;
&rfc3688;
&rfc4574;
&rfc2141;
&rfc3023;
&rfc3264;
&rfc2474;
&rfc4975;
&rfc4976;
&rfc5766;
&w3c.REC-xml-20040204;
</references>
<references title='Informative References'>
&i-d.ietf-sip-session-policy-framework;
&i-d.ietf-sipping-config-framework;
&rfc2648;
&rfc4856;
&rfc4629;
<!--
<reference anchor='I-D.ietf-sipping-session-policy-req'>
<front>
<title>Requirements for Session Policy for the Session Initiation Protocol (SIP)</title>
<author initials='J' surname='Rosenberg' fullname='Jonathan Rosenberg'>
<organization />
</author>
<date month='July' day='20' year='2004' />
<abstract><t>The proxy server plays a central role as an intermediary
in the establishment of sessions in the Session Initiation Protocol
(SIP). In that role, they can define and impact policies on call
routing, rendezvous, and other call features. However, there is no
standard means by which proxies can have any influence on session
policies, such as the codecs that are to be used. As such, ad-hoc and
non-conformant techniques have been deployed to allow for such policy
mechanisms. There is a need for a standards-based and complete
mechanism for session policies. This document defines a set of
requirements for such a mechanism.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sipping-session-policy-req-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-sipping-session-policy-req-02.txt' />
</reference>
-->
&rfc3261;
</references>
<section title="Acknowledgements">
<t>Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam
Roach and Ben Campbell for the discussions and suggestions. Many
thanks to Roni Even and Mary Barnes for reviewing the draft and to
Jari Urpalainen for helping with the Relax NG schema.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:40:15 |