One document matched: draft-camarillo-rai-media-policy-dataset-04.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 rfc3470 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3470.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 rfc4583 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4583.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 rfc6080 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6080.xml'>
<!ENTITY w3c.REC-xml-20081126 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-20081126.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-sip-session-policy-framework PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-session-policy-framework.xml'>
<!ENTITY i-d.ietf-sipping-policy-package PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-policy-package.xml'>
]>
<rfc ipr='trust200902' category='std' docName='draft-camarillo-rai-media-policy-dataset-04'>
<?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="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>
<street/>
<city>Monmouth</city><region>NJ</region>
<country>USA</country>
</postal>
<email>jdrosen@jdrosen.net</email>
</address>
</author>
<author initials='D.R.' 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>
<date year="2012" />
<area>RAI</area>
<workgroup>RAI</workgroup>
<keyword>SIP</keyword>
<keyword>Session Policy</keyword>
<keyword>Data Set</keyword>
<abstract>
<t>This specification defines an XML document format to describe the media
properties of Session Initiation Protocol (SIP) sessions. Examples
for media properties are the codecs or media types used in the
session. This document also defines an XML document format
to describe policies that limit the media properties of SIP sessions.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Framework for Session Initiation Protocol (SIP) <xref
target="RFC3261"/> User Agent Profile Delivery <xref
target="RFC6080" /> 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-20081126" />. 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
elements 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. The specification of each MPDF element lists which
of these attributes can be used. If an element bears an
attribute which may not be used with it, the user agent MUST
ignore the attribute.</t>
<section title="The 'visibility' Attribute">
<t>The attribute 'visibility' specifies whether or not the
user agent is advised to display the property value to the
user. This is used to hide setting values that the
administrator may not want the user to see or know. The
'visibility' attribute has two possible values:</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 is not advised to
display the property value. Display of the property value
may be allowed using special administrative interfaces, but
is not appropriate for 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 streams.</t>
<t>sendonly: the property only applies to outgoing streams.</t>
<t>sendrecv: the property applies to 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 is possible to express a preference for a certain value
relative to the other values within a set of multiple values
that are allowed within a property. For example, it is
possible to express that the codecs G.711 and G.729 are
allowed, but G.711 is preferred. Preferences are be expressed
by adding a 'q' attribute to a property element. The 'q'
attribute is only allowed in elements that specify allowed
values (as opposed to elements that specify forbidden
values).</t>
<t>The value of the 'q' attribute is a decimal number within
the range 0 to 1, inclusive, with two or less decimal places.
An element with a higher 'q' value is preferred over one with
a lower 'q' value.</t>
</section>
<section title="The 'media-type' Attribute">
<t>The media-type attribute is used to define that an element
only applies to streams of a certain media type, as defined in
Section 8.2.1 of <xref target="RFC4566"/>. For example, it may
only apply to audio streams. The value of the 'media-type'
attribute MUST be the media type, such as 'audio', 'video',
'text', or 'application'.</t>
</section>
<section title="The 'label' Attribute">
<t>The label attribute is used to identify a specific media
stream. The value of the label attribute is a token, whose
syntax is defined in <xref target="RFC4566"/>. The token can
be chosen freely, however, it MUST be unique among all
<stream> elements in a session-info document.</t>
</section>
<section title="The 'enabled' Attribute">
<t>
The 'enabled' attribute specifies whether or not the user
agent is allowed to establish a media stream. This boolean
attribute has two possible values:
</t>
<t><list style='symbols'>
<t>yes: specifies that the media stream can be established.
This is the default value of the attribute if it is not
specified.</t>
<t>no: specifies that the user agent MUST NOT establish the
media stream.</t>
</list></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 (i.e.,
enabled="no") 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 documents do not
require merging rules. If used in the context of session-specific
policies, session info documents are sent to one policy server at
a time only, therefore a UA does not need to merge multiple
session info documents into one. A policy server needs to modify a
session info document it has received according to its
policies. The modification of session info documents is determined
by the local policies of the policy server and is, thus, outside
the scope of this standard.</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 between SDP and Session Info Documents">
<t>This section specifies how to map information in an SDP
session description or an SDP offer/answer pair <xref
target="RFC3264"/> to session info documents. It also specifies
how to map a session info document into an SDP description. Note
that these mapping rules do not include rules for all elements
that need to be present in a session info document or in an SDP
description. That is, some of those elements are generated
following their associated general rules (e.g., the general
rules to generate SDP v= and t= lines).</t>
<t>A UA with an SDP session description that needs to create a
session info document uses the data in the session description
and maps it following the rules below. A UA with an SDP
offer/answer pair that needs to create a session info document
uses the data that has been agreed in the offer/answer exchange.</t>
<t>A UA MUST create a separate <stream> element for each
m= line in an SDP description or SDP offer/answer pair; the
order of the <stream> elements corresponds to the order of
the m= lines. For an SDP 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 the particular stream in the offer/answer exchange.
The <codec> elements MUST have 'q' attributes with values
that decrease with the order the codecs are given in the m=
line. (Other than the ordering restriction, the particular
values used are not specified by this document.)</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 SHOULD create a <remote-host-port>
element using the port and address from the m= and c= lines for
the same stream taken from the remote session description if
this session description is available. (The local SDP is the
one sent by the UA; the remote SDP is the one received from the
remote UA.)</t>
<t><list style="empty"><t>The <remote-host-port> contains
information that may be considered sensitive from a privacy
stand point. A UA configured not to disclose that information
would not include the <remote-host-port> element in its
session info documents.</t></list></t>
<t>The numeric value in a "b=CT:..." attribute in a session
description is used to set the content of a <max-bw> element
with the direction attribute value corresponding to which
SDP contains the b= attribute.</t>
<t>The numeric value in a "b=AS:..." attribute at the session
level in a session description is used to set the content of a
<max-session-bw> element with the direction attribute
value corresponding to the SDP which contains the b=
attribute.</t>
<t>The numeric value in a "b=AS:..." attribute at the media
level in a media description is used to set the content of a
<max-stream-bw> element child of the appropriate
<stream> element, with the direction attribute value
corresponding to the SDP which contains the b= attribute.</t>
<t>An "a=label:..." attribute <xref target="RFC4574"/> is used
to set the 'label' attribute of the appropriate <stream>
element.</t>
<t>The mapping from a session info document to a SDP description
follows the same rules in the reverse direction.</t>
<t>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.</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 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.</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 SHOULD insert the hostname/port of the remote
session description into the remote-host-port element, if the
remote session description is available to the UA. If not, the
UA generates a stream element that only contains the
local-host-port element. </t>
<t>This element MAY have the direction, label, and enabled
attributes (see <xref target="sec_attributes" />).</t>
<t>The 'label' attribute is used to identify a specific media
stream. The value of the label attribute is a token that is
unique among all <stream> elements in a session-info
document and whose syntax is defined in <xref
target="RFC4566"/>.</t>
<t>
The 'enabled' attribute specifies whether or not the user
agent is allowed to establish a media stream.</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 MUST contain zero or one <remote-host-port>
elements.</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 media streams through media intermediaries. The
purpose of the <media-intermediaries> element is to tell
the UA to send media streams through a chain of media
intermediaries. The manner in which the UA arranges for a
media stream to pass through the intermediaries depends on
the type of intermediary.</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 direction attribute (see <xref
target="sec_attributes" />).</t>
<t>Multiple <media-intermediaries> elements MUST NOT be
present in a container unless each applies to a different set of
streams (e.g., one <media-intermediaries> element for
incoming and one for outgoing streams). The
<media-intermediaries> element MUST contain one or more
elements defining a specific media intermediary, such as
<fixed-intermediary> or <turn-intermediary>.</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. The URIs in the
<msrp-uri> element MUST have a scheme of "msrps:".</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
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 <xref
target="mime-param"/>) allows identifying a particular
encoding or profile of the codec. Therefore, when the
<mime-parameter> element is present, what is allowed or
excluded is the particular encoding or profile. Other encodings
or profiles of the same codec are unaffected.
</t>
<t>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.</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><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>
]]></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="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.</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 SHOULD used. Values received from other policy
servers SHOULD be 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 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.</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 direction and visibility attributes
(see <xref target="sec_attributes" />).</t>
<t>Multiple <media-types-allowed> elements MUST NOT be
present in a container element unless each applies to a
different set of streams (e.g., one <media-types-allowed>
element for incoming and one for outgoing streams). The
<media-types-allowed> element MUST contain zero or more
<media-type> elements. </t>
<t>A <media-types-allowed> element MUST NOT be used in a
container that contains a <media-types-excluded>
element.</t>
<t>Merging of session-policy documents:
<media-types-allowed> containers are merged as described
in "Merging Sets" <xref target="sec_setmerge" />.</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 direction and visibility attributes
(see <xref target="sec_attributes" />).</t>
<t>Multiple <media-types-excluded> elements MUST NOT be
present in a container element unless each applies to a
different set of streams (e.g., one <media-types-excluded>
element for incoming and one for outgoing streams). The
<media-types-excluded> element MUST contain zero or more
<media-type> elements. </t>
<t>A <media-types-excluded> element MUST NOT be used in a
container that contains a <media-types-allowed>
element.</t>
<t>Merging of session-policy documents:
<media-types-excluded> containers are merged as
described in "Merging Sets" <xref target="sec_setmerge" />.</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 codecs not listed in the <codecs-allowed>
element are disallowed and MUST NOT be used in a session. A
policy MUST allow the use of at least one codec per media
type. A specific codec is allowed by adding the corresponding
<codec> element to this container.</t>
<t>The <codecs-allowed> element MAY have the direction
and visibility attributes (see <xref target="sec_attributes"
/>).</t>
<t>Multiple <codecs-allowed> elements MUST NOT be present
in a container element unless each applies to a different set of
streams (e.g., one <codecs-allowed> element for incoming
and one for outgoing streams). The <codecs-allowed>
element MUST contain zero or more <codec> elements.</t>
<t>A <codecs-allowed> element MUST NOT be used in a
container that contains a <codecs-excluded>
element.</t>
<t>Merging of session-policy documents: <codecs-allowed>
containers are merged as described in "Merging Sets"
<xref target="sec_setmerge" />.</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 codecs not listed in the <codecs-excluded>
element are permitted and MAY be used in a session. A specific
codec is disallowed by adding the corresponding <codec>
element to this container.</t>
<t>The <codecs-excluded> element MAY have the direction
and visibility attributes (see <xref target="sec_attributes"
/>).</t>
<t>Multiple <codecs-excluded> elements MUST NOT be present
in a container element unless each applies to a different set of
streams (e.g., one <codecs-excluded> element for incoming
and one for outgoing streams). The <codecs-excluded>
element MUST contain zero or more <codec> elements.</t>
<t>A <codecs-excluded> element MUST NOT be used in a
container that contains a <codecs-allowed>
element.</t>
<t>Merging of session-policy documents:
<codecs-excluded> containers are merged as described in
"Merging Sets" <xref target="sec_setmerge" />.</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 the decimal representation
of a start port number and an
end port number, separated by a "-". The start/end port numbers are the
first/last port numbers that can be used, that is, the range
is inclusive. The start/end port numbers must be in the range 1
to 65535 (inclusive).</t>
<t>As with other policy elements, there are values of the
<local-ports> element that allow no sessions. This happens
if the start port number is greater than the end port number.</t>
<t>The default value for <local-ports> is "1-65535".</t>
<t>This element MAY have the visibility attributes (see <xref
target="sec_attributes" />).</t>
<t>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.</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, as defined in Section 8.2.1 of <xref target="RFC4566"/>,
such as 'audio', 'video', 'text', or 'application'. </t>
<t>This element MAY have the q attribute (see <xref
target="sec_attributes" />).</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 q attribute (see <xref
target="sec_attributes" />).</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 <media-type-subtype>
element and MAY contain multiple optional <mime-parameter>
elements.</t>
<section title="The <media-type-subtype> Element">
<t>The <media-type-subtype> element contains a media
type and subtype that identifies a media format <xref
target="RFC4566"/> (e.g., a codec). For audio and video
streams, the value of this element MUST be a media type and
subtype that is registered as an RTP Payload Type <xref
target="RFC4855" /> separated by a "/" (e.g., audio/PCMA,
audio/G726-16 <xref target="RFC4856"/> or video/H263 <xref
target="RFC4629"/>). For other media types, SDP sometimes
encodes the actual media format as part of the transport
protocol field (e.g., TCP/MSRP <xref target="RFC4975"/> and
TCP/TLS/BFCP <xref target="RFC4583"/>). In these cases, this
element MUST contain the media type and the media format
part (e.g., message/msrp and application/bfcp). </t>
</section>
<section title="The <mime-parameter> Element"
anchor="mime-param">
<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 (i.e., 1024 bits per second) an
entity can/will use for media streams at any point in time. It
defines an upper limit for the total bandwidth an entity
can/will use for the transmission of media streams. The limit
corresponds to the sum of the maximum session bandwidth of all
sessions a UA may set up in parallel.</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 direction attribute
(see <xref target="sec_attributes" />).</t>
<t>If used in a <session-policy> element, the
<max-bw> element MAY also have the visibility
attribute (see <xref target="sec_attributes" />).</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>Merging of session-policy documents: the lowest
max-bw value MUST be used.</t>
</section>
<section title="The <max-session-bw> Element">
<t>The <max-session-bw> element defines the maximum
bandwidth in kilobits per second (i.e., 1024 bits per second) an
entity can/will use for media streams in the described
session. It defines an upper limit for the total bandwidth of a
single session. This limit corresponds to the sum of the maximum
stream bandwidth of all media streams in a session.</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 <max-session-bw> element MAY have the direction
attribute (see <xref target="sec_attributes" />).</t>
<t>If used in a <session-policy> element, the
<max-session-bw> element MAY also have the visibility
attribute (see <xref target="sec_attributes" />).</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>Merging of session-policy documents: the lowest
max-session-bw value MUST be used.</t>
</section>
<section title="The <max-stream-bw> Element">
<t>The <max-stream-bw> element defines the maximum
bandwidth in kilobits per second (i.e., 1024 bits per second) an
entity can/will use for each media stream in the described
session.</t>
<t>The bandwidth limit given in the <max-stream-bw>
element includes the bandwidth needed as encapsulated in IP
(i.e., the RTP, UDP, and IP overheads are included).</t>
<t>The <max-stream-bw> element MAY have the direction and
media-type attributes (see <xref target="sec_attributes"
/>).</t>
<t>If used in a <session-policy> element, the
<max-stream-bw> element MAY also have the visibility
attribute (see <xref target="sec_attributes" />).</t>
<t>If used in a <session-info> element, the
<max-stream-bw> element MAY also have the label
attribute.</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 (e.g., audio streams).</t>
<t>The <max-stream-bw> element is used to define a
bandwidth limit for a specific media stream. The use of this
attribute requires that the <stream> element that
represents the media stream to which this bandwidth limit
applies also has a 'label' attribute. A <max-stream-bw>
element with a 'label' attribute applies only to the stream
element that has a 'label' attribute with the same value. If no
matching <stream> element exists, then the
<max-stream-bw> element MUST be ignored.</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>Merging of session-policy documents: the lowest
max-stream-bw value MUST be used.</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 a decimal integer value that represents a 6
bit field and therefore ranges from 0 to 63.</t>
<t>This element MAY have the direction and media-type attributes
(see <xref target="sec_attributes" />)).</t>
<t>If used in a <session-policy> element, the
<qos-dscp> element MAY also have the visibility attribute
(see <xref target="sec_attributes" />).</t>
<t>The media-type attribute is used to specify that
the <qos-dscp> element only applies to streams of a certain
media type (e.g., audio streams).</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>Merging of session-policy documents: the local domain of
the user agent has precedence over other domains and its DSCP
value MUST be used. During the merging process,
<qos-dscp> element values from local policy server
selected as described in "Local Policy Server Selection" <xref
target="sec_localselect" /> are used.</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. It can also
contain optional <policy-server-URI> and
<token> elements.</t>
<t>If used in a <session-info> element, the
<context> element MAY also contain a <request-URI>
element.</t>
<t>Merging of session-policy documents: the resulting <context>
element MUST be determined by local policy.</t>
<section title="The <policy-server-URI> Element">
<t>The <policy-server-URI> element contains the URI
(including the URI scheme)of the policy server that has issued
this policy.</t>
</section>
<section title="The <contact> Element">
<t>The <contact> element contains a URI which is a contact address
(e.g., a SIP URI or mailto URI) by which a human representative of
the issuer of this document can be reached.</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 <request-URI> Element">
<t>The <request-URI> element contains the request-URI
(including the URI scheme) of the dialog-initiating request of
the session.</t>
<t>The <request-URI> element is only permitted inside
<session-info> documents and, thus, MUST NOT be
included in session policy documents.</t>
</section>
<section title="The <token> Element">
<t>The <token> element provides a mechanism for a policy
server to return an opaque string to a UA. Such a string is
sometimes needed to construct a Policy-Id header which ensures
that all policy requests concerning a single 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" />. The token
value MUST consist of ASCII characters in the range U+0020 to
U+007E (note that the token value is encodable as a SIP URI
parameter value).</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 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>
]]></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 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>
]]></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 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>
]]></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 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>
]]></artwork></figure>
</section>
</section>
</section>
<section title="Relax NG Definition" anchor="sec-schema">
<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">
<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>
]]></artwork></figure></t>
</section>
<section title="Security Considerations" anchor="sec_security">
<t>
Section 5 of <xref
target="I-D.ietf-sip-session-policy-framework"/> discusses
security aspects related to the transfer of session policy
information between user agents and policy servers, including
their authentication and the use of TLS between them. In
particular, a UA needs to check the server's certificate and only
accept policies from severs the UA is configured to accept
policies from. Section 7 of RFC 3470 <xref target="RFC3470"/>
provides general security considerations regarding the transport
of XML documents in network protocols. Session info and session
policy information can be sensitive information. The protocol used
to distribute session info and session policy documents SHOULD
ensure authentication and confidentiality, and message
integrity. The use of <xref
target="I-D.ietf-sipping-policy-package" /> to distribute session
info and session policy document meets these requirements.
</t>
<t>
An attacker could attempt to modify session policy documents that
were sent to a client so that their processing by the client would
be more costly (e.g., in terms of merging policies). The attacker
could also attempt to create its own fake policy documents and
send them to the client with the same purpose or in order to get
the client to comply with those fake policies as part of a Denial
of Service (DoS) attack. The protocol used to distribute session
policy documents SHOULD ensure authentication and privacy, and
message integrity. The use of <xref
target="I-D.ietf-sipping-policy-package" /> to distribute session
policy document meets these requirements.
</t>
<t>The <shared-secret> element can contain a shared secret
needed to authenticate at a media intermediary. The privacy of
documents containing this element MUST be preserved when they are
sent between a server and a UA. When <xref
target="I-D.ietf-sipping-policy-package" /> is used to distribute
these documents, encryption as defined in <xref target="RFC3261"/>
(i.e., TLS or S/MIME) MUST be used</t>
</section>
<section title="IANA Considerations" anchor="sec_iana">
<t>This document registers a new media type
(application/media-policy-dataset+xml), a new RLAX NG schema, 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="RELAX NG Schema Registration">
<t>
This specification registers a schema. The schema can be found
as the sole content of <xref target="sec-schema"/>.
</t>
<t>
URI: urn:ietf:params:xml:schema:mediadataset
</t>
<t>
Registrant Contact: IETF RAI area <![CDATA[<rai@ietf.com>]]>,
Volker Hilt <![CDATA[<volkerh@bell-labs.com>]]>
</t>
<t>
RELAX NG Schema: The RELAX NG schema to be registered is
contained in Section <xref target="sec-schema"/>.
</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;
&i-d.ietf-sipping-policy-package;
&w3c.REC-xml-20081126;
</references>
<references title='Informative References'>
&i-d.ietf-sip-session-policy-framework;
&rfc2648;
&rfc3470;
&rfc4583;
&rfc4629;
&rfc4856;
&rfc6080;
<!--
<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, Mary Barnes, Yaron Sheffer, Pete McCann, and
Henry S. Thompson 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 02:06:23 |