Internet Engineering Task Force (IETF) V. Hilt
Request for Comments: 6796 Bell Labs/Alcatel-Lucent
Category: Standards Track G. Camarillo
ISSN: 2070-1721 Ericsson
J. Rosenberg
jdrosen.net
D. Worley
Ariadne
December 2012
A User Agent Profile Data Set for Media Policy
Abstract
This specification defines an XML document format to describe the
media properties of Session Initiation Protocol (SIP) sessions.
Examples for media properties are the codecs or media types used in
the session. This document also defines an XML document format to
describe policies that limit the media properties of SIP sessions.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6796.
Hilt, et al. Standards Track [Page 1]
RFC 6796 Media Policy Data Set December 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Media Policy Data Set Format ....................................5
3.1. Namespace and Media Type ...................................5
3.2. Extensibility ..............................................5
3.3. Attributes .................................................6
3.3.1. The 'visibility' Attribute ..........................6
3.3.2. The 'direction' Attributes ..........................6
3.3.3. The 'q' Attribute ...................................6
3.3.4. The 'media-type' Attribute ..........................7
3.3.5. The 'label' Attribute ...............................7
3.3.6. The 'enabled' Attribute .............................7
4. Session Info Documents ..........................................7
4.1. Mapping between SDP and Session Info Documents .............8
4.2. The
Element ................................10
4.3. The Element .....................................10
4.3.1. The Element ...............................10
4.4. The Element ........................11
4.4.1. The Element ...................12
4.4.2. The Element ....................13
4.4.3. The Element ....................13
5. Session Policy Documents .......................................14
5.1. Merging Session Policies ..................................14
5.1.1. Single Value Selection .............................14
5.1.2. Merging Sets .......................................15
5.1.3. Local Policy Server Selection ......................16
5.2. The Element ..............................16
5.3. The Element .........................16
5.4. The Element ........................17
5.5. The Element ..............................17
5.6. The Element .............................18
Hilt, et al. Standards Track [Page 2]
RFC 6796 Media Policy Data Set December 2012
5.7. The Element .................................18
6. Common Media Policy Data Set Elements ..........................19
6.1. The Element ..................................19
6.2. The Element .......................................19
6.2.1. The Element ...................20
6.2.2. The Element .......................20
6.3. The Element ......................................20
6.4. The Element ..............................21
6.5. The Element ...............................21
6.6. The Element ....................................22
6.7. The Element .....................................23
6.7.1. The Element ....................23
6.7.2. The Element ..............................23
6.7.3. The Element .................................23
6.7.4. The Element ..........................23
6.7.5. The Element ................................24
6.8. Other Session Properties ..................................24
7. Examples .......................................................25
7.1. Session Policy Documents ..................................25
7.2. Session Information Documents .............................25
7.2.1. Example 1 ..........................................25
7.2.2. Example 2 ..........................................26
8. RELAX NG Definition ............................................29
9. Security Considerations ........................................37
10. IANA Considerations ...........................................38
10.1. Media Type Registration ..................................38
10.2. RELAX NG Schema Registration .............................39
10.3. URN Sub-Namespace Registration ...........................39
11. References ....................................................40
11.1. Normative References .....................................40
11.2. Informative References ...................................41
Appendix A. Acknowledgements ......................................42
Hilt, et al. Standards Track [Page 3]
RFC 6796 Media Policy Data Set December 2012
1. Introduction
Within the Session Initiation Protocol (SIP) [RFC3261], "A Framework
for Session Initiation Protocol (SIP) User Agent Profile Delivery"
[RFC6080] and "A Framework for SIP Session Policies" [RFC6794] define
mechanisms to convey session policies and configuration information
from a network server to a user agent. An important piece of the
information conveyed to the user agent relates to the media
properties of the SIP sessions set up by the user agent. Examples
for these media properties are the codecs and media types used, the
media-intermediaries to be traversed, or the maximum bandwidth
available for media streams.
This specification defines a document format for media properties of
SIP sessions: the Media Policy Data Set Format (MPDF). This format
can be used in two ways. First, it can be used to describe the
properties of a given SIP session (e.g., the media types and codecs
used). These MPDF documents are called session info documents and
they are usually created based on the session description of a
session. Second, the MPDF format can be used to define policies for
SIP sessions in a session policy document. A session policy document
defines properties for a session (e.g., the media types allowed in a
session), independent of a specific session description.
If used with "A Framework for SIP Session Policies" [RFC6794],
session info documents are used in conjunction with session-specific
policies. A session info document is created by a user agent (UA)
based on the current session description and submitted to the policy
server. The policy server examines the session info document,
modifies it if necessary (e.g., by removing video streams if video is
not permitted), and returns the possibly modified session info
document to the UA. Session policy documents, on the other hand, are
used to describe session-independent policies that can be submitted
to the UA independent of a specific session.
The two types of MPDF documents, session information and session
policy documents, share the same set of XML elements to describe
session properties. Since these elements are used in different
contexts for session info and session policy documents, two different
root elements exist for the two document types: is the
root element for session information documents and
is the root element for session policy documents.
A user agent can receive multiple session policy documents from
different sources. This can lead to a situation in which the user
agent needs to apply multiple session policy documents to the same
session. This standard specifies merging rules for those XML
elements that can be present in session policy documents. It should
Hilt, et al. Standards Track [Page 4]
RFC 6796 Media Policy Data Set December 2012
be noted that these merging rules are part of the semantics of a
session policy XML element. User agents implement the merging rules
as part of implementing the element semantics. As a consequence, it
is not possible to build an entity that can mechanically merge two
session policy documents without understanding the semantics of all
elements in the input documents.
Merging rules are not needed for elements of session information
documents since they are created by one source and describe a
specific session.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Media Policy Data Set Format
This section discusses fundamental properties of the Media Policy
Data Set Format (MPDF).
3.1. Namespace and Media Type
The MPDF format is based on XML [W3C.REC-xml-20081126]. An MPDF
document MUST be well-formed and MUST be valid according to schemas,
including extension schemas, available to the validator and
applicable to the XML document. MPDF documents MUST be based on XML
1.0 and MUST be encoded using UTF-8.
MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The
namespace URIs for elements defined in this specification are URNs
[RFC2141], using the namespace identifier 'ietf' defined by [RFC2648]
and extended by [RFC3688]. The namespace URN for the MPDF schema is:
urn:ietf:params:xml:ns:mediadataset
The media type for the Media Policy Data Set Format is:
application/media-policy-dataset+xml
3.2. Extensibility
The MPDF format can be extended using XML extension mechanisms if
additional media properties are needed. In particular, elements from
different XML namespaces MAY be present within a MPDF document for
the purposes of extensibility; elements or attributes from unknown
namespaces MUST be ignored.
Hilt, et al. Standards Track [Page 5]
RFC 6796 Media Policy Data Set December 2012
3.3. Attributes
The following attributes can be used with elements of the MPDF
format. The specification of each MPDF element lists which of these
attributes can be used. If an element bears an attribute that may
not be used with it, the user agent MUST ignore the attribute.
3.3.1. The 'visibility' Attribute
The attribute 'visibility' specifies whether or not the user agent is
advised to display the property value to the user. This is used to
hide setting values that the administrator may not want the user to
see or know. The 'visibility' attribute has two possible values:
o visible: specifies that display of the property value is not
restricted. This is the default value of the attribute if it is
not specified.
o hidden: Specifies that the user agent is advised not to display
the property value. Display of the property value may be allowed
using special administrative interfaces, but it is not appropriate
for the ordinary user.
3.3.2. The 'direction' Attributes
Some properties are unidirectional and only apply to messages or data
streams transmitted into one direction. For example, a property for
media streams can be restricted to outgoing media streams only.
Unidirectional properties can be expressed by adding a 'direction'
attribute to the respective element.
The 'direction' attribute can have the following values:
o recvonly: the property only applies to incoming streams.
o sendonly: the property only applies to outgoing streams.
o sendrecv: the property applies to streams in both directions.
This is the default value that is used if the 'direction'
attribute is omitted.
3.3.3. The 'q' Attribute
It is possible to express a preference for a certain value relative
to the other values within a set of multiple values that are allowed
within a property. For example, it is possible to express that the
codecs G.711 and G.729 are allowed, but G.711 is preferred.
Preferences are to be expressed by adding a 'q' attribute to a
Hilt, et al. Standards Track [Page 6]
RFC 6796 Media Policy Data Set December 2012
property element. The 'q' attribute is only allowed in elements that
specify allowed values (as opposed to elements that specify forbidden
values).
The value of the 'q' attribute is a decimal number within the range
of 0 to 1, inclusive, with two or fewer decimal places. An element
with a higher 'q' value is preferred over one with a lower 'q' value.
3.3.4. The 'media-type' Attribute
The media-type attribute is used to define that an element only
applies to streams of a certain media type, as defined in Section
8.2.1 of [RFC4566]. For example, it may only apply to audio streams.
The value of the 'media-type' attribute MUST be the media type, such
as audio, video, text, or application.
3.3.5. The 'label' Attribute
The label attribute is used to identify a specific media stream. The
value of the label attribute is a token, whose syntax is defined in
[RFC4574]. The token can be chosen freely; however, it MUST be
unique among all elements in a session-info document.
3.3.6. The 'enabled' Attribute
The 'enabled' attribute specifies whether or not the user agent is
allowed to establish a media stream. This boolean attribute has two
possible values:
o yes: specifies that the media stream can be established. This is
the default value of the attribute if it is not specified.
o no: specifies that the user agent MUST NOT establish the media
stream.
4. Session Info Documents
Session info documents describe key properties of a SIP session such
as the media streams used in the session. Session info documents are
typically created based on a session description expressed using
Session Description Protocol (SDP) [RFC4566] or an SDP offer/answer
pair [RFC3264].
Session info documents can be used for session-specific policies
[RFC6794]. In this usage, a UA creates a session info document based
on its session description(s) and sends this document to the policy
server. The policy server modifies this document according to the
policies that apply to the described session and returns a version of
Hilt, et al. Standards Track [Page 7]
RFC 6796 Media Policy Data Set December 2012
the session info document that is compliant to the policies. For
example, if video streams are not permissible under current policies
and the UA submits a session info document that contains a video
stream, the policy server will disable (i.e., enabled="no") the video
stream in the session info document that it returns to the UA.
Session info documents use the root element. They use
elements described in this section and common elements described in
Section 6.
Elements that are only present in session info documents do not
require merging rules. If used in the context of session-specific
policies, session info documents are sent to one policy server at a
time only; therefore, a UA does not need to merge multiple session
info documents into one. A policy server needs to modify a session
info document it has received according to its policies. The
modification of session info documents is determined by the local
policies of the policy server and is, thus, outside the scope of this
standard.
A policy server can completely reject a session by returning a
session info document with an empty element:
4.1. Mapping between SDP and Session Info Documents
This section specifies how to map information in a session
description or an SDP offer/answer pair [RFC3264] to session info
documents. It also specifies how to map a session info document into
a session description. Note that these mapping rules do not include
rules for all elements that need to be present in a session info
document or in a session description. That is, some of those
elements are generated following their associated general rules
(e.g., the general rules to generate SDP "v=" and "t=" lines).
A UA with a session description that needs to create a session info
document uses the data in the session description and maps it
following the rules below. A UA with an SDP offer/answer pair that
needs to create a session info document uses the data that has been
agreed in the offer/answer exchange.
A UA MUST create a separate element for each "m=" line in a
session description or SDP offer/answer pair; the order of the
elements corresponds to the order of the "m=" lines. For a
session description, the UA MUST insert the media type from the "m="
line into a element and MUST create a element
for each codec listed in the "m=" line. For an SDP offer/answer
Hilt, et al. Standards Track [Page 8]
RFC 6796 Media Policy Data Set December 2012
pair, the UA MUST insert a element for each of the codecs
that were agreed upon for the particular stream in the offer/answer
exchange. The 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 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 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 contains information that may be considered
sensitive from a privacy standpoint. A UA configured not to
disclose that information would not include the
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 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
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
element child of the appropriate 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 element.
The mapping from a session info document to a session description
follows the same rules in the reverse direction.
For any particular "m=" line, the codecs MUST be listed in decreasing
order of the values of the 'q' attributes of the corresponding
elements.
Hilt, et al. Standards Track [Page 9]
RFC 6796 Media Policy Data Set December 2012
4.2. The Element
The element describes the properties of a specific SIP
session. The element MAY contain the optional
and elements, and multiple (including zero)
, , , ,
and elements, as well as elements from other namespaces.
4.3. The Element
The element is a container that is used to describe the
media streams used in a session. A element contains zero
or more elements. Each element describes the
properties (e.g., media type, codecs, and IP addresses and ports) of
a single media stream.
4.3.1. The Element
The 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 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 element,
if the remote session description is available to the UA. If not,
the UA generates a stream element that only contains the 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
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 element MUST contain one element, one or
more elements and one element. The
element MUST contain zero or one
elements.
Hilt, et al. Standards Track [Page 10]
RFC 6796 Media Policy Data Set December 2012
4.3.1.1. The Element
The element contains the hostname or IP address and
the receiving port number of the media stream in the local session
description. The hostname or IP address is separated from the port
by a ":". An example is: "host.example.com:49562".
The hostname or IP address of element is found in the "c=" element
for the stream in the local session description. The port number is
found in the "m=" element.
4.3.1.2. The Element
The element is structured exactly as the 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 Element
The element expresses a policy for routing
media streams through media intermediaries. The purpose of the
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 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 element SHOULD
therefore only contain intermediary elements of the same type.
This element MAY have the 'direction' attribute (see Section 3.3).
Multiple elements MUST NOT be present in a
container unless each applies to a different set of streams (e.g.,
one element for incoming and one for outgoing
streams). The element MUST contain one or
more elements defining a specific media intermediary, such as intermediary> or .
Hilt, et al. Standards Track [Page 11]
RFC 6796 Media Policy Data Set December 2012
Note: it is not intended that the element
replace connectivity discovery mechanisms such as Interactive
Connectivity Establishment (ICE). Instead of finding media relays
that provide connectivity, this element defines a policy for media
intermediaries that should be traversed. The set of
intermediaries defined in the element and
the ones discovered through ICE may overlap but don't have to.
4.4.1. The Element
A fixed intermediary relies on pre-configured forwarding rules. The
user agent simply sends media to the first media intermediary listed.
It can assume that this media intermediary has been pre-configured
with a forwarding rule for the media stream and knows where to
forward the packets. The configuration of forwarding rules in the
intermediary must be done through other means.
The contents of a element MUST be echoed to all
policy servers that provide policies for a session. That is, if
multiple policy servers provide policies for the same session, this
element needs to be forwarded to all of them, possibly in a second
round of session-specific policy subscriptions as described in
[RFC6794] in the "Contacting the Policy Server" section.
The element MUST contain one
element and MAY contain multiple optional elements.
4.4.1.1. The Element
The 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 element. All
additional port numbers SHOULD be identified in
elements.
4.4.1.2. The Element
If a protocol uses multiple subsequent ports (e.g., RTP), the lowest
port number SHOULD be included in the element. All
additional port numbers SHOULD be identified in
elements.
Hilt, et al. Standards Track [Page 12]
RFC 6796 Media Policy Data Set December 2012
4.4.2. The Element
The Traversal Using Relays around NAT (TURN) [RFC5766] protocol
provides a mechanism for inserting a relay into the media path.
Although the main purpose of TURN is NAT traversal, it is possible
for a TURN relay to perform other media intermediary functionalities.
The user agent establishes a binding on the TURN server and uses this
binding to transmit and receive media.
The element MUST contain one
element and MAY contain multiple optional elements
and zero or one each of the , , and
elements. If no element is present, UDP is assumed.
4.4.2.1. The Element
The element contains the shared secret needed to
authenticate at the media intermediary.
4.4.2.2. The Element
The element contains the user ID needed to authenticate to the
media intermediary.
4.4.2.3. The Element
The 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 element. Other
specifications may define additional values.
4.4.3. The Element
The Message Session Relay Protocol (MSRP) Relay Extensions [RFC4976]
define a means for incorporating relays into the media path of an
MSRP [RFC4975] session. MSRP is explicitly designed for a variety of
purposes, including policy enforcement.
The element MUST contain one element,
and may contain zero or one of each of the and
elements.
Hilt, et al. Standards Track [Page 13]
RFC 6796 Media Policy Data Set December 2012
4.4.3.1. The Element
The 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 element MUST have a scheme of "msrps:".
5. Session Policy Documents
Session policy documents describe policies for SIP sessions. Session
policy documents are independent of any specific session description
and express general policies for SIP sessions. A session policy
document is used to determine if a SIP session is policy-conformant
and can be used to modify the session, if needed, to conform to the
described policies.
Session policy documents can be used to encode session-independent
policies [RFC6794]. In this usage, a policy server creates a session
policy document and passes this document to a UA. The UA applies the
policies defined to the SIP sessions it is establishing. For
example, a session policy document can contain an element that
prohibits the use of video. To set up a session that is compliant to
this policy, a UA does not include the video media type in its SDP
offer or answer.
Session policy documents use the root element. They
use elements described in this section and common elements described
in Section 6.
5.1. Merging Session Policies
A UA may receive session policy documents from multiple sources;
multiple session policy documents can be merged into a single session
policy document that expresses the logical AND of the policies.
5.1.1. Single Value Selection
Properties that have a single value (e.g., the maximum bandwidth
allowed) require that a common value be determined for this property
during the merging process. The merging rules for determining this
value need to be defined individually for each element in the schema
definition (e.g., select the lowest maximum bandwidth).
Hilt, et al. Standards Track [Page 14]
RFC 6796 Media Policy Data Set December 2012
5.1.2. Merging Sets
The , ,
and elements are containers that hold a set of
media-type/codec elements. The values defined in these containers
MUST be merged to determine the set of media types/codecs that are
permissible in a session. Note that for a particular codec, the
element (see Section 6.2.2) allows identifying a
particular encoding or profile of the codec. Therefore, when the
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:
audio/PCMA
Session Policy Document 2:
audio/PCMA
audio/G729
It is possible that two session policy documents define non-
overlapping sets of allowed media types or codecs. The resulting
merged set would be empty, which is illegal according to the schema
definition of the media-type/codec elements. This constitutes a
conflict that cannot be resolved automatically. If these properties
are enforced by both networks, the UA will not be able to set up a
session.
Hilt, et al. Standards Track [Page 15]
RFC 6796 Media Policy Data Set December 2012
The combined set of media types/codecs MUST again be valid and well-
formed according to the schema definitions. A conflict occurs if the
combined property set is not a well-formed document after the merging
process is completed.
5.1.3. Local Policy Server Selection
Some properties require that only values from the local policy server
are used. The local policy server is the policy server that is in
the local domain of the user agent.
If policy documents are delivered through the configuration framework
[RFC6080], the value received through a subscription using the
"local-network" profile-type SHOULD used. Values received through
other profile-type subscriptions SHOULD be discarded.
If policy documents are delivered through the session-specific policy
mechanism [RFC6794] the value received from the policy server
identified by the Local Policy Server URI SHOULD used. Values
received from other policy servers SHOULD be discarded.
5.2. The Element
The element describes a policy that applies to SIP
sessions. The element MAY contain the optional
and elements and multiple (including zero)
, , ,
, , , , and
elements as well as elements from other namespaces.
5.3. The Element
The 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 element to this container.
This element MAY have the 'direction' and 'visibility' attributes
(see Section 3.3).
Multiple elements MUST NOT be present in a
container element unless each applies to a different set of streams
(e.g., one element for incoming and one for
outgoing streams). The element MUST contain
zero or more elements.
Hilt, et al. Standards Track [Page 16]
RFC 6796 Media Policy Data Set December 2012
A element MUST NOT be used in a container that
contains a element. The absence of both
elements in a container indicates no restrictions regarding media
types.
Merging of session-policy documents: containers
are merged as described in "Merging Sets" Section 5.1.2.
5.4. The Element
The 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 type> element to this container.
This element MAY have the 'direction' and 'visibility' attributes
(see Section 3.3).
Multiple elements MUST NOT be present in a
container element unless each applies to a different set of streams
(e.g., one element for incoming and one for
outgoing streams). The element MUST contain
zero or more elements.
A element MUST NOT be used in a container that
contains a element. The absence of both
elements in a container indicates no restrictions regarding media
types.
Merging of session-policy documents:
containers are merged as described in "Merging Sets" Section 5.1.2.
5.5. The Element
The 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 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 element to this container.
The element MAY have the 'direction' and
'visibility' attributes (see Section 3.3).
Hilt, et al. Standards Track [Page 17]
RFC 6796 Media Policy Data Set December 2012
Multiple elements MUST NOT be present in a container
element unless each applies to a different set of streams (e.g., one
element for incoming and one for outgoing streams).
The element MUST contain zero or more
elements.
A element MUST NOT be used in a container that
contains a element. The absence of both elements
in a container indicates no restrictions regarding codecs.
Merging of session-policy documents: containers are
merged as described in "Merging Sets" Section 5.1.2.
5.6. The Element
The 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 element are permitted and MAY be used
in a session. A specific codec is disallowed by adding the
corresponding element to this container.
The element MAY have the 'direction' and
'visibility' attributes (see Section 3.3).
Multiple elements MUST NOT be present in a
container element unless each applies to a different set of streams
(e.g., one element for incoming and one for
outgoing streams). The element MUST contain zero
or more elements.
A element MUST NOT be used in a container that
contains a element. The absence of both elements in
a container indicates no restrictions regarding codecs.
Merging of session-policy documents: containers are
merged as described in "Merging Sets" Section 5.1.2.
5.7. The Element
Domains often require that a user agent only uses ports in a certain
range for media streams. The element defines a policy
for the ports a user agent can use for media. The value of this
element consists of the decimal representation of a start port number
and an end port number, separated by a hyphen ("-"). The start/end
port numbers are the first/last port numbers that can be used, that
is, the range is inclusive. The start/end port numbers must be in
the range 1 to 65535 (inclusive).
Hilt, et al. Standards Track [Page 18]
RFC 6796 Media Policy Data Set December 2012
As with other policy elements, there are values of the
element that allow no sessions. This happens if the start port
number is greater than the end port number.
The default value for is "1-65535".
This element MAY have the 'visibility' attribute (see Section 3.3).
Merging of session-policy documents: the permitted ranges specified
by the two policies are set-intersected. If the resulting set is
empty, the resulting element value MUST be any allowed
value with a start port number greater than the end port number.
6. Common Media Policy Data Set Elements
This section describes common XML elements that are used in session
info and session policy documents to encode the media properties of
SIP sessions.
6.1. The Element
The 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
element, the media types defined MAY be used in a session. If used
in a session policy document inside a element,
the media types defined MUST NOT be used in a session.
6.2. The Element
The 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 element MAY have the 'q' attribute (see Section 3.3).
If used in a session policy document inside a
element, the codec defined MAY be used in a session. If used in a
session policy document inside a element, the codec
defined MUST NOT be used in a session.
The element MUST contain one element and
MAY contain multiple optional elements.
Hilt, et al. Standards Track [Page 19]
RFC 6796 Media Policy Data Set December 2012
6.2.1. The Element
The element contains a media type and subtype
that identifies a media format [RFC4566] (e.g., a codec). For audio
and video streams, the value of this element MUST be a media type and
subtype that is registered as an RTP Payload Type [RFC4855] separated
by a forward slash ("/"), e.g., audio/PCMA, audio/G726-16 [RFC4856],
or video/H263 [RFC4629]. For other media types, SDP sometimes
encodes the actual media format as part of the transport protocol
field (e.g., TCP/MSRP [RFC4975] and TCP/TLS/BFCP [RFC4583]). In
these cases, this element MUST contain the media type and the media
format part (e.g., message/msrp and application/bfcp).
6.2.2. The Element
The element may be needed for some codecs to
identify a particular encoding or profile. The value of this element
MUST be a name-value pair containing the name and the value of a
media type parameter for the codec [RFC4855]. The name and value are
separated by an equals sign ("="). For example, the parameter
"profile=0" can be used to specify a specific profile for the codec
video/H263-2000 [RFC4629].
6.3. The Element
The 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 element includes the
bandwidth needed for lower-layer transport and network protocols
(e.g., UDP and IP).
The element MAY have the 'direction' attribute (see
Section 3.3).
If used in a element, the element MAY also
have the 'visibility' attribute (see Section 3.3).
If the element occurs multiple times in a container element,
each instance MUST apply to a different set of media streams (i.e.,
one element for outgoing and one for incoming streams).
Hilt, et al. Standards Track [Page 20]
RFC 6796 Media Policy Data Set December 2012
Merging of session-policy documents: the lowest value MUST
be used.
6.4. The Element
The 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 element includes
the bandwidth needed for lower-layer transport and network protocols
(e.g., UDP and IP).
The element MAY have the 'direction' attribute (see
Section 3.3).
If used in a element, the element
MAY also have the 'visibility' attribute (see Section 3.3).
If the element occurs multiple times in a container
element, each instance MUST apply to a different set of media streams
(i.e., one element for outgoing and one for incoming
streams).
Merging of session-policy documents: the lowest
value MUST be used.
6.5. The Element
The 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 element includes the
bandwidth needed as encapsulated in IP (i.e., the RTP, UDP, and IP
overheads are included).
The element MAY have the 'direction' and 'media-type'
attributes (see Section 3.3).
If used in a element, the element
MAY also have the visibility attribute (see Section 3.3).
If used in a element, the element MAY
also have the label attribute.
Hilt, et al. Standards Track [Page 21]
RFC 6796 Media Policy Data Set December 2012
The media-type attribute is used to define that the
element only applies to streams of a certain media type (e.g., audio
streams).
The element is used to define a bandwidth limit for a
specific media stream. The use of this attribute requires that the
element that represents the media stream to which this
bandwidth limit applies also has a 'label' attribute. A
element with a 'label' attribute applies only to the
stream element that has a 'label' attribute with the same value. If
no matching element exists, then the element
MUST be ignored.
If the element occurs multiple times in a container
element, each instance MUST apply to a different set of media streams
(i.e., one element for outgoing and one for incoming
streams).
Merging of session-policy documents: the lowest value
MUST be used.
6.6. The Element
The element contains a Differentiated Services Codepoint
(DSCP) [RFC2474] value that should be used to populate the IP DS
field of media packets. The 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 element, the element MAY