Internet DRAFT - draft-camarillo-rai-media-policy-dataset
draft-camarillo-rai-media-policy-dataset
RAI V. Hilt
Internet-Draft Bell Labs/Alcatel-Lucent
Intended status: Standards Track G. Camarillo
Expires: March 29, 2013 Ericsson
J. Rosenberg
jdrosen.net
D. Worley
Avaya Inc.
September 25, 2012
A User Agent Profile Data Set for Media Policy
draft-camarillo-rai-media-policy-dataset-04
Abstract
This specification defines an XML document format to describe the
media properties of Session Initiation Protocol (SIP) sessions.
Examples for media properties are the codecs or media types used in
the session. This document also defines an XML document format to
describe policies that limit the media properties of SIP sessions.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 29, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Hilt, et al. Expires March 29, 2013 [Page 1]
Internet-Draft Media Policy Dataset September 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Media Policy Dataset Format . . . . . . . . . . . . . . . . . 5
3.1. Namespace and Media Type . . . . . . . . . . . . . . . . . 5
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. The 'visibility' Attribute . . . . . . . . . . . . . . 6
3.3.2. The 'direction' Attributes . . . . . . . . . . . . . . 6
3.3.3. The 'q' Attribute . . . . . . . . . . . . . . . . . . 6
3.3.4. The 'media-type' Attribute . . . . . . . . . . . . . . 7
3.3.5. The 'label' Attribute . . . . . . . . . . . . . . . . 7
3.3.6. The 'enabled' Attribute . . . . . . . . . . . . . . . 7
4. Session Info Documents . . . . . . . . . . . . . . . . . . . . 7
4.1. Mapping between SDP and Session Info Documents . . . . . . 8
4.2. The <session-info> Element . . . . . . . . . . . . . . . . 10
4.3. The <streams> Element . . . . . . . . . . . . . . . . . . 10
4.3.1. The <stream> Element . . . . . . . . . . . . . . . . . 10
4.4. The <media-intermediaries> Element . . . . . . . . . . . . 11
4.4.1. The <fixed-intermediary> Element . . . . . . . . . . . 12
4.4.2. The <turn-intermediary> Element . . . . . . . . . . . 13
4.4.3. The <msrp-intermediary> Element . . . . . . . . . . . 13
5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 14
5.1. Merging Session Policies . . . . . . . . . . . . . . . . . 14
5.1.1. Single Value Selection . . . . . . . . . . . . . . . . 14
5.1.2. Merging Sets . . . . . . . . . . . . . . . . . . . . . 14
5.1.3. Local Policy Server Selection . . . . . . . . . . . . 16
5.2. The <session-policy> Element . . . . . . . . . . . . . . . 16
5.3. The <media-types-allowed> Element . . . . . . . . . . . . 16
5.4. The <media-types-excluded> Element . . . . . . . . . . . . 17
5.5. The <codecs-allowed> Element . . . . . . . . . . . . . . . 17
5.6. The <codecs-excluded> Element . . . . . . . . . . . . . . 18
5.7. The <local-ports> Element . . . . . . . . . . . . . . . . 18
6. Common Media Policy Dataset Elements . . . . . . . . . . . . . 19
6.1. The <media-type> Element . . . . . . . . . . . . . . . . . 19
6.2. The <codec> Element . . . . . . . . . . . . . . . . . . . 19
6.2.1. The <media-type-subtype> Element . . . . . . . . . . . 19
6.2.2. The <mime-parameter> Element . . . . . . . . . . . . . 20
6.3. The <max-bw> Element . . . . . . . . . . . . . . . . . . . 20
6.4. The <max-session-bw> Element . . . . . . . . . . . . . . . 20
Hilt, et al. Expires March 29, 2013 [Page 2]
Internet-Draft Media Policy Dataset September 2012
6.5. The <max-stream-bw> Element . . . . . . . . . . . . . . . 21
6.6. The <qos-dscp> Element . . . . . . . . . . . . . . . . . . 22
6.7. The <context> Element . . . . . . . . . . . . . . . . . . 22
6.7.1. The <policy-server-URI> Element . . . . . . . . . . . 23
6.7.2. The <contact> Element . . . . . . . . . . . . . . . . 23
6.7.3. The <info> Element . . . . . . . . . . . . . . . . . . 23
6.7.4. The <request-URI> Element . . . . . . . . . . . . . . 23
6.7.5. The <token> Element . . . . . . . . . . . . . . . . . 23
6.8. Other Session Properties . . . . . . . . . . . . . . . . . 23
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Session Policy Documents . . . . . . . . . . . . . . . . . 24
7.2. Session Information Documents . . . . . . . . . . . . . . 24
7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 24
7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 25
8. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10.1. Media Type Registration . . . . . . . . . . . . . . . . . 38
10.2. RELAX NG Schema Registration . . . . . . . . . . . . . . . 38
10.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Hilt, et al. Expires March 29, 2013 [Page 3]
Internet-Draft Media Policy Dataset September 2012
1. Introduction
The Framework for Session Initiation Protocol (SIP) [RFC3261] User
Agent Profile Delivery [RFC6080] and the Framework for SIP Session
Policies [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.
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.
If used with the Framework for SIP Session Policies
[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.
The two types of MPDF documents, session information and session
policy documents, share the same set of XML elements to describe
session properties. Since these elements are used in different
contexts for session info and session policy documents, two different
root elements exist for the two document types: <session-info> is the
root element for session information documents and <session-policy>
is the root element for session policy documents.
A user agent can receive multiple session policy documents from
different sources. This can lead to a situation in which the user
agent needs to apply multiple session policy documents to the same
session. This standard specifies merging rules for those XML
elements that can be present in session policy documents. It should
Hilt, et al. Expires March 29, 2013 [Page 4]
Internet-Draft Media Policy Dataset September 2012
be noted that these merging rules are part of the semantics of a
session policy XML element. User agents implement the merging rules
as part of implementing the element semantics. As a consequence, it
is not possible to build an entity that can mechanically merge two
session policy documents without understanding the semantics of all
elements in the input documents.
Merging rules are not needed for elements of session information
documents since they are created by one source and describe a
specific session.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Media Policy Dataset Format
This section discusses fundamental properties of the Media Policy
Dataset Format (MPDF).
3.1. Namespace and Media Type
The MPDF format is based on XML [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.
MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The
namespace URIs for elements defined in this specification are URNs
[RFC2141], using the namespace identifier 'ietf' defined by [RFC2648]
and extended by [RFC3688]. The namespace URN for the MPDF schema is:
urn:ietf:params:xml:ns:mediadataset
The media type for the Media Policy Dataset Format is:
application/media-policy-dataset+xml
3.2. Extensibility
The MPDF format can be extended using XML extension mechanisms if
additional media properties are needed. In particular, elements from
different XML namespaces MAY be present within a MPDF document for
Hilt, et al. Expires March 29, 2013 [Page 5]
Internet-Draft Media Policy Dataset September 2012
the purposes of extensibility; elements or attributes from unknown
namespaces MUST be ignored.
3.3. Attributes
The following attributes can be used with elements of the MPDF
format. The specification of each MPDF element lists which of these
attributes can be used. If an element bears an attribute which may
not be used with it, the user agent MUST ignore the attribute.
3.3.1. The 'visibility' Attribute
The attribute 'visibility' specifies whether or not the user agent is
advised to display the property value to the user. This is used to
hide setting values that the administrator may not want the user to
see or know. The 'visibility' attribute has two possible values:
o visible: specifies that display of the property value is not
restricted. This is the default value of the attribute if it is
not specified.
o hidden: Specifies that the user agent is 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.
3.3.2. The 'direction' Attributes
Some properties are unidirectional and only apply to messages or data
streams transmitted into one direction. For example, a property for
media streams can be restricted to outgoing media streams only.
Unidirectional properties can be expressed by adding a 'direction'
attribute to the respective element.
The 'direction' attribute can have the following values:
o recvonly: the property only applies to incoming streams.
o sendonly: the property only applies to outgoing streams.
o sendrecv: the property applies to streams in both directions.
This is the default value that is used if the 'direction'
attribute is omitted.
3.3.3. The 'q' Attribute
It is possible to express a preference for a certain value relative
to the other values within a set of multiple values that are allowed
within a property. For example, it is possible to express that the
codecs G.711 and G.729 are allowed, but G.711 is preferred.
Preferences are be expressed by adding a 'q' attribute to a property
Hilt, et al. Expires March 29, 2013 [Page 6]
Internet-Draft Media Policy Dataset September 2012
element. The 'q' attribute is only allowed in elements that specify
allowed values (as opposed to elements that specify forbidden
values).
The value of the 'q' attribute is a decimal number within the range 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.
3.3.4. The 'media-type' Attribute
The media-type attribute is used to define that an element only
applies to streams of a certain media type, as defined in Section
8.2.1 of [RFC4566]. For example, it may only apply to audio streams.
The value of the 'media-type' attribute MUST be the media type, such
as 'audio', 'video', 'text', or 'application'.
3.3.5. The 'label' Attribute
The label attribute is used to identify a specific media stream. The
value of the label attribute is a token, whose syntax is defined in
[RFC4566]. The token can be chosen freely, however, it MUST be
unique among all <stream> elements in a session-info document.
3.3.6. The 'enabled' Attribute
The 'enabled' attribute specifies whether or not the user agent is
allowed to establish a media stream. This boolean attribute has two
possible values:
o yes: specifies that the media stream can be established. This is
the default value of the attribute if it is not specified.
o no: specifies that the user agent MUST NOT establish the media
stream.
4. Session Info Documents
Session info documents describe key properties of a SIP session such
as the media streams used in the session. Session info documents are
typically created based on an SDP [RFC4566] session description or an
SDP offer/answer pair [RFC3264].
Session info documents can be used for session-specific policies
[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
Hilt, et al. Expires March 29, 2013 [Page 7]
Internet-Draft Media Policy Dataset September 2012
compliant to the policies. For example, if video streams are not
permissible under current policies and the UA submits a session info
document that contains a video stream, the policy server will disable
(i.e., enabled="no") the video stream in the session info document
that it returns to the UA.
Session info documents use the <session-info> root element. They use
elements described in this section and common elements described in
Section 6.
Elements that are only present in session info documents do not
require merging rules. If used in the context of session-specific
policies, session info documents are sent to one policy server at a
time only, therefore a UA does not need to merge multiple session
info documents into one. A policy server needs to modify a session
info document it has received according to its policies. The
modification of session info documents is determined by the local
policies of the policy server and is, thus, outside the scope of this
standard.
A policy server can completely reject a session by returning an
session info document with an empty <session-info> element:
<session-info></session-info>
4.1. Mapping between SDP and Session Info Documents
This section specifies how to map information in an SDP session
description or an SDP offer/answer pair [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).
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.
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
Hilt, et al. Expires March 29, 2013 [Page 8]
Internet-Draft Media Policy Dataset September 2012
MUST insert a <codec> element for each of the codecs that were agreed
upon for the particular stream in the offer/answer exchange. The
<codec> elements MUST have 'q' attributes with values that decrease
with the order the codecs are given in the m= line. (Other than the
ordering restriction, the particular values used are not specified by
this document.)
The UA MUST create a <local-host-port> element for each stream using
the port taken from the m= line and the address from the
corresponding c= line of the local session description. The UA
SHOULD create a <remote-host-port> element using the port and address
from the m= and c= lines for the same stream taken from the remote
session description if this session description is available. (The
local SDP is the one sent by the UA; the remote SDP is the one
received from the remote UA.)
The <remote-host-port> contains information that may be considered
sensitive from a privacy stand point. A UA configured not to
disclose that information would not include the <remote-host-port>
element in its session info documents.
The numeric value in a "b=CT:..." attribute in a session description
is used to set the content of a <max-bw> element with the direction
attribute value corresponding to which SDP contains the b= attribute.
The numeric value in a "b=AS:..." attribute at the session level in a
session description is used to set the content of a <max-session-bw>
element with the direction attribute value corresponding to the SDP
which contains the b= attribute.
The numeric value in a "b=AS:..." attribute at the media level in a
media description is used to set the content of a <max-stream-bw>
element child of the appropriate <stream> element, with the direction
attribute value corresponding to the SDP which contains the b=
attribute.
An "a=label:..." attribute [RFC4574] is used to set the 'label'
attribute of the appropriate <stream> element.
The mapping from a session info document to a SDP description follows
the same rules in the reverse direction.
For any particular m= line, the codecs MUST be listed in decreasing
order of the values of the 'q' attributes of the corresponding
<codec> elements.
Hilt, et al. Expires March 29, 2013 [Page 9]
Internet-Draft Media Policy Dataset September 2012
4.2. The <session-info> Element
The <session-info> element describes the properties of a specific SIP
session. The <session-info> element MAY contain the optional
<context> and <streams> elements, and multiple (including zero)
<max-bw>, <max-session-bw>, <max-stream-bw>, <media-intermediaries>
and <qos-dscp> elements, as well as elements from other namespaces.
4.3. The <streams> Element
The <streams> element is a container that is used to describe the
media streams used in a session. A <streams> element contains zero
or more <stream> elements. Each <stream> element describes the
properties (e.g., media type, codecs and IP addresses and ports) of a
single media stream.
4.3.1. The <stream> Element
The <stream> element describes a specific media stream. It contains
the media type, codecs and the hostname(s) or IP address(es) and
port(s) of this stream.
The hostname(s) or IP address(es) and port number(s) of a stream
correspond to the ones listed in the session description(s). A UA
that generates a <stream> element MUST insert the hostname/port found
in the local session description for this media stream into the
local-host-port element. The UA SHOULD insert the hostname/port of
the remote session description into the remote-host-port element, if
the remote session description is available to the UA. If not, the
UA generates a stream element that only contains the local-host-port
element.
This element MAY have the direction, label, and enabled attributes
(see Section 3.3).
The 'label' attribute is used to identify a specific media stream.
The value of the label attribute is a token that is unique among all
<stream> elements in a session-info document and whose syntax is
defined in [RFC4566].
The 'enabled' attribute specifies whether or not the user agent is
allowed to establish a media stream.
The <stream> element MUST contain one <media-type> element, one or
more <codec> elements and one <local-host-port> element. The
<stream> element MUST contain zero or one <remote-host-port>
elements.
Hilt, et al. Expires March 29, 2013 [Page 10]
Internet-Draft Media Policy Dataset September 2012
4.3.1.1. The <local-host-port> Element
The <local-host-port> element contains the hostname or IP address and
the receiving port number of the media stream in the local session
description. The hostname or IP address is separated from the port
by a ":". An example is: "host.example.com:49562".
The hostname or IP address of element is found in the c= element for
the stream in the local SDP description. The port number is found in
the m= element.
4.3.1.2. The <remote-host-port> Element
The <remote-host-port> element is structured exactly as the <local-
host-port> element. However, it identifies the hostname or IP
address and receiving port number of the media stream in the remote
session description.
4.4. The <media-intermediaries> Element
The <media-intermediaries> element expresses a policy for routing
media streams through media intermediaries. The purpose of the
<media-intermediaries> element is to tell the UA to send media
streams through a chain of media intermediaries. The manner in which
the UA arranges for a media stream to pass through the intermediaries
depends on the type of intermediary.
The <media-intermediaries> element is a container that lists all
media intermediaries to be traversed. Media intermediaries should be
traversed in the order in which they appear in this list. The
topmost entry should be traversed first, the last entry should be
traversed last.
Different types of intermediaries exist. These intermediaries are
not necessarily interoperable and it may not be possible to chain
them in an arbitrary order. A <media-intermediaries> element SHOULD
therefore only contain intermediary elements of the same type.
This element MAY have the direction attribute (see Section 3.3).
Multiple <media-intermediaries> elements MUST NOT be present in a
container unless each applies to a different set of streams (e.g.,
one <media-intermediaries> element for incoming and one for outgoing
streams). The <media-intermediaries> element MUST contain one or
more elements defining a specific media intermediary, such as <fixed-
intermediary> or <turn-intermediary>.
Hilt, et al. Expires March 29, 2013 [Page 11]
Internet-Draft Media Policy Dataset September 2012
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.
4.4.1. The <fixed-intermediary> Element
A fixed intermediary relies on pre-configured forwarding rules. The
user agent simply sends media to the first media intermediary listed.
It can assume that this media intermediary has been pre-configured
with a forwarding rule for the media stream and knows where to
forward the packets to. The configuration of forwarding rules in the
intermediary must be done through other means.
The contents of a <fixed-intermediary> element MUST be echoed to all
policy servers that provide policies for a session. 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
[I-D.ietf-sip-session-policy-framework] in section Contacting the
Policy Server.
The <fixed-intermediary> element MUST contain one <int-host-port>
element and MAY contain multiple optional <int-addl-port> elements.
4.4.1.1. The <int-host-port> Element
The <int-host-port> element contains the hostname or IP address and
port number of a media intermediary. The UA uses this hostname/IP
address and port to send its media streams to the intermediary. The
hostname or IP address is separated from the port by a ":".
If a protocol uses multiple subsequent ports (e.g., RTP), the lowest
port number SHOULD be included in the <int-host-port> element. All
additional port numbers SHOULD be identified in <int-addl-port>
elements.
4.4.1.2. The <int-addl-port> Element
If a protocol uses multiple subsequent ports (e.g., RTP), the lowest
port number SHOULD be included in the <int-host-port> element. All
additional port numbers SHOULD be identified in <int-addl-port>
elements.
Hilt, et al. Expires March 29, 2013 [Page 12]
Internet-Draft Media Policy Dataset September 2012
4.4.2. The <turn-intermediary> Element
The TURN [RFC5766] protocol provides a mechanism for inserting a
relay into the media path. Although the main purpose of TURN is NAT
traversal, it is possible for a TURN relay to perform other media
intermediary functionalities. The user agent establishes a binding
on the TURN server and uses this binding to transmit and receive
media.
The <turn-intermediary> element MUST contain one <int-host-port>
element and MAY contain multiple optional <int-addl-port> elements
and zero or one each of the <shared-secret>, <user>, and <transport>
elements. If no <transport> element is present, UDP is assumed.
4.4.2.1. The <shared-secret> Element
The <shared-secret> element contains the shared secret needed to
authenticate at the media intermediary.
4.4.2.2. The <user> element
The <user> element contains the user ID needed to authenticate to the
media intermediary.
4.4.2.3. The <transport> Element
The <transport> element contains the name of the transport to be used
for communicating with the TURN server. This document defines the
values "tcp" and "udp" for use in the <transport> element. Other
specifications may define additional values.
4.4.3. The <msrp-intermediary> Element
The MSRP Relay Extensions [RFC4976] define a means for incorporating
relays into the media path of an MSRP [RFC4975] session. MSRP is
explicitly designed for a variety of purposes, including policy
enforcement.
The <msrp-intermediary> element MUST contain one <msrp-uri> element,
and may contain zero or one each of the <shared-secret> and <user>
elements.
4.4.3.1. The <msrp-uri> Element
The <msrp-uri> element contains a URI that indicates the MSRP server
to use for an intermediary. The UA uses this URI to authenticate
with the MSRP relay, and then uses the URI it learns through that
authentication process for any MSRP media it sends or receives. The
Hilt, et al. Expires March 29, 2013 [Page 13]
Internet-Draft Media Policy Dataset September 2012
URIs in the <msrp-uri> element MUST have a scheme of "msrps:".
5. Session Policy Documents
Session policy documents describe policies for SIP sessions. Session
policy documents are independent of any specific session description
and express general policies for SIP sessions. A session policy
document is used to determine if a SIP session is policy conformant
and can be used to modify the session, if needed, to conform to the
described policies.
Session policy documents can be used to encode session-independent
policies [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.
Session policy documents use the <session-policy> root element. They
use elements described in this section and common elements described
in Section 6.
5.1. Merging Session Policies
A UA may receive session policy documents from multiple sources;
multiple session policy documents can be merged into a single session
policy document which expresses the logical AND of the policies.
5.1.1. Single Value Selection
Properties that have a single value (e.g., the maximum bandwidth
allowed) require that a common value 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).
5.1.2. Merging Sets
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 Section 6.2.2) allows identifying a particular encoding
or profile of the codec. Therefore, when the <mime-parameter>
Hilt, et al. Expires March 29, 2013 [Page 14]
Internet-Draft Media Policy Dataset September 2012
element is present, what is allowed or excluded is the particular
encoding or profile. Other encodings or profiles of the same codec
are unaffected.
To merge the media-types-* and codecs-* containers a UA MUST apply
all containers it has received one after the other to the set of
media-types/codecs it supports. After applying media-types-*/
codecs-* elements, the UA has the list of media-types/codecs that are
allowed in a session. The containers MAY be applied in any order.
However, each time a container is applied to the set of media-types/
codecs allowed, this set MUST stay the same or be reduced. Media-
types/codecs cannot be added during this process.
The following example illustrates the merging process for two data
sets. In this example, the UA supports the following set of audio
codecs: PCMA, PCMU and G729. After applying session policy document
1, the UA removes PCMA as it is disallowed by this policy. The
remaining set of codecs is: PCMU and G729. Session policy document 2
disallows all codecs that are not listed. After applying this
policy, the set of codecs allowed is: G729.
Session Policy Document 1:
<codecs-excluded>
<codec><media-type-subtype>audio/PCMA</media-type-subtype></codec>
</codecs-excluded>
Session Policy Document 2:
<codecs-allowed>
<codec><media-type-subtype>audio/PCMA</media-type-subtype></codec>
<codec><media-type-subtype>audio/G729</media-type-subtype></codec>
</codecs-allowed>
It is possible that two session policy documents define non-
overlapping sets of allowed media-types or codecs. The resulting
merged set would be empty, which is illegal according to the schema
definition of the media-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.
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.
Hilt, et al. Expires March 29, 2013 [Page 15]
Internet-Draft Media Policy Dataset September 2012
5.1.3. Local Policy Server Selection
Some properties require that only values from the local policy server
are used. The local policy server is the policy server that is in
the local domain of the user agent.
If policy documents are delivered through the configuration framework
[RFC6080], the value received through a subscription using the
"local-network" profile-type SHOULD used. Values received through
other profile-type subscriptions SHOULD be discarded.
If policy documents are delivered through the session-specific policy
mechanism [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.
5.2. The <session-policy> Element
The <session-policy> element describes a policy that applies to SIP
sessions. The <session-policy> element MAY contain the optional
<context> and <local-ports> elements and multiple (including zero)
<media-types-allowed>, <media-types-excluded>, <codecs-allowed>,
<codecs-excluded>, <max-bw>, <max-session-bw>, <max-stream-bw> and
<qos-dscp> elements as well as elements from other namespaces.
5.3. The <media-types-allowed> Element
The <media-types-allowed> element is a container that is used to
define the set of media types (e.g., audio, video) that are allowed
in a session. All media types that are not listed in this container
are not permitted in a session. A specific media type is allowed by
adding the corresponding <media-type> element to this container.
This element MAY have the direction and visibility attributes (see
Section 3.3).
Multiple <media-types-allowed> elements MUST NOT be present in a
container element unless each applies to a different set of streams
(e.g., one <media-types-allowed> element for incoming and one for
outgoing streams). The <media-types-allowed> element MUST contain
zero or more <media-type> elements.
A <media-types-allowed> element MUST NOT be used in a container that
contains a <media-types-excluded> element.
Merging of session-policy documents: <media-types-allowed> containers
are merged as described in "Merging Sets" Section 5.1.2.
Hilt, et al. Expires March 29, 2013 [Page 16]
Internet-Draft Media Policy Dataset September 2012
5.4. The <media-types-excluded> Element
The <media-types-excluded> element is a container that is used to
define the set of media types (e.g., audio, video) that are not
permitted in a session. All media types that are not listed in this
container are allowed and can be used in a session. A specific media
type is excluded from a session by adding the corresponding <media-
type> element to this container.
This element MAY have the direction and visibility attributes (see
Section 3.3).
Multiple <media-types-excluded> elements MUST NOT be present in a
container element unless each applies to a different set of streams
(e.g., one <media-types-excluded> element for incoming and one for
outgoing streams). The <media-types-excluded> element MUST contain
zero or more <media-type> elements.
A <media-types-excluded> element MUST NOT be used in a container that
contains a <media-types-allowed> element.
Merging of session-policy documents: <media-types-excluded>
containers are merged as described in "Merging Sets" Section 5.1.2.
5.5. The <codecs-allowed> Element
The <codecs-allowed> element is a container that is used to define
the set of codecs that may be used in a session. All codecs not
listed in the <codecs-allowed> element are disallowed and MUST NOT be
used in a session. A policy MUST allow the use of at least one codec
per media type. A specific codec is allowed by adding the
corresponding <codec> element to this container.
The <codecs-allowed> element MAY have the direction and visibility
attributes (see Section 3.3).
Multiple <codecs-allowed> elements MUST NOT be present in a container
element unless each applies to a different set of streams (e.g., one
<codecs-allowed> element for incoming and one for outgoing streams).
The <codecs-allowed> element MUST contain zero or more <codec>
elements.
A <codecs-allowed> element MUST NOT be used in a container that
contains a <codecs-excluded> element.
Merging of session-policy documents: <codecs-allowed> containers are
merged as described in "Merging Sets" Section 5.1.2.
Hilt, et al. Expires March 29, 2013 [Page 17]
Internet-Draft Media Policy Dataset September 2012
5.6. The <codecs-excluded> Element
The <codecs-excluded> element is a container that is used to define
the set of codecs that are disallowed in a session. All codecs not
listed in the <codecs-excluded> element are permitted and MAY be used
in a session. A specific codec is disallowed by adding the
corresponding <codec> element to this container.
The <codecs-excluded> element MAY have the direction and visibility
attributes (see Section 3.3).
Multiple <codecs-excluded> elements MUST NOT be present in a
container element unless each applies to a different set of streams
(e.g., one <codecs-excluded> element for incoming and one for
outgoing streams). The <codecs-excluded> element MUST contain zero
or more <codec> elements.
A <codecs-excluded> element MUST NOT be used in a container that
contains a <codecs-allowed> element.
Merging of session-policy documents: <codecs-excluded> containers are
merged as described in "Merging Sets" Section 5.1.2.
5.7. The <local-ports> Element
Domains often require that a user agent only uses ports in a certain
range for media streams. The <local-ports> element defines a policy
for the ports a user agent can use for media. The value of this
element consists of the decimal representation of a start port number
and an end port number, separated by a "-". 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).
As with other policy elements, there are values of the <local-ports>
element that allow no sessions. This happens if the start port
number is greater than the end port number.
The default value for <local-ports> is "1-65535".
This element MAY have the visibility attributes (see Section 3.3).
Merging of session-policy documents: the permitted ranges specified
by the two policies are set-intersected. If the resulting set is
empty, the resulting <local-ports> element value MUST be any allowed
value with a start port number greater than the end port number.
Hilt, et al. Expires March 29, 2013 [Page 18]
Internet-Draft Media Policy Dataset September 2012
6. Common Media Policy Dataset Elements
This section describes common XML elements that are used in session
info and session policy documents to encode the media properties of
SIP sessions.
6.1. The <media-type> Element
The <media-type> element identifies a specific media type. The value
of this element MUST be the name of a media type, as defined in
Section 8.2.1 of [RFC4566], such as 'audio', 'video', 'text', or
'application'.
This element MAY have the q attribute (see Section 3.3).
If used in a session policy document inside a <media-types-allowed>
element, the media types defined MAY be used in a session. If used
in a session policy document inside a <media-types-excluded> element,
the media types defined MUST NOT be used in a session.
6.2. The <codec> Element
The <codec> element identifies a specific codec. The content of this
element MUST be a media type and subtype (e.g., audio/PCMA [RFC4856]
or video/H263 [RFC4629]), possibly with parameters.
The <codec> element MAY have the q attribute (see Section 3.3).
If used in a session policy document inside a <codecs-allowed>
element, the codec defined MAY be used in a session. If used in a
session policy document inside a <codecs-excluded> element, the codec
defined MUST NOT be used in a session.
The <codec> element MUST contain one <media-type-subtype> element and
MAY contain multiple optional <mime-parameter> elements.
6.2.1. The <media-type-subtype> Element
The <media-type-subtype> element contains a media type and subtype
that identifies a media format [RFC4566] (e.g., a codec). For audio
and video streams, the value of this element MUST be a media type and
subtype that is registered as an RTP Payload Type [RFC4855] separated
by a "/" (e.g., audio/PCMA, audio/G726-16 [RFC4856] or video/H263
[RFC4629]). For other media types, SDP sometimes encodes the actual
media format as part of the transport protocol field (e.g., TCP/MSRP
[RFC4975] and TCP/TLS/BFCP [RFC4583]). In these cases, this element
MUST contain the media type and the media format part (e.g., message/
msrp and application/bfcp).
Hilt, et al. Expires March 29, 2013 [Page 19]
Internet-Draft Media Policy Dataset September 2012
6.2.2. The <mime-parameter> Element
The <mime-parameter> element may be needed for some codecs to
identify a particular encoding or profile. The value of this element
MUST be a name-value pair containing the name and the value of a
media type parameter for the codec [RFC4855]. The name and value are
separated by a "=". For example, the parameter "profile=0" can be
used to specify a specific profile for the codec "video/H263-2000"
[RFC4629].
6.3. The <max-bw> Element
The <max-bw> element defines the overall maximum bandwidth in
kilobits per second (i.e., 1024 bits per second) an entity can/will
use for media streams at any point in time. It defines an upper
limit for the total bandwidth an entity can/will use for the
transmission of media streams. The limit corresponds to the sum of
the maximum session bandwidth of all sessions a UA may set up in
parallel.
The bandwidth limit given in the <max-bw> element includes the
bandwidth needed for lower-layer transport and network protocols
(e.g., UDP and IP).
The <max-bw> element MAY have the direction attribute (see
Section 3.3).
If used in a <session-policy> element, the <max-bw> element MAY also
have the visibility attribute (see Section 3.3).
If the <max-bw> element occurs multiple times in a container element,
each instance MUST apply to a different set of media streams (i.e.,
one <max-bw> element for outgoing and one for incoming streams).
Merging of session-policy documents: the lowest max-bw value MUST be
used.
6.4. The <max-session-bw> Element
The <max-session-bw> element defines the maximum bandwidth in
kilobits per second (i.e., 1024 bits per second) an entity can/will
use for media streams in the described session. It defines an upper
limit for the total bandwidth of a single session. This limit
corresponds to the sum of the maximum stream bandwidth of all media
streams in a session.
The bandwidth limit given in the <max-session-bw> element includes
the bandwidth needed for lower-layer transport and network protocols
Hilt, et al. Expires March 29, 2013 [Page 20]
Internet-Draft Media Policy Dataset September 2012
(e.g., UDP and IP).
The <max-session-bw> element MAY have the direction attribute (see
Section 3.3).
If used in a <session-policy> element, the <max-session-bw> element
MAY also have the visibility attribute (see Section 3.3).
If the <max-session-bw> element occurs multiple times in a container
element, each instance MUST apply to a different set of media streams
(i.e., one <max-session-bw> element for outgoing and one for incoming
streams).
Merging of session-policy documents: the lowest max-session-bw value
MUST be used.
6.5. The <max-stream-bw> Element
The <max-stream-bw> element defines the maximum bandwidth in kilobits
per second (i.e., 1024 bits per second) an entity can/will use for
each media stream in the described session.
The bandwidth limit given in the <max-stream-bw> element includes the
bandwidth needed as encapsulated in IP (i.e., the RTP, UDP, and IP
overheads are included).
The <max-stream-bw> element MAY have the direction and media-type
attributes (see Section 3.3).
If used in a <session-policy> element, the <max-stream-bw> element
MAY also have the visibility attribute (see Section 3.3).
If used in a <session-info> element, the <max-stream-bw> element MAY
also have the label attribute.
The media-type attribute is used to define that the <max-stream-bw>
element only applies to streams of a certain media type (e.g., audio
streams).
The <max-stream-bw> element is used to define a bandwidth limit for a
specific media stream. The use of this attribute requires that the
<stream> element that represents the media stream to which this
bandwidth limit applies also has a 'label' attribute. A
<max-stream-bw> element with a 'label' attribute applies only to the
stream element that has a 'label' attribute with the same value. If
no matching <stream> element exists, then the <max-stream-bw> element
MUST be ignored.
Hilt, et al. Expires March 29, 2013 [Page 21]
Internet-Draft Media Policy Dataset September 2012
If the <max-stream-bw> element occurs multiple times in a container
element, each instance MUST apply to a different set of media streams
(i.e., one <max-stream-bw> element for outgoing and one for incoming
streams).
Merging of session-policy documents: the lowest max-stream-bw value
MUST be used.
6.6. The <qos-dscp> Element
The <qos-dscp> element contains an Differentiated Services Codepoint
(DSCP) [RFC2474] value that should be used to populate the IP DS
field of media packets. The <qos-dscp> contains a decimal integer
value that represents a 6 bit field and therefore ranges from 0 to
63.
This element MAY have the direction and media-type attributes (see
Section 3.3)).
If used in a <session-policy> element, the <qos-dscp> element MAY
also have the visibility attribute (see Section 3.3).
The media-type attribute is used to specify that the <qos-dscp>
element only applies to streams of a certain media type (e.g., audio
streams).
The <qos-dscp> element is optional and MAY occur multiple times
inside a container. If the <qos-dscp> element occurs multiple times,
each instance MUST apply to a different media stream (i.e., one <qos-
dscp> element for audio and one for video streams).
Merging of session-policy documents: the local domain of the user
agent has precedence over other domains and its DSCP value MUST be
used. During the merging process, <qos-dscp> element values from
local policy server selected as described in "Local Policy Server
Selection" Section 5.1.3 are used.
6.7. The <context> Element
The <context> element provides context information about a session
policy or session information document.
The <context> element MAY contain multiple <contact> and one <info>
element. It can also contain optional <policy-server-URI> and
<token> elements.
If used in a <session-info> element, the <context> element MAY also
contain a <request-URI> element.
Hilt, et al. Expires March 29, 2013 [Page 22]
Internet-Draft Media Policy Dataset September 2012
Merging of session-policy documents: the resulting <context> element
MUST be determined by local policy.
6.7.1. The <policy-server-URI> Element
The <policy-server-URI> element contains the URI (including the URI
scheme)of the policy server that has issued this policy.
6.7.2. The <contact> Element
The <contact> element contains a URI 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.
6.7.3. The <info> Element
The <info> element provides a short textual description of the policy
or session that should be intelligible to the human user.
6.7.4. The <request-URI> Element
The <request-URI> element contains the request-URI (including the URI
scheme) of the dialog-initiating request of the session.
The <request-URI> element is only permitted inside <session-info>
documents and, thus, MUST NOT be included in session policy
documents.
6.7.5. The <token> Element
The <token> element provides a mechanism for a policy server to
return an opaque string to a UA. Such a string is sometimes needed
to construct a Policy-Id header 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 [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).
6.8. Other Session Properties
A number of additional elements have been proposed for a media
property language. These elements are deemed to be outside the scope
of this format. However, they may be defined in extensions of MPDF
or other profile data sets.
Hilt, et al. Expires March 29, 2013 [Page 23]
Internet-Draft Media Policy Dataset September 2012
o maximum number of streams
o maximum number of sessions
o maximum number of streams per session
o external address and port
o media transport protocol
o outbound proxy
o SIP methods
o SIP option tags
o SIP transport protocol
o body disposition
o body format
o body encryption
7. Examples
7.1. Session Policy Documents
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.
<session-policy xmlns="urn:ietf:params:xml:ns:mediadataset">
<context>
<policy-server-URI>sips:policy@biloxi.example.com</policy-server-URI>
<contact>sip:policy_manager@example.com</contact>
<info>Access network policies</info>
</context>
<media-types-allowed>
<media-type>audio</media-type>
<media-type>video</media-type>
</media-types-allowed>
<codecs-excluded>
<codec><media-type-subtype>audio/G729</media-type-subtype></codec>
<codec><media-type-subtype>audio/G723</media-type-subtype></codec>
</codecs-excluded>
</session-policy>
7.2. Session Information Documents
The following examples contain session descriptions and the session
information documents that represent these sessions.
7.2.1. Example 1
In this example, a session info document is created based on one
session description. This session info document would be created,
Hilt, et al. Expires March 29, 2013 [Page 24]
Internet-Draft Media Policy Dataset September 2012
for example, by a UA that has composed an offer and is now contacting
a policy server.
Local SDP session description:
v=0
o=alice 2890844526 2890844526 IN IP4 host.somewhere.example
s=
c=IN IP4 host.somewhere.example
t=0 0
m=audio 49562 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
m=video 51234 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
MPDF document:
<session-info xmlns="urn:ietf:params:xml:ns:mediadataset">
<context>
<contact>sip:alice@somewhere.example</contact>
<info>session information</info>
</context>
<streams>
<stream>
<media-type>audio</media-type>
<codec q="1.0"><media-type-subtype>audio/PCMU</media-type-subtype></codec>
<codec q="0.9"><media-type-subtype>audio/1016</media-type-subtype></codec>
<codec q="0.8"><media-type-subtype>audio/GSM</media-type-subtype></codec>
<local-host-port>host.somewhere.example:49562</local-host-port>
</stream>
<stream>
<media-type>video</media-type>
<codec q="1.0"><media-type-subtype>video/H261</media-type-subtype></codec>
<codec q="0.9"><media-type-subtype>video/H263</media-type-subtype></codec>
<local-host-port>host.somewhere.example:51234</local-host-port>
</stream>
</streams>
</session-info>
7.2.2. Example 2
In this example, a session info document is created that represents
two session descriptions (i.e., an offer and answer). This session
info document would be created, for example, by a UA that has
received an answer from another UA and is now contacting a policy
Hilt, et al. Expires March 29, 2013 [Page 25]
Internet-Draft Media Policy Dataset September 2012
server.
Local SDP session description:
v=0
o=alice 2890844526 2890844526 IN IP4 host.somewhere.example
s=
c=IN IP4 host.somewhere.example
t=0 0
m=audio 49562 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
m=video 51234 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
Remote SDP session description:
v=0
o=bob 2890844730 2890844730 IN IP4 host.anywhere.example
s=
c=IN IP4 host.anywhere.example
t=0 0
m=audio 52124 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
m=video 50286 RTP/AVP 31
a=rtpmap:31 H261/90000
MPDF document that represents the local and the remote session
description:
Hilt, et al. Expires March 29, 2013 [Page 26]
Internet-Draft Media Policy Dataset September 2012
<session-info xmlns="urn:ietf:params:xml:ns:mediadataset">
<context>
<contact>sip:alice@somewhere.example</contact>
<info>session information</info>
</context>
<streams>
<stream>
<media-type>audio</media-type>
<codec q="1.0"><media-type-subtype>audio/PCMU</media-type-subtype></codec>
<codec q="0.9"><media-type-subtype>audio/GSM</media-type-subtype></codec>
<local-host-port>host.somewhere.example:49562</local-host-port>
<remote-host-port>host.anywhere.example:52124</remote-host-port>
</stream>
<stream>
<media-type>video</media-type>
<codec q="1.0"><media-type-subtype>video/H261</media-type-subtype></codec>
<local-host-port>host.somewhere.example:51234</local-host-port>
<remote-host-port>host.anywhere.example:50286</remote-host-port>
</stream>
</streams>
</session-info>
The 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.
Hilt, et al. Expires March 29, 2013 [Page 27]
Internet-Draft Media Policy Dataset September 2012
<session-info xmlns="urn:ietf:params:xml:ns:mediadataset">
<context>
<contact>sip:alice@somewhere.example</contact>
<info>modified session information</info>
</context>
<streams>
<stream label='1'>
<media-type>audio</media-type>
<codec q="1.0"><media-type-subtype>audio/PCMU</media-type-subtype></codec>
<codec q="0.9"><media-type-subtype>audio/GSM</media-type-subtype></codec>
<local-host-port>host.somewhere.example:49562</local-host-port>
<remote-host-port>host.anywhere.example:52124</remote-host-port>
</stream>
<stream label='2'>
<media-type>video</media-type>
<codec q="1.0"><media-type-subtype>video/H261</media-type-subtype></codec>
<local-host-port>host.somewhere.example:51234</local-host-port>
<remote-host-port>host.anywhere.example:50286</remote-host-port>
</stream>
</streams>
<max-stream-bw label='2'>128</max-stream-bw>
<max-session-bw>192</max-session-bw>
</session-info>
8. Relax NG Definition
<?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"/>
Hilt, et al. Expires March 29, 2013 [Page 28]
Internet-Draft Media Policy Dataset September 2012
</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>
Hilt, et al. Expires March 29, 2013 [Page 29]
Internet-Draft Media Policy Dataset September 2012
</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>
Hilt, et al. Expires March 29, 2013 [Page 30]
Internet-Draft Media Policy Dataset September 2012
<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"/>
Hilt, et al. Expires March 29, 2013 [Page 31]
Internet-Draft Media Policy Dataset September 2012
</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>
Hilt, et al. Expires March 29, 2013 [Page 32]
Internet-Draft Media Policy Dataset September 2012
<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>
Hilt, et al. Expires March 29, 2013 [Page 33]
Internet-Draft Media Policy Dataset September 2012
<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"/>
Hilt, et al. Expires March 29, 2013 [Page 34]
Internet-Draft Media Policy Dataset September 2012
</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">
Hilt, et al. Expires March 29, 2013 [Page 35]
Internet-Draft Media Policy Dataset September 2012
<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/>
Hilt, et al. Expires March 29, 2013 [Page 36]
Internet-Draft Media Policy Dataset September 2012
</attribute>
<text/>
</choice>
</zeroOrMore>
</define>
</grammar>
9. Security Considerations
Section 5 of [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 [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 [I-D.ietf-sipping-policy-package] to
distribute session info and session policy document meets these
requirements.
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 [I-D.ietf-sipping-policy-package] to distribute session policy
document meets these requirements.
The <shared-secret> element can contain a shared secret needed to
authenticate at a media intermediary. The privacy of documents
containing this element MUST be preserved when they are sent between
a server and a UA. When [I-D.ietf-sipping-policy-package] is used to
distribute these documents, encryption as defined in [RFC3261] (i.e.,
TLS or S/MIME) MUST be used
10. IANA Considerations
This document registers a new media type (application/
Hilt, et al. Expires March 29, 2013 [Page 37]
Internet-Draft Media Policy Dataset September 2012
media-policy-dataset+xml), a new RLAX NG schema, and a new XML
namespace.
10.1. Media Type Registration
Media type name: application
Media subtype name: media-policy-dataset+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 9 of this specification.
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has been
used to convey media policy information between SIP user agents and a
domain.
Additional Information:
Magic Number: None
File Extension: .mpf or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Volker Hilt,
<volkerh@bell-labs.com>
Intended usage: COMMON
Author/Change controller: The IETF.
10.2. RELAX NG Schema Registration
This specification registers a schema. The schema can be found as
the sole content of Section 8.
Hilt, et al. Expires March 29, 2013 [Page 38]
Internet-Draft Media Policy Dataset September 2012
URI: urn:ietf:params:xml:schema:mediadataset
Registrant Contact: IETF RAI area <rai@ietf.com>, Volker Hilt
<volkerh@bell-labs.com>
RELAX NG Schema: The RELAX NG schema to be registered is contained in
Section Section 8.
10.3. URN Sub-Namespace Registration
This section registers a new XML namespace, as per the guidelines in
[RFC3688]
URI: The URI for this namespace is
urn:ietf:params:xml:ns:mediadataset.
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Volker Hilt, <volkerh@bell-labs.com>
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Media Policy 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
11. References
11.1. Normative References
[I-D.ietf-sipping-policy-package]
Camarillo, G. and V. Hilt, "A Session Initiation Protocol
(SIP) Event Package for Session-Specific Session
Hilt, et al. Expires March 29, 2013 [Page 39]
Internet-Draft Media Policy Dataset September 2012
Policies.", draft-ietf-sipping-policy-package-08 (work in
progress), March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[W3C.REC-xml-20081126]
Sperberg-McQueen, C., Yergeau, F., Bray, T., Paoli, J.,
and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
Hilt, et al. Expires March 29, 2013 [Page 40]
Internet-Draft Media Policy Dataset September 2012
<http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-names-19990114]
Hollander, D., Bray, T., and A. Layman, "Namespaces in
XML", World Wide Web Consortium FirstEdition REC-xml-
names-19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
11.2. Informative References
[I-D.ietf-sip-session-policy-framework]
Camarillo, G., Rosenberg, J., and V. Hilt, "A Framework
for Session Initiation Protocol (SIP) Session Policies",
draft-ietf-sip-session-policy-framework-10 (work in
progress), February 2011.
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
the Use of Extensible Markup Language (XML)
within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
for Binary Floor Control Protocol (BFCP) Streams",
RFC 4583, November 2006.
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R.
Even, "RTP Payload Format for ITU-T Rec", RFC 4629,
January 2007.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences",
RFC 4856, February 2007.
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
RFC 6080, March 2011.
Appendix A. Acknowledgements
Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach
Hilt, et al. Expires March 29, 2013 [Page 41]
Internet-Draft Media Policy Dataset September 2012
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.
Authors' Addresses
Volker Hilt
Bell Labs/Alcatel-Lucent
791 Holmdel-Keyport Rd
Holmdel, NJ 07733
USA
Email: volkerh@bell-labs.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg
jdrosen.net
Monmouth, NJ
USA
Email: jdrosen@jdrosen.net
Dale R. Worley
Avaya Inc.
600 Technology Park Dr.
Billerica, MA 01821
US
Email: dworley@avaya.com
Hilt, et al. Expires March 29, 2013 [Page 42]
