SIPPING Working Group V. Hilt
Internet-Draft Bell Labs/Lucent Technologies
Expires: April 24, 2007 G. Camarillo
Ericsson
J. Rosenberg
Cisco Systems
October 21, 2006
A User Agent Profile Data Set for Media Policy
draft-ietf-sipping-media-policy-dataset-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This specification defines a document format for media properties of
Session Initiation Protocol (SIP) sessions, such as the codecs or
media types used. This format is based on XML and extends the Schema
for SIP User Agent Profile Data Sets. It is capable of expressing
the media properties of a SIP session and can be used to summarize a
Hilt, et al. Expires April 24, 2007 [Page 1]
Internet-Draft Media Policy Dataset October 2006
SIP session or to formulate policies for a SIP session.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. The 'stream-label' Attribute . . . . . . . . . . . . . . . 6
5.2. The 'media-type' Attribute . . . . . . . . . . . . . . . . 6
6. Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. The <session-policy> Element . . . . . . . . . . . . . . . 6
6.2. The <session-info> Element . . . . . . . . . . . . . . . . 7
6.3. The <context> Element . . . . . . . . . . . . . . . . . . 7
6.3.1. The <domain> Element . . . . . . . . . . . . . . . . . 8
6.3.2. The <contact> Element . . . . . . . . . . . . . . . . 8
6.3.3. The <info> Element . . . . . . . . . . . . . . . . . . 8
6.3.4. The <call-ID> Element . . . . . . . . . . . . . . . . 8
6.3.5. The <request-URI> Element . . . . . . . . . . . . . . 8
6.4. The <media-types> Element . . . . . . . . . . . . . . . . 9
6.4.1. The <media-type> Element . . . . . . . . . . . . . . . 9
6.5. The <codecs> Element . . . . . . . . . . . . . . . . . . . 9
6.5.1. The <codec> Element . . . . . . . . . . . . . . . . . 10
6.6. The <media-intermediaries> Element . . . . . . . . . . . . 11
6.6.1. The <configured-intermediary> Element . . . . . . . . 12
6.6.2. The <turn-intermediary> Element . . . . . . . . . . . 12
6.6.3. The <ipinip-intermediary> Element . . . . . . . . . . 13
6.6.4. The <iploose-intermediary> Element . . . . . . . . . . 13
6.7. The <max-bandwidth> Element . . . . . . . . . . . . . . . 13
6.8. The <qos-dscp> Element . . . . . . . . . . . . . . . . . . 14
6.9. The <local-ports> Element . . . . . . . . . . . . . . . . 14
6.10. The <streams> Element . . . . . . . . . . . . . . . . . . 14
6.10.1. The <stream> Element . . . . . . . . . . . . . . . . . 15
6.11. Other Elements . . . . . . . . . . . . . . . . . . . . . . 15
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Media Policy . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Session Information . . . . . . . . . . . . . . . . . . . 17
7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17
7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 19
7.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 20
8. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. MIME Registration for application/session-policy+xml . . . 26
10.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:mediadataset . . . . . . . . . . . 27
Hilt, et al. Expires April 24, 2007 [Page 2]
Internet-Draft Media Policy Dataset October 2006
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Hilt, et al. Expires April 24, 2007 [Page 3]
Internet-Draft Media Policy Dataset October 2006
1. Introduction
The Framework for Session Initiation Protocol (SIP) [18] User Agent
Profile Delivery [16] and the Framework for SIP Session Policies [15]
define mechanisms to convey session policies and configuration
information from a network server to a user agent. An important part
of this information are properties that define media-related aspects
of SIP sessions. These properties include, for example, codecs and
media-types to be used, media-intermediaries to be traversed or the
maximum bandwidth available in a session.
This draft 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 summarize the properties
of a given SIP session. In this case, an MPDF document is created
based on the session descriptions for this session (i.e. the offer
and the answer). Second, the MPDF format can be used to express
configuration information and policies for a session. In this usage,
an MPDF document describes properties that can be used in a SIP
session.
The MPDF format is based on XML [14] and extends the Schema for SIP
User Agent Profile Data Sets [12] by specifying a data set for media
properties. The format also satisfies the requirements of a minimal
set of media-level session policy elements as described in [17]. It
can be extended through the XML extension mechanisms if additional
media properties are needed.
The two types of MPDF documents, session information and session
policy documents, share the same set of XML elements to describe
session properties. However, session information and session policy
documents use different root elements: <session-info> for session
information documents and <session-policy> for session policy
documents. This enables the recipient of a document to determine the
specific document type. Also, some XML elements can only appear
inside one or the other root element since they are only defined for
one of the usages.
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.
A user agent may receive multiple MPDF policy documents from
different sources. These documents need to be merged into a single
document the user agent can work with. General rules for merging
MPDF policy documents are described in [12]. Specific merging rules
for each of the MPDF policy elements are described below.
Hilt, et al. Expires April 24, 2007 [Page 4]
Internet-Draft Media Policy Dataset October 2006
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, [1] and indicate requirement levels for
compliant implementations.
3. Namespace
This specification makes use of XML namespaces [4]. The namespace
URIs for schemas defined in this specification are URNs [7], using
the namespace identifier 'ietf' defined by [8] and extended by [5].
The namespace URN for the MPDF schema is:
urn:ietf:params:xml:ns:mediadataset
The MIME type for the Media Policy Dataset Format is:
application/session-policy+xml
4. Extensibility
The MPDF format is an extension of the Schema for SIP User Agent
Profile Data Sets [12]. Elements from the MPDF namespace can be used
in conjunction with elements from other extensions of this schema.
The MPDF format itself can also be extended using XML extension
mechanisms. 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.
5. Attributes
The following attributes provide common functionalities, which are
generally useful for media properties:
o Per-stream properties: 'stream-label' attribute
o Media-type specific properties: 'media-type' attribute
These attributes are defined in addition to the attributes inherited
from the Profile Data Set Schema [12]:
Hilt, et al. Expires April 24, 2007 [Page 5]
Internet-Draft Media Policy Dataset October 2006
o Property Access Control: 'visibility' attribute
o Policies: 'policy' and 'excluded-policy' attribute
o Unidirectional Properties: 'direction' attribute
o Preferences: 'q' attribute
The use of these attributes is defined individually for each element
in the XML format below.
5.1. The 'stream-label' Attribute
Some properties only apply to a specific media stream. The stream to
which a property applies MUST be identifiable through a label [6].
Per-stream properties can be expressed by adding a 'stream-label'
attribute to the respective element. Such a property only applies to
the identified stream. If there is no stream with this label, the
element must be ignored.
Per-stream properties require that the labels of media streams are
known to the creator of a document (i.e. the profile delivery/policy
server). These labels are part of the session description.
5.2. The 'media-type' Attribute
Some properties only apply to streams of a certain media type. For
example, a property may only apply to audio streams. Media-type
specific properties can be defined by adding a 'media-type' attribute
to the respective element. Such a property only applies to media
streams of that type.
The value of the 'media-type' attribute MUST be the name of a IANA
registered media type (see [3]), such as 'audio', 'video', 'text', or
'application'.
6. Elements
The following elements are defined for the MPDF format.
6.1. The <session-policy> Element
The <session-policy> element describes a policy for a SIP session.
I.e. the contents of this element specify which properties are
allowed or disallowed in a SIP session. Documents containing
<session-policy> elements are typically sent from a policy server to
a UA.
The <session-policy> MAY occur multiple times inside a <property_set>
[12] element.
Hilt, et al. Expires April 24, 2007 [Page 6]
Internet-Draft Media Policy Dataset October 2006
The <session-policy> element MAY contain one optional <context>
element and multiple (including zero) <media-types>, <codecs>,
<media-intermediaries>, <max-bandwidth>, <qos-dscp>, and <local-
ports> elements as well as elements from other namespaces.
6.2. The <session-info> Element
The <session-info> element summarizes the properties of a specific
SIP session. This element is typically created based on a session
description and reflects the properties that are describe in this
session description, for example, the codecs and media types used.
Documents containing <session-info> elements are typically sent from
a UA to a policy server.
The <session-info> MAY occur multiple times inside a <property_set>
[12] element.
The <session-info> element MAY contain one optional <context> and
<streams> element and multiple (including zero) <media-types>,
<codecs>, and <max-bandwidth> elements as well as elements from other
namespaces.
OPEN ISSUE: need to determine which elements are needed in the
<session-info> element (e.g. are the <media-intermediaries>, <qos-
dscp>, <local-ports> elements needed. Is a media encryption key
element needed).
6.3. The <context> Element
The <context> element provides context information about the MPDF
document.
The <context> element MAY contain multiple <contact> and an <info>
element.
If used in a <session-policy> element, the <context> element MAY also
contain a <domain> element.
If used in a <session-info> element, the <context> element MAY also
contain a <request-URI> element.
Merging rule: the <context> element is not subject to merging.
Information in the context element may be used to assist the user
if a conflict occurs during the merging process.
Hilt, et al. Expires April 24, 2007 [Page 7]
Internet-Draft Media Policy Dataset October 2006
6.3.1. The <domain> Element
The <domain> element contains a URI that identifies the domain which
has issued this policy.
The <domain> element is optional and MAY occur only once inside a
<context> element.
The <domain> element is only defined inside a <session-info> element.
6.3.2. The <contact> Element
The <contact> element contains a contact address (e.g. a SIP URI or
email address) under which the issuer of this document can be
reached.
The <contact> element is optional and MAY occur multiple times inside
a <context> element.
6.3.3. The <info> Element
The <info> element provides a short textual description of the policy
that should be intelligible to the human user.
The <info> element is optional and MAY occur only once inside a
<context> element.
6.3.4. The <call-ID> Element
The <call-ID> element contains the call-ID of a session.
If used in a <session-policy> element, all properties defined in this
container MUST only be applied to the identified session.
If used in a <session-info> element, the <call-ID> contains the call
ID of the session that is summarized in this document.
6.3.5. The <request-URI> Element
The <request-URI> element identifies the request-URI the dialog
initiating request of a session is sent to.
The <request-URI> element is only defined inside a <session-info>
element.
Hilt, et al. Expires April 24, 2007 [Page 8]
Internet-Draft Media Policy Dataset October 2006
6.4. The <media-types> Element
The <media-types> element describes the usage of media types (e.g.
audio, video) in a session. If used in a <session-policy> element,
it defines the media types that can be used and those that must not
be used in a session. If used in a <session-info> element, it
describes the media types that appear in a session description.
This element MAY have the following attribute (see Section 5):
direction.
If used in a <session-policy> element, this element MAY have the
following additional attributes (see Section 5): visibility,
excluded-policy. The 'excluded-policy' attribute specifies the
default policy for all media types that are not listed inside this
element.
Multiple <media-types> elements MAY only be present in <session-
policy> or <session-info> element if each element applies to a
different set of streams (e.g. one <media-types> for incoming and one
for outgoing streams). The <media-types> MUST contain one or more
<media-type> elements.
Merging rule: <media-types> containers are merged using the
"Multiple Enumerated Value Merging Algorithm" defined in [12].
6.4.1. The <media-type> Element
The <media-type> element specifies a media type. The value of this
element MUST be the name of a IANA registered media type (see [3]),
such as 'audio', 'video', 'text', or 'application'.
This element MAY have the following attribute (see Section 5): q.
If used in a <session-policy> element, this element MAY have the
following additional attribute (see Section 5): policy. Media types
that have the policy 'allowed' MAY be used and media types with the
policy 'disallowed' MUST NOT be used.
6.5. The <codecs> Element
The <codecs> element describes the usage of codecs in a session. If
used in a <session-policy> element, it defines the codecs that may be
used or must not be used in a session. A policy MUST allow the use
of at least one codec per media type. If used in a <session-info>
element, it describes the codecs that appear in a session
description.
Hilt, et al. Expires April 24, 2007 [Page 9]
Internet-Draft Media Policy Dataset October 2006
This element MAY have the following attributes (see Section 5):
direction, stream-label.
If used in a <session-policy> element, this element MAY have the
following additional attributes (see Section 5): visibility,
excluded-policy. The 'excluded-policy' attribute specifies the
default policy for all codecs that are not listed inside this
element.
Multiple <codecs> elements MAY only be present in <session-policy> or
<session-info> element if each element applies to a different set of
streams (e.g. one <codecs> for incoming and one for outgoing
streams). The <codecs> element MUST contain one or more <codec>
elements.
Merging rule: <codecs> containers are merged using the "Multiple
Enumerated Value Merging Algorithm" defined in [12].
6.5.1. The <codec> Element
The <codec> element specifies a codec. The content of this element
MUST be a registered MIME type [2] using media-type and subtype (e.g.
audio/PCMA or video/H263) and possibly additional registered MIME
type parameters.
This element MAY have the following attribute (see Section 5): q.
If used in a <session-policy> element, this element MAY have the
following additional attribute (see Section 5): policy. Codecs that
have the policy 'allowed' MAY be used and codecs with the policy
'disallowed' MUST NOT be used.
The <codec> element MUST contain one <mime-type> element and MAY
contain multiple optional <mime-parameter> elements.
6.5.1.1. The <mime-type> Element
The <mime-type> element identifies a codec. The value of this
element MUST be a combination of a registered MIME media-type and
subtype [2] separated by a "/" (e.g. audio/PCMA, audio/G726-16,
video/H263).
6.5.1.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
registered MIME type parameter for the codec [2]. The name and value
Hilt, et al. Expires April 24, 2007 [Page 10]
Internet-Draft Media Policy Dataset October 2006
are separated by a "=". For example, the parameter "profile=0" can
be used to specify a specific profile for the codec "video/
H263-2000".
6.6. The <media-intermediaries> Element
The <media-intermediaries> element expresses a policy for routing a
media stream through a media intermediary. The purpose of the
<media-intermediaries> element is to tell the UA to send a media
stream through one (or a chain of) media intermediaries. Instead of
sending the media directly to its final destination, the UA instead
specifies a source route, which touches each intermediary and then
reaches the final recipient. If there are N hops, including the
final recipient, there needs to be a way for the media stream to
specify N destinations. The <media-intermediaries> element is only
defined in a <session-policy> element.
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 following attributes (see Section 5):
visibility, direction, stream-label.
Multiple <media-intermediaries> elements in a <session-policy>
element MAY only be present if each element 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 of the following elements (all of the same
type): <configured-intermediary>, <turn-intermediary>, <ipinip-
intermediary>, and <iploose-intermediary>.
Merging rule: the intermediaries defined in all policies are
traversed. In general, local intermediaries should be traversed
before remote intermediaries. During the merging process, <media-
intermediaries> element values from different servers are ordered
using the "Closest Value First Merging Algorithm" [12]. The
intermediaries should be traversed in this order.
Hilt, et al. Expires April 24, 2007 [Page 11]
Internet-Draft Media Policy Dataset October 2006
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.
6.6.1. The <configured-intermediary> Element
A configured intermediary relies on configured forwarding rules. The
user agent simply sends media to the first media intermediary listed.
It can assume that this media intermediary has been 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 <configured-intermediary> element is optional and MAY occur
multiple times inside a <media-intermediaries> element. The
<configured-intermediary> element MUST contain one <int-uri> element
and MAY contain multiple optional <int-addl-port> elements.
6.6.1.1. The <int-uri> Element
The <int-uri> element contains a URI that identifies the IP address
and port number of a media intermediary. The UA uses this URI to
send its media streams to the intermediary. If a protocol uses
multiple subsequent ports (e.g. RTP), the lowest port number SHOULD
be included in the URI. All additional port numbers SHOULD be
identified in <int-addl-port> elements.
6.6.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-uri> element. All
additional port numbers SHOULD be identified in <int-addl-port>
elements.
6.6.2. The <turn-intermediary> Element
The TURN [13] 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-uri> element
Hilt, et al. Expires April 24, 2007 [Page 12]
Internet-Draft Media Policy Dataset October 2006
and MAY contain multiple optional <int-addl-port> elements and one
optional <shared-secret> element.
6.6.2.1. The <shared-secret> Element
The <shared-secret> element contains the shared secret needed to
authenticate at the TURN server.
6.6.3. The <ipinip-intermediary> Element
For these intermediaries, IP-in-IP tunneling [11] is used to specify
the hops of media intermediary traversal. The ultimate destination
is specified in the destination IP address of the innermost packet.
Each subsequent hop results in another encapsulation, with the
destination of that hop in the destination IP address of the packet.
The <ipinip-intermediary> element MUST contain one <int-uri> element
and MAY contain multiple optional <int-addl-port> elements.
6.6.4. The <iploose-intermediary> Element
IP provides a loose routing mechanism that allows the sender of an IP
datagram to specify a set of IP addresses that are to be visited on
the way before reaching the final destination.
The <iploose-intermediary> element MUST contain one <int-uri> element
and MAY contain multiple optional <int-addl-port> elements.
6.7. The <max-bandwidth> Element
The <max-bandwidth> element contains the maximum bandwidth in
kilobits per second an entity can use for its media streams. If used
in a <session-policy> element, this is the maximum media bandwidth a
UA can count on. If used in a <session-info> element, this is the
maximum bandwidth a UA is planning on using for media streams.
This element MAY have the following attribute (see Section 5):
direction, media-type.
If used in a <session-policy> element, this element MAY have the
following additional attribute (see Section 5): visibility.
If the <max-bandwidth> element occurs multiple times in a <session-
policy> or <session-info> element, each instance MUST apply to
different media streams (i.e. one <max-bandwidth> element for
outgoing and one for incoming streams).
Hilt, et al. Expires April 24, 2007 [Page 13]
Internet-Draft Media Policy Dataset October 2006
Merging rule: the lowest max-bandwidth value is used.
6.8. The <qos-dscp> Element
The <qos-dscp> element contains an Differentiated Services Codepoint
(DSCP) [10] value that should be used to populate the IP DS field of
media packets. The <qos-dscp> contains an integer value that
represents a 6 bit field and therefore ranges from 0 to 63. The
<qos-dscp> element is only defined in a <session-policy> element.
This element may have the following attributes (see Section 5):
visibility, direction, stream-label, media-type.
The <qos-dscp> element is optional and MAY occur multiple times
inside a <session-policy> element. If the <qos-dscp> element occurs
multiple times in a <session-policy> element, each instance MUST
apply to a different media stream (i.e. one <qos-dscp> element for
audio and one for video streams).
Merging rule: the domain that is first traversed by the media
stream has precedence and its DSCP value is used. During the
merging process, <qos-dscp> element values from different servers
are ordered using the "Closest Value First Merging Algorithm"
[12]. The DSCP value from the closest server is used.
6.9. 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 a start port and an end port separated by a "-".
The start/end port is the first/last port that can be used. The
<local-ports> element is only defined in a <session-policy> element.
This element may have the following attributes (see Section 5):
visibility.
Merging rule: the domain that is first traversed by the media
stream has precedence and its local ports value is used. During
the merging process, <local-ports> element values from different
servers are ordered using the "Closest Value First Merging
Algorithm" [12]. The value from the closest server is used.
6.10. The <streams> Element
The <streams> element describes the media streams that are used in a
session. It contains multiple <stream> elements, which each
represents one media stream used in the session. The <streams>
Hilt, et al. Expires April 24, 2007 [Page 14]
Internet-Draft Media Policy Dataset October 2006
element is only defined in a <session-info> element.
The <streams> element MUST contain one or more <stream> elements.
6.10.1. The <stream> Element
The <stream> element describes a media stream. It contains the media
type and media URIs for of this stream. A URI consists of the
address and a port number contained in a session description for this
stream. A UA that generates a <stream> element MUST insert the
address/port found in the local session description for this media
stream into the local-uri element. It MUST insert the address/port
of the remote session description into the remote URI, if this
address/port is available to the UA. If not, the UA generates a
stream element that only contains the local-URI.
This element may have the following attributes (see Section 5):
direction, stream-label.
The <stream> element MUST contain one <media-type> (see
Section 6.4.1) and one <local-uri> element and MAY contain one
optional <remote-uri> element.
6.10.1.1. The <local-uri> Element
The <local-uri> element contains a URI that identifies the IP address
and port number of the media stream in the local session description.
The address part of this URI is contained in the c= element of the
local SDP description. The port number part of the URI is contained
in the m= element of the stream.
6.10.1.2. The <remote-uri> Element
The <remote-uri> element is structured exactly as the <local-uri>
element. However, it contains a URI that identifies the IP address
and port number of the described media stream in the remote session
description.
6.11. Other Elements
A number of additional elements have been proposed for a policy
language. These elements are deemed to be outside the scope of this
media policy format. However, they may be defined in extensions of
MPDF or other profile data sets.
Hilt, et al. Expires April 24, 2007 [Page 15]
Internet-Draft Media Policy Dataset October 2006
o maximum number of streams
o maximum number of sessions
o maximum number of streams per session
o maximum bandwidth per session
o maximum bandwidth per stream
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. Example
7.1. Media Policy
The following example describes a policy 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. The policy also inserts a
media intermediary into outgoing media streams using IP-in-IP
tunneling.
Hilt, et al. Expires April 24, 2007 [Page 16]
Internet-Draft Media Policy Dataset October 2006
<property-set>
<session-policy>
<context>
<domain>example.com</domain>
<contact>sip:policy_manager@example.com</contact>
<info>Access network policies</info>
</context>
<media-types excluded-policy="disallow">
<media-type policy="allow">audio</media-type>
<media-type policy="allow">video</media-type>
</media-types>
<codecs excluded-policy="allow">
<codec policy="disallow">
<mime-type>audio/G729</mime-type>
</codec>
<codec policy="disallow">
<mime-type>audio/G723</mime-type>
</codec>
</codecs>
<media-intermediaries direction="sendonly">
<ipinip-intermediary>
<int-uri>192.0.2.0:6000</int-uri>
<int-addl-port>6001</int-addl-port>
</ipinip-intermediary>
</media-intermediaries>
</session-policy>
</property-set>
7.2. Session Information
The following examples contain session descriptions and the MPDF
documents that summarize these sessions. Examples 1 and 3 are based
on one session description, example 2 is based on two session
descriptions (i.e. the offer and answer).
7.2.1. Example 1
Local SDP session description (remote description unknown):
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
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
Hilt, et al. Expires April 24, 2007 [Page 17]
Internet-Draft Media Policy Dataset October 2006
m=video 51234 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
MPDF document:
<property-set>
<session-info>
<context>
<contact>sip:alice@atlanta.com</contact>
<info>session information</info>
</context>
<media-types>
<media-type>audio</media-type>
<media-type>video</media-type>
</media-types>
<codecs>
<codec>
<mime-type>audio/PCMU</mime-type>
</codec>
<codec>
<mime-type>audio/1016</mime-type>
</codec>
<codec>
<mime-type>audio/GSM</mime-type>
</codec>
<codec>
<mime-type>video/H261</mime-type>
</codec>
<codec>
<mime-type>video/H263</mime-type>
</codec>
</codecs>
<streams>
<stream>
<media-type>audio</media-type>
<local-uri>host.anywhere.com:49562</local-uri>
</stream>
<stream>
<media-type>video</media-type>
<local-uri>host.anywhere.com:51234</local-uri>
</stream>
</streams>
</session-info>
</property-set>
Hilt, et al. Expires April 24, 2007 [Page 18]
Internet-Draft Media Policy Dataset October 2006
7.2.2. Example 2
Local SDP session description:
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
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.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 52123 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:
<property-set>
<session-info>
<context>
<contact>sip:alice@atlanta.com</contact>
<info>session information</info>
</context>
<media-types>
<media-type>audio</media-type>
<media-type>video</media-type>
</media-types>
<codecs>
<codec>
<mime-type>audio/PCMU</mime-type>
</codec>
<codec>
<mime-type>audio/GSM</mime-type>
</codec>
<codec>
Hilt, et al. Expires April 24, 2007 [Page 19]
Internet-Draft Media Policy Dataset October 2006
<mime-type>video/H261</mime-type>
</codec>
</codecs>
<streams>
<stream>
<media-type>audio</media-type>
<local-uri>host.anywhere.com:49562</local-uri>
<remote-uri>host.example.com:52123</remote-uri>
</stream>
<stream>
<media-type>video</media-type>
<local-uri>host.anywhere.com:51234</local-uri>
<remote-uri>host.example.com:50286</remote-uri>
</stream>
</streams>
</session-info>
</property-set>
7.2.3. Example 3
Local SDP session description (remote description unknown):
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
MPDF document:
<property-set>
<session-info>
<context>
<contact>sip:alice@atlanta.com</contact>
<info>session information</info>
</context>
<media-types>
<media-type>audio</media-type>
<media-type>video</media-type>
</media-types>
<codecs>
<codec>
<mime-type>audio/PCMU</mime-type>
Hilt, et al. Expires April 24, 2007 [Page 20]
Internet-Draft Media Policy Dataset October 2006
</codec>
<codec>
<mime-type>video/H261</mime-type>
</codec>
<codec>
<mime-type>video/MPV</mime-type>
</codec>
</codecs>
<streams>
<stream>
<media-type>audio</media-type>
<local-uri>host.anywhere.com:49170</local-uri>
</stream>
<stream>
<media-type>video</media-type>
<local-uri>host.anywhere.com:51372</local-uri>
</stream>
<stream>
<media-type>video</media-type>
<local-uri>host.anywhere.com:53000</local-uri>
</stream>
</streams>
</session-info>
</property-set>
8. Schema Definition
Note: the schema definition still reflects the -01 version of this
draft.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:mediadataset"
xmlns:tns="urn:ietf:params:xml:ns:mediadataset"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:spds="http://sipfoundry.org/schema/profile-data-sets-00">
<xs:attributeGroup name="single_stream_attributes" >
<xs:attribute name="stream-label"
type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:attributeGroup name="media_type_attributes" >
<xs:attribute name="media-type"
type="xs:string" use="optional"/>
</xs:attributeGroup>
Hilt, et al. Expires April 24, 2007 [Page 21]
Internet-Draft Media Policy Dataset October 2006
<xs:element name="session-policy">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:context"
minOccurs="0" maxOccurs="1"/>
<xs:element ref="tns:media-types"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:codecs"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:media-intermediaries"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:max-bandwidth"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:qos-dscp"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:local-ports"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="context">
<xs:complexType>
<xs:sequence>
<xs:element name="domain" type="xs:anyURI" minOccurs="0"
maxOccurs="1"/>
<xs:element name="contact" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="info" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="media-types"
substitutionGroup="spds:setting_container">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:media-type"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="codecs"
substitutionGroup="spds:setting_container">
Hilt, et al. Expires April 24, 2007 [Page 22]
Internet-Draft Media Policy Dataset October 2006
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:codec"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="media-intermediaries"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:configured-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:turn-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:ipinip-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:iploose-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="max-bandwidth"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:positiveInteger" />
</xs:simpleContent>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:media_type_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="qos-dscp"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:integer" >
<xs:minInclusive value="0" />
<xs:maxInclusive value="63" />
</xs:restriction>
</xs:simpleContent>
Hilt, et al. Expires April 24, 2007 [Page 23]
Internet-Draft Media Policy Dataset October 2006
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
<xs:attributeGroup ref="tns:media_type_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="local-ports"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:string" />
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="media-type"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:string" />
</xs:simpleContent>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="codec"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="mime-type" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="mime-parameter" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="configured-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
Hilt, et al. Expires April 24, 2007 [Page 24]
Internet-Draft Media Policy Dataset October 2006
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="turn-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="shared-secret" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="ipinip-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="iploose-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
Hilt, et al. Expires April 24, 2007 [Page 25]
Internet-Draft Media Policy Dataset October 2006
</xs:schema>
9. Security Considerations
Session policy information can be sensitive information. The
protocol used to distribute it SHOULD ensure privacy, message
integrity and authentication. Furthermore, the protocol SHOULD
provide access controls which restrict who can see who else's session
policy information.
10. IANA Considerations
This document registers a new MIME type, application/
session-policy+xml, and registers a new XML namespace.
10.1. MIME Registration for application/session-policy+xml
MIME media type name: application
MIME subtype name: session-policy+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [9].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [9].
Security considerations: See Section 10 of RFC 3023 [9] 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 download the session policy of a domain to SIP user agents.
Additional Information:
Magic Number: None
File Extension: .wif or .xml
Macintosh file type code: "TEXT"
Hilt, et al. Expires April 24, 2007 [Page 26]
Internet-Draft Media Policy Dataset October 2006
Personal and email address for further information: Volker Hilt,
<volkerh@bell-labs.com>
Intended usage: COMMON
Author/Change controller: The IETF.
10.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:mediadataset
This section registers a new XML namespace, as per the guidelines in
[5]
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>Session Policy Namespace</title>
</head>
<body>
<h1>Namespace for Session Policy Information</h1>
<h2>urn:ietf:params:xml:ns:mediadataset</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
Appendix A. Acknowledgements
Many thanks to Allison Mankin, Dan Petrie and Martin Dolly for the
discussions and suggestions. Many thanks to Roni Even and Mary
Barnes for reviewing the draft and providing feedback.
Hilt, et al. Expires April 24, 2007 [Page 27]
Internet-Draft Media Policy Dataset October 2006
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[3] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.
[4] Layman, A., Hollander, D., and T. Bray, "Namespaces in XML",
World Wide Web Consortium Recommendation REC-xml-names-
19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[5] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress),
June 2003.
[6] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005.
[7] Moats, R., "URN Syntax", RFC 2141, May 1997.
[8] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[10] 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.
[11] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[12] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and
Guidelines for Defining Session Initiation Protocol User Agent
Profile Data Sets", draft-petrie-sipping-profile-datasets-03
(work in progress), October 2005.
[13] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Hilt, et al. Expires April 24, 2007 [Page 28]
Internet-Draft Media Policy Dataset October 2006
Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
progress), October 2006.
[14] Yergeau, F., Maler, E., Paoli, J., Bray, T., and C. Sperberg-
McQueen, "Extensible Markup Language (XML) 1.0 (Third
Edition)", World Wide Web Consortium Recommendation REC-xml-
20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
11.2. Informative References
[15] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for
Session Initiation Protocol (SIP) Session Policies",
draft-ietf-sip-session-policy-framework-00 (work in progress),
October 2006.
[16] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-09
(work in progress), October 2006.
[17] Rosenberg, J., "Requirements for Session Policy for the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-session-policy-req-02 (work in progress),
July 2004.
[18] 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.
Authors' Addresses
Volker Hilt
Bell Labs/Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: volkerh@bell-labs.com
Hilt, et al. Expires April 24, 2007 [Page 29]
Internet-Draft Media Policy Dataset October 2006
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
USA
Email: jdrosen@cisco.com
Hilt, et al. Expires April 24, 2007 [Page 30]
Internet-Draft Media Policy Dataset October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hilt, et al. Expires April 24, 2007 [Page 31]
