draft-ietf-sipping-session-indep-policy-02.txt   draft-ietf-sipping-session-indep-policy-03.txt 
SIPPING Working Group V. Hilt SIPPING Working Group V. Hilt
Internet-Draft Bell Labs/Lucent Technologies Internet-Draft Bell Labs/Lucent Technologies
Expires: August 10, 2005 G. Camarillo Expires: January 17, 2006 G. Camarillo
Ericsson Ericsson
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
February 9, 2005 July 16, 2005
Session Initiation Protocol (SIP) Session Policies - Document Format Session Initiation Protocol (SIP) Session Policies - Document Format
and Session-Independent Delivery Mechanism and Session-Independent Delivery Mechanism
draft-ietf-sipping-session-indep-policy-02 draft-ietf-sipping-session-indep-policy-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 10, 2005. This Internet-Draft will expire on January 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This draft defines a delivery mechanism for SIP session policies that This draft defines a document format for media-related SIP session
is independent of a specific SIP session. It also defines the Basic policies. The format extends the Profile Data Set Schema by
Session Policy Format (BSPF), which is a minimal, XML-based format specifying a data set for media properties. This draft also defines
for session policies. a delivery mechanism for session policies that is independent of a
SIP session.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Session-Independent Policy Mechanism . . . . . . . . . . . . 4 3. Session-Independent Policy Mechanism . . . . . . . . . . . . 4
3.1 Subscriber Behavior . . . . . . . . . . . . . . . . . . . 4 3.1 Subscriber Behavior . . . . . . . . . . . . . . . . . . . 4
3.2 Notifier Behavior . . . . . . . . . . . . . . . . . . . . 6 4. Basic Media Policy Format . . . . . . . . . . . . . . . . . 6
4. Policy Format Design . . . . . . . . . . . . . . . . . . . . 6 4.1 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Policy Model . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Unidirectional Policies . . . . . . . . . . . . . . . . . 7 4.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Per-Stream Policies . . . . . . . . . . . . . . . . . . . 7 4.3.1 The 'stream-label' Attribute . . . . . . . . . . . . . 7
4.4 Merging Policies . . . . . . . . . . . . . . . . . . . . . 7 4.3.2 The 'media-type' Attribute . . . . . . . . . . . . . . 7
5. Basic Session Policy Format . . . . . . . . . . . . . . . . 8 4.4 Elements . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 MIME Type and Namespace . . . . . . . . . . . . . . . . . 8 4.4.1 The <session-policy> Element . . . . . . . . . . . . . 8
5.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 4.4.2 The <context> Element . . . . . . . . . . . . . . . . 8
5.3 XML Format Definition . . . . . . . . . . . . . . . . . . 9 4.4.3 The <dialog-ID> Element . . . . . . . . . . . . . . . 8
5.3.1 The <session-policy> Element . . . . . . . . . . . . . 9 4.4.4 The <domain> Element . . . . . . . . . . . . . . . . . 9
5.3.2 The <context> Element . . . . . . . . . . . . . . . . 9 4.4.5 The <contact> Element . . . . . . . . . . . . . . . . 9
5.3.3 The <domain> Element . . . . . . . . . . . . . . . . . 10 4.4.6 The <info> Element . . . . . . . . . . . . . . . . . . 9
5.3.4 The <contact> Element . . . . . . . . . . . . . . . . 10 4.4.7 The <media-types> Element . . . . . . . . . . . . . . 9
5.3.5 The <info> Element . . . . . . . . . . . . . . . . . . 10 4.4.8 The <media-type> Element . . . . . . . . . . . . . . . 10
5.3.6 The <entity> Element . . . . . . . . . . . . . . . . . 10 4.4.9 The <codecs> Element . . . . . . . . . . . . . . . . . 10
5.3.7 The <media-types> Element . . . . . . . . . . . . . . 10 4.4.10 The <codec> Element . . . . . . . . . . . . . . . . 11
5.3.8 The <media-type> Element . . . . . . . . . . . . . . . 11 4.4.11 The <media-intermediary> Element . . . . . . . . . . 11
5.3.9 The <codecs> Element . . . . . . . . . . . . . . . . . 11 4.4.12 The <int-uri> Element . . . . . . . . . . . . . . . 12
5.3.10 The <codec> Element . . . . . . . . . . . . . . . . 12 4.4.13 The <int-addl-port> Element . . . . . . . . . . . . 12
5.3.11 The <media-intermediary> Element . . . . . . . . . . 12 4.4.14 The <int-lroute> Element . . . . . . . . . . . . . . 12
5.3.12 The <int-uri> Element . . . . . . . . . . . . . . . 13 4.4.15 The <max-bandwidth> Element . . . . . . . . . . . . 13
5.3.13 The <int-lroute> Element . . . . . . . . . . . . . . 13 4.4.16 The <qos-dscp> Element . . . . . . . . . . . . . . . 13
5.3.14 The <max-bandwidth> Element . . . . . . . . . . . . 13 4.4.17 Other Elements . . . . . . . . . . . . . . . . . . . 14
5.3.15 The <qos> Element . . . . . . . . . . . . . . . . . 14 4.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.16 Open Issue: Other Elements . . . . . . . . . . . . . 14 4.6 Schema Definition . . . . . . . . . . . . . . . . . . . . 15
5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . 19
5.5 Schema Definition . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . 18 6.1 MIME Registration for application/session-policy+xml . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 6.2 URN Sub-Namespace Registration for
7.1 MIME Registration for application/session-policy+xml . . . 18 urn:ietf:params:xml:ns:mediadataset . . . . . . . . . . . 20
7.2 URN Sub-Namespace Registration for Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
urn:ietf:params:xml:ns:sessionpolicy . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2 Informative References . . . . . . . . . . . . . . . . . . 22
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . 24
1. Introduction 1. Introduction
Some domains have policies in place, which impact the sessions Some domains have policies in place, which impact the sessions
established using the Session Initiation Protocol (SIP) [15]. These established using the Session Initiation Protocol (SIP) [15]. These
policies are often needed to support the network infrastructure or policies are often needed to support the network infrastructure or
for the execution of services. For example, wireless networks for the execution of services. For example, wireless networks
usually have limited resources for media traffic. A wireless network usually have limited resources for media traffic. A wireless network
provider may want to restrict codec usage on the network to lower provider may therefore restrict the bandwidth that is available to a
rate codecs or disallow the use of high bandwidth media types such as single user. Knowing about the bandwidth limit enables an user agent
video. to make an informed decision about the number of streams, codecs and
media types it can use in a session.
In another example, a network has a resource reservation In another example, a service provider wants to specifically restrict
infrastructure in place, which enables user agents to request Quality the set of codecs and media types that can be used in the network.
of Service (QoS) for media streams. With session policies, the These restrictions may change depending on network conditions. With
network can tell user agents that a QoS infrastructure is present and session policies, the current set of restrictions can be conveyed to
ask user agents to use specific parameters or provide certain user agents to prevent them from inadvertently violating any of the
credentials when requesting QoS. network policies.
In a third example, a user has subscribed to a service that requires In a third example, a network provides quality of service (QoS) for
the media streams to be routed through a media intermediary. The media streams through differentiated services. By knowing that
service provider would like to tell the user agent to direct the differentiated services are available and knowing the service class
media streams to this intermediary and to use a certain source assigned to media streams, a user agent can mark the packets of media
routing scheme (e.g. IP-in-IP tunneling). Knowing this policy streams accordingly and therefore benefit from the QoS
enables the user to use this service in any network from which the infrastructure.
intermediary can be reached.
Domains sometimes enforce policies they have in place. For example, Domains sometimes enforce policies they have in place. For example,
a domain might have a configuration in which all packets containing a a domain might have a configuration in which all packets containing a
certain audio codec are dropped. Unfortunately, enforcement certain audio codec are dropped. Unfortunately, enforcement
mechanisms usually do not inform the user about the policies they are mechanisms usually do not inform the user about the policies they are
enforcing and silently keep the user from doing anything against enforcing and silently keep the user from doing anything against
them. This may lead to the malfunctioning of devices that is them. This may lead to the malfunctioning of devices that is
incomprehensible to the user. With session policies, the user knows incomprehensible to the user. With session policies, the user knows
about the restricted codecs and can use a different codec or simply about the restricted codecs and can use a different codec or simply
connect to a domain with less stringent policies. Session policies connect to a domain with less stringent policies. Session policies
skipping to change at page 4, line 4 skipping to change at page 4, line 4
Session-policies can be set up in two different ways: specifically Session-policies can be set up in two different ways: specifically
for a session or independent of a session. Session-specific policies for a session or independent of a session. Session-specific policies
are created for one particular session, usually under consideration are created for one particular session, usually under consideration
of certain aspects of this session (e.g. the IP addresses and ports of certain aspects of this session (e.g. the IP addresses and ports
that are used for media). Since session-specific policies are that are used for media). Since session-specific policies are
tailored to a session, they only apply to the session they are tailored to a session, they only apply to the session they are
created for. These policies require a delivery mechanism that created for. These policies require a delivery mechanism that
enables the exchange of session policy information at the time a enables the exchange of session policy information at the time a
session is established. The framework for session-specific policies session is established. The framework for session-specific policies
[3] defines such a delivery mechanism for session-specific policies. [17] defines such a delivery mechanism for session-specific policies.
Session-independent policies on the other hand are independent of a Session-independent policies on the other hand are independent of a
specific session and generally apply to the sessions set up by a user specific session and generally apply to the sessions set up by a user
agent. An example is a policy which prohibits the use of agent. In principle, these policies could also be delivered to user
high-bandwidth codecs. In principle, these policies could also be agents individually for each session, using the session-specific
delivered to user agents individually for each session, using the policy framework. However, since these policies apply to many
session-specific policy framework. However, since these policies sessions, it is more efficient to deliver them to user agents only
apply to many sessions, it is more efficient to deliver them to user when the user agent is initialized or a policy changes. This draft
agents only when the user agent is initialized or a policy changes. defines a delivery mechanism for session-independent policies.
This draft defines a delivery mechanism for session-independent
policies.
This draft also defines the Basic Session Policy Format (BSPF). BSPF This draft also defines a document format for media-related session
is a minimal session policy format aimed at achieving policies. This format is based on XML [16]. It extends the Profile
interoperability between different user agents and policy servers. Data Set Schema [13] by specifying a data set for media properties.
This format introduces a common data model and defines a basic set of The format defines a minimal set of media-related properties [18] and
policy elements. The format is based on XML [16] and can be extended is aimed at achieving interoperability between different user agents
using XML extension mechanisms. The document format is independent and profile delivery/policy servers. The format can be extended
of the policy delivery mechanism and can be used for through the XML extension mechanisms if additional media properties
session-independent and session-specific session policies. are needed. The XML document format is independent of the delivery
mechanism and can be used with session-independent and session-
specific session policies.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, [1] and indicate requirement levels for described in BCP 14, [1] and indicate requirement levels for
compliant implementations. compliant implementations.
3. Session-Independent Policy Mechanism 3. Session-Independent Policy Mechanism
Session-independent policies can be delivered to UAs using the Session-independent policies can be delivered to UAs using the
mechanism defined in the Framework for SIP User Agent Profile mechanism defined in the Framework for SIP User Agent Profile
Delivery [12]. Session-independent policies can reside on the same Delivery [12]. Session-independent policies can reside on the same
server as other configuration information and they can be delivered server as other configuration information and they can be delivered
to UAs in conjunction with this information. Session-independent to UAs in conjunction with this information. Session-independent
policies can also reside on a separate policy server, which is policies can also reside on a separate policy server, which is
independent of a configuration server. A UA may receive independent of a configuration server. A UA may receive session-
session-independent policies from multiple policy servers. The independent policies from multiple servers.
following sections describe the subscription to the
session-independent policies relevant for a UA. In this draft, the terms policy server and profile delivery server
are used interchangeably. A policy server is a profile delivery
server that provides session policies.
3.1 Subscriber Behavior 3.1 Subscriber Behavior
A UA can express interest in session-independent policies by A UA can express interest in session-independent policies by
subscribing to session policies using the mechanism defined in [12]. subscribing to session policies as described in [12]. If the UA
If the UA has already received the URIs of all relevant session already has the URIs of policy servers (e.g., through provisioning)
policy servers (e.g., through configuration) it SHOULD use these URIs it may directly use these URIs to subscribe to session-independent
to subscribe to session-independent policies. policies.
Session-independent policies are frequently provided to a UA by the Session-independent policies are frequently provided to a UA by the
following two network domains: the domain a user registers at (i.e., following two network domains: the domain a user registers at (i.e.,
the domain in the address-of-record (AoR)) and the domain the UA is the domain in the address-of-record (AoR)) and the domain the UA is
physically connected to. A policy server in the AoR-domain may, for physically connected to (i.e. the local network domain). A policy
example, provide policies needed for services the user has subscribed server in the AoR-domain may, for example, provide policies needed
to. The domain that provides the physical network connection may for services the user has subscribed to. The domain that provides
have policies needed to ensure the operativeness of the network, the physical network connection may have policies needed to ensure
e.g., by limiting the bandwidth available to a UA. A UA SHOULD the operativeness of the network, e.g., by limiting the bandwidth
attempt to subscribe to the policy servers in both domains. These available to a UA. A UA SHOULD attempt to subscribe to the policy
subscriptions are established using the "user" (for subscriptions to servers in both domains. These subscriptions are established using
the AoR-domains) and the "local" (for subscriptions to the network the "user" (for subscriptions to the AoR-domains) and the
domain) profile-types [12]. A UA SHOULD modify these subscriptions "localnetwork" (for subscriptions to the network domain) profile-
as described below in following events: types [12].
o The UA changes the registration status of one of its AoR. This A UA SHOULD create a SUBSCRIBE request in the following events:
occurs, for example, when a UA starts up and registers its AoRs,
when it shuts down and deregisters AoRs, or when a new AoR is
added to a UA. In these events, the UA SHOULD establish
subscriptions for each new AoR using the "user" and the "local"
profile-types. It SHOULD terminate the subscriptions for all AoRs
that have been removed.
o The domain the UA is connected to changes. The UA SHOULD create a
new subscription for each AoR using the "local" profile-type. It
SHOULD terminate all existing subscriptions for the "local"
profile-type. It does not need to change the subscriptions for
"user" profiles.
If a subscriber is unable to successfully establish a subscription, o The UA registers a AoR for the first time or removes a AoR from
it SHOULD NOT attempt to re-try this subscription, unless one of the the set of AoRs it has registered. This occurs, for example, when
above events occurs again. This is to limit the number of SUBSCRIBE a UA starts up (and registers AoRs) and when it shuts down (and
requests sent within domains that do not support session-policies. deregisters AoRs). This event also occurs when a new AoR is added
to a UA or a AoR is removed. In these cases, the UA SHOULD
establish subscriptions for each new AoR using the "user" and the
"localnetwork" profile-types. It SHOULD terminate all
subscriptions for the AoRs that have been removed.
o The UA changes the domain it is connected to. The UA SHOULD
create a new subscription for each AoR using the "localnetwork"
profile-type. It SHOULD terminate all existing subscriptions for
the "localnetwork" profile-type. It does not need to change the
subscriptions for "user" profiles.
A subscriber compliant to this specification MUST indicate its If a subscriber is unable to establish a subscription, it SHOULD NOT
attempt to re-try this subscription, unless one of the above events
occurs again. This is to limit the number of SUBSCRIBE requests sent
within domains that do not support session-policies.
A subscriber compliant to this specification SHOULD indicate its
support for session-independent session policies by adding the MIME support for session-independent session policies by adding the MIME
types of supported session policy formats to the Accept header of the types of supported session policy formats to the Accept header of the
SUBSCRIBE request. This specification defines the new MIME type SUBSCRIBE request. This specification defines the new MIME type
"application/session-policy+xml", which MUST be supported by UAs "application/session-policy+xml", which MUST be supported by UAs
compliant to this specification. UAs MAY also indicate support for compliant to this specification. UAs MAY also indicate support for
MIME type extensions (e.g. an additional XML namespace) using [4]. MIME type extensions (e.g. an additional XML namespace) using [3].
A subscriber may receive a 406 in response to a SUBSCRIBE request.
This indicates that the notifier requires the support of a session
policy format that was not in the Accept header of the SUBSCRIBE
request. This means that the notifier has session policies that are
required in the network but not supported by the subscriber. As a
consequence, the subscriber may experience difficulties when setting
up a session without these policies.
3.2 Notifier Behavior
A network may have session policies in place that must be supported
by a UA. If the notifier receives a SUBSCRIBE request, which does
not list all MIME types and MIME type extensions in the Accept header
that are needed for policies, it MUST reject the request with a 406
response. A policy format is needed, if the network has policies in
this format that must be used by the UA. The notifier SHOULD NOT
return a 406 if an unsupported format contains optional policies.
4. Policy Format Design
The following sections describe design considerations for an
XML-based model for session policies.
4.1 Policy Model 4. Basic Media Policy Format
Session policies influence aspects of a SIP session by defining The Basic Media Policy Format (BMPF) is a document format for media-
constraints. A constraint impacts a specific aspect of a SIP session related policies. It extends the Profile Data Set Schema by
(e.g. the codecs that can be used in this session). Policy providing a media data set and is used to define media-related SIP
constraints are modeled as XML elements. Each policy element session policies.
expresses a certain constraint. Policy elements can contain a simple
value or act as a container, which holds multiple alternative values
for this policy.
Elements that express policies have a 'policy' attribute. This A BMPF document is an XML [16] document that MUST be well-formed and
attribute defines the constraining properties of the XML element. MUST be valid according to schemas, including extension schemas,
The following values are defined for the 'policy' attribute: available to the validator and applicable to the XML document. BMPF
documents MUST be based on XML 1.0 and MUST be encoded using UTF-8.
o mandatory: the value contained in the element is mandatory and A user agent may receive multiple BMPF documents from different
MUST be used in sessions. This is the default value that is used sources. These documents need to merged into a single document the
if the 'policy' attribute is omitted. user agent can work with. General rules for merging BMPF documents
o allow: the value contained in the element is allowed and MAY be are described in [13]. Specific merging rules for each of the BMPF
used in sessions. elements are described below.
o disallow: the value contained in the element is forbidden and MUST
NOT be used in sessions.
Polices consisting of one single value can be expressed by a simple 4.1 Namespace
policy element. The following is an example of a policy defining an
upper limit for media bandwidth:
<max-bandwidth>80</max-bandwidth> 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 BMPF schema is:
Policies consisting of multiple values can be expressed using a urn:ietf:params:xml:ns:mediadataset
container element. The container contains multiple elements, which
define possible values. The policy attribute of the container
specifies the policy that applies to all values not listed in the
container. The policy attribute of each element in the container
defines the policy for that item. The following example shows a
policy that requires the media type audio and allows video in
sessions:
<media-types policy="disallow"> The MIME type for the Basic Media Policy Format is:
<media-type policy="mandatory">audio</media-type>
<media-type policy="allow">video</media-type>
</media-types>
4.2 Unidirectional Policies application/session-policy+xml
Some policies only affect media streams flowing into one direction, ISSUE: a separate MIME type might not be needed for BMPF. The
e.g., only outgoing streams. Unidirectional policies can be MIME type of the Profile Data Set Schema may be sufficient. We
expressed by adding a 'direction' attribute to the respective policy still need a separate namespace.
element.
The 'direction' attribute can have the following values: 4.2 Extensibility
o recvonly: the policy only applies to incoming streams. The BMPF format is an extension of the Profile Data Set Schema [13].
o sendonly: the policy only applies to outgoing streams. Elements from the BMPF namespace can be used in conjunction with
o sendrecv: the policy applies to streams in both directions. This elements from other Profile Data Sets.
is the default value that is used if the 'direction' attribute is
omitted.
4.3 Per-Stream Policies The BMPF format itself can also be extended using XML extension
mechanisms. In particular, elements from different XML namespaces
MAY be present within a BMPF document for the purposes of
extensibility; elements or attributes from unknown namespaces MUST be
ignored.
Policies can be specific to a certain media stream. The stream to 4.3 Attributes
which a policy applies to must be identifiable through a label [7].
Per-stream policies can be expressed by adding a 'label' attribute to
the respective policy element. Such a policy only applies to the
identified stream. If the label value is unknown to the recipient,
the policy must be ignored.
Per-stream policies require that the policy server has access to the The following attributes provide common functionalities, which are
session description in order to extract the stream label. For this generally useful for media properties:
reason, per-stream policies are typically used in session-specific
policies.
4.4 Merging Policies o Per-stream properties: 'stream-label' attribute
o Media-type specific properties: 'media-type' attribute
A UA may receive policy documents from multiple sources, which need These attributes are defined in addition to the attributes inherited
to be merged into a single combined policy document the UA can work from the Profile Data Set Schema [13]:
with.
Policies that define a single value (e.g. maximum bandwidth) require o Property Access Control: 'visibility' attribute
the selection of one value during the merging process. The selection o Policies: 'policy' and 'excluded-policy' attribute
criteria must be defined individually for each element (e.g. select o Unidirectional Properties: 'direction' attribute
lowest value) in the schema definition. o Preferences: 'q' attribute
Policies that allow multiple values can be merged by combining all The use of these attributes is defined individually for each element
values and adjusting the 'policy' attribute for values that exist in in the XML format below.
both documents. Table 1 provides a matrix for merging the 'policy'
attributes. Additional merging rules may be required for some
elements. They must be specified in the schema definition.
Some constellations are not feasible and constitute a policy conflict 4.3.1 The 'stream-label' Attribute
that can not be resolved automatically. If the conflicting policies
are enforced by the network, the UA may experience difficulties when
setting up a session.
pol 1 \ pol 2 | mandatory | allow | disallow Some properties only apply to a specific media stream. The stream to
--------------+-----------+-----------+----------- which a property applies to must be identifiable through a label [6].
mandatory | mandatory | mandatory | conflict! Per-stream properties can be expressed by adding a 'stream-label'
allow | mandatory | allow | disallow attribute to the respective element. Such a property only applies to
disallow | conflict! | disallow | disallow the identified stream. If there is no stream with this label, the
element must be ignored.
Table 1: merging policies. 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, for example, part of the session
description. Per-stream properties are therefore typically used for
session-specific policies.
The combined policy MUST again be valid and well-formed according to 4.3.2 The 'media-type' Attribute
policy schema definitions. A policy conflict occurs if the combined
policy is not a well-formed document after the merging process is
completed.
5. Basic Session Policy Format 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 Basic Session Policy Format (BSPF) defines the structure of and a The value of the 'media-type' attribute MUST be the name of a IANA
root element for session policy documents. It provides a minimal set registered media type (see [2]), such as 'audio', 'video', 'text', or
of policy elements as required by [14]. To enable interoperability 'application'.
between UAs and policy servers, this format MUST be supported by all
UAs compliant to this specification.
Note: It is the goal to keep this specification aligned with the 4.4 Elements
schema for user agent profile data sets [13] to simplify the
processing of policy and configuration data.
5.1 MIME Type and Namespace The following elements are defined for the BMPF format.
The MIME type for the Basic Session Policy Format is: 4.4.1 The <session-policy> Element
application/session-policy+xml The <session-policy> element is a container for media policy
elements. It MAY occur multiple times inside a <property_set> [13]
element.
This specification makes use of XML namespaces [5]. The namespace The <session-policy> element MAY contain one optional <context>
URIs for schemas defined in this specification are URNs [8], using element and multiple (including zero) <media-types>, <codecs>,
the namespace identifier 'ietf' defined by [9] and extended by [6]. <media-intermediary>, <qos-dscp>, and <max-bandwidth> elements as
The namespace URN for the BSPF schema is: well as elements from other namespaces.
urn:ietf:params:xml:ns:sessionpolicy OPEN ISSUE: the <session-policy> seems to have pretty much the
same functionality as the <property_set> element. Maybe it needs
to be removed and the context element needs to go into the Profile
Data Set Schema.
5.2 Extensibility 4.4.2 The <context> Element
The BSPF format can be extended using XML extension mechanisms. In The <context> element provides context information about this policy.
particular, elements from different XML namespaces MAY be present
within a BSPF document for the purposes of extensibility; elements or
attributes from unknown namespaces MUST be ignored.
5.3 XML Format Definition The <context> element is optional in a <session-policy> element. It
MAY contain a <dialog-ID>, <domain>, multiple <contact> and an <info>
element.
A BSPF document is an XML [16] document that MUST be well-formed and Merging rule: the <context> element is not subject to merging.
MUST be valid according to schemas, including extension schemas, Information in the context element may be used to assist the user
available to the validator and applicable to the XML document. BSPF if a conflict occurs during the merging process.
documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. Policies that affect different sessions (i.e. have different
<dialog-ID> values) are not merged.
5.3.1 The <session-policy> Element 4.4.3 The <dialog-ID> Element
The root element of a BSPF document is the <session-policy> element. Session-specific policies only apply to one particular session. The
<dialog-ID> element is used to identify this session. If this
element is present the <context> element of a <session-policy>
container, all properties defined in this container only apply to the
identified session. A single document may contain multiple <session-
policy> containers, which each contains a different <dialog-ID>
element. This way, session-specific policies for different sessions
can be contained in one document. If the user agent does not have a
session with this dialog-ID, the content of the respective <session-
policy> container MUST be ignored.
The <session-policy> element MAY contain an optional <context> The <dialog-ID> element is optional in a <context> element. It MUST
element and multiple (including zero) <media-types>, <codecs>, contain a <call-ID> and a <local-tag> and MAY contain a <remote-tag>
<media-intermediary>, <qos>, and <max-bandwidth> elements as well as element.
elements from other namespaces.
5.3.2 The <context> Element The <call-ID> element contains the call-ID (as defined in [15]) of
the session the policies are for.
The <context> element provides context information about this policy. The <local-tag> element contains the local tag (as defined in [15])
of the session the policies are for.
The <context> element is optional in a <session-policy> element. It The <remote-tag> element contains the remote tag (as defined in [15])
MAY contain a <domain>, multiple <contact>, a <info>, and multiple of the session the policies are for. If the remote tag element is
<entity> elements. omitted, the policies apply to all sessions that have the given
call-ID and local tag.
Merging policies: the <context> element is not subject to merging. Local and remote tags are defined from the viewpoint of the recipient
Information in the context element may be used to assist the user of the document.
if a policy conflict occurs. Policies that affect different
entities (e.g. different AoRs) on a user agent and therefore have
different <entity> values do not need to be merged. A policy
affecting all entities on a user agent (i.e. no <entity> element
is specified) must be merged with the policy for a specific
entity.
5.3.3 The <domain> Element 4.4.4 The <domain> Element
The <domain> element contains a URI that identifies the domain which The <domain> element contains a URI that identifies the domain which
has issued this policy. has issued this policy.
The <domain> element is optional and MAY occur only once inside a The <domain> element is optional and MAY occur only once inside a
<context> element. <context> element.
5.3.4 The <contact> Element 4.4.5 The <contact> Element
The <contact> element contains a contact address (e.g. a SIP URI or The <contact> element contains a contact address (e.g. a SIP URI or
email address) under which the issuer of this policy can be reached. email address) under which the issuer of this policy can be reached.
The <contact> element is optional and MAY occur multiple times inside The <contact> element is optional and MAY occur multiple times inside
a <context> element. a <context> element.
5.3.5 The <info> Element 4.4.6 The <info> Element
The <info> element provides a short textual description of the policy The <info> element provides a short textual description of the policy
that should be intelligible to the human user. that should be intelligible to the human user.
The <info> element is optional and MAY occur only once inside a The <info> element is optional and MAY occur only once inside a
<context> element. <context> element.
5.3.6 The <entity> Element 4.4.7 The <media-types> Element
The <entity> element contains a URI that identifies the user or
device whose policy information is reported in this policy instance.
The policy only applies to the sessions that involve this entity. If
this element is not present, the policy applies to all entities on a
UA.
The <entity> element is optional and MAY occur multiple times inside
a <context> element.
5.3.7 The <media-types> Element
The <media-types> element expresses a policy for the use of media The <media-types> element expresses a policy for the use of media
types (e.g. audio, video). A policy defines the media types that types (e.g. audio, video). It defines the media types that must be
must be used, may be used, or must not be used in a session. used, may be used, and must not be used in a session.
This element has an mandatory 'policy' attribute as defined in This element may have the following attributes (see Section 4.3):
Section 4.1. The 'policy' attribute specifies the default policy for
all media types that are not listed inside this element.
This element has an optional 'direction' attribute as defined in visibility, excluded-policy, direction. The 'excluded-policy'
Section 4.2. attribute specifies the default policy for all media types that are
not listed inside this element.
The <media-types> element is optional in a <session-policy> element The <media-types> element is optional in a <session-policy> element
and MAY occur multiple times. It MUST contain one or more and MAY occur multiple times. Multiple <media-types> elements MAY
<media-type> elements. only be present 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 policies: the 'policy' attribute of the <media-types> Merging rule: <media-types> containers are merged using the
element and <media-type> elements with the same value is adjusted "Multiple Enumerated Value Merging Algorithm" defined in [13].
according to Table 1.
5.3.8 The <media-type> Element 4.4.8 The <media-type> Element
The <media-type> element defines a policy for the use of the media The <media-type> element defines a policy for the use of the media
type identified by this elements value. This value MUST be the name type identified by this element. The value of this element MUST be
of a IANA registered media type (see [2]), such as 'audio', 'video', the name of a IANA registered media type (see [2]), such as 'audio',
'text', or 'application'. 'video', 'text', or 'application'.
This element has a mandatory 'policy' attribute as defined in Section This element may have the following attributes (see Section 4.3):
4.1. policy, q. Media types that have the policy 'mandatory' MUST be used
in a session, media types with the policy 'allowed' MAY be used and
media types with the policy 'disallowed' MUST NOT be used.
The <media-type> element is mandatory and MAY occur multiple times The <media-type> element is mandatory and MAY occur multiple times
inside a <media-types> element. inside a <media-types> element.
5.3.9 The <codecs> Element 4.4.9 The <codecs> Element
The <codecs> element expresses a policy for the use of codecs. A The <codecs> element expresses a policy for the use of codecs. A
policy can define that a codec must be used, may be used, or must not policy can define that a codec must be used, may be used, or must not
be used in a session. A policy MUST allow the use of at least one be used in a session. A policy MUST allow the use of at least one
codec and MUST NOT define more than one mandatory codec for a media codec and MUST NOT define more than one mandatory codec for a media
type. type.
This element has a mandatory 'policy' attribute as defined in Section This element may have the following attributes (see Section 4.3):
4.1. The 'policy' attribute specifies the default policy for all visibility, excluded-policy, direction, stream-label. The 'excluded-
codecs that are not listed inside this element. policy' attribute specifies the default policy for all codecs that
are not listed inside this element.
This element has an optional 'direction' attribute as defined in
Section 4.2.
This element has an optional 'label' attribute as defined in Section
4.3.
The <codecs> element is optional in a <session-policy> element and The <codecs> element is optional in a <session-policy> element and
MAY occur multiple times. It MUST contain one or more <codec> MAY occur multiple times. Multiple <codecs> elements MAY only be
elements. present 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 policies: the 'policy' attribute of the <codecs> element Merging rule: <codecs> containers are merged using the "Multiple
and <codec> elements with the same value is adjusted according to Enumerated Value Merging Algorithm" defined in [13].
Table 1.
5.3.10 The <codec> Element 4.4.10 The <codec> Element
The <codec> element defines a policy for the use of the codec The <codec> element defines a policy for the use of the codec
identified by this elements value. This value MUST be the name of a identified by this element. The value of this element MUST be the
registered MIME type for a encoding (see [2]), such as "PCMA", name of a registered MIME type for a encoding (see [2]), such as
"G729", or "H263". "PCMA", "G729", or "H263".
This element has a mandatory 'policy' attribute as defined in Section This element may have the following attributes (see Section 4.3):
4.1. policy, q. Codecs that have the policy 'mandatory' MUST be used in a
session, codecs with the policy 'allowed' MAY be used and codecs with
the policy 'disallowed' MUST NOT be used.
The <codec> element is mandatory and MAY occur multiple times inside The <codec> element is mandatory and MAY occur multiple times inside
a <codecs> element. a <codecs> element.
5.3.11 The <media-intermediary> Element 4.4.11 The <media-intermediary> Element
The <media-intermediary> element expresses a policy for routing a The <media-intermediary> element expresses a policy for routing a
media stream through a media intermediary. The purpose of the media stream through a media intermediary. The purpose of the
<media-intermediary> element is to tell the UA to send the media for <media-intermediary> element is to tell the UA to send the media for
a particular stream through an IP address and port of an a particular stream through an IP address and port on an
intermediary. Instead of merely sending the media there, the UA can intermediary. Instead of merely sending the media there, the UA can
instead specify a source route, which touches that intermediary, but instead specify a source route, which touches that intermediary, but
also any other intermediaries and then the final recipient. Thus, if also any other intermediaries and then the final recipient. Thus, if
there are N hops, including the final recipient, there needs to be a there are N hops, including the final recipient, there needs to be a
way for the media stream to specify N destinations. The way these N way for the media stream to specify N destinations. The way these N
destinations should be identified when sending the media stream is destinations should be identified when sending the media stream is
expressed using the <int-lroute> element. expressed using the <int-lroute> element.
This element has a mandatory 'policy' attribute as defined in Section This element may have the following attributes (see Section 4.3):
4.1). This attribute defines whether routing media streams through visibility, policy, direction, stream-label.
this intermediary is mandatory or allowed.
This element has an optional 'label' attribute as defined in Section
4.3.
The <media-intermediary> element is optional in a <session-policy> The <media-intermediary> element is optional in a <session-policy>
element and MAY occur multiple times. The order of element and MAY occur multiple times. The order of <media-
<media-intermediary> element instances is significant. It defines intermediary> element instances is significant. It defines the order
the order in which the media intermediaries must be traversed. The in which the media intermediaries must be traversed. The UA sends
UA sends the media stream to the intermediary listed first, then to the media stream to the intermediary listed first, then to the
the intermediary listed next and so on. The <media-intermediary> intermediary listed next and so on. The <media-intermediary> element
element MUST contain one <int-uri> and one <int-lroute> element. MUST contain one <int-uri> and one <int-lroute> element.
Merging policies: the intermediaries defined in all policies are
traversed. For session-independent policies, intermediaries
received through a subscription using the "local" profile-type are
traversed before those received through a "user" profile-type
subscription. For session-specific policies, intermediaries are
traversed in the order in which policy URIs are received (i.e.
local intermediaries first). 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-
intermediary> element values from different servers are ordered
using the "Closest Value First Merging Algorithm" [13]. The
intermediaries should be traversed in this order.
5.3.12 The <int-uri> Element 4.4.12 The <int-uri> Element
The <int-uri> element contains a URI that identifies the IP address 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 and port number of a media intermediary. The UA uses this URI to
send its media streams to the intermediary. If a protocol uses send its media streams to the intermediary. If a protocol uses
multiple subsequent ports (e.g. RTP) only the lowest port number multiple subsequent ports (e.g. RTP), the lowest port number SHOULD
needs to be identified. be included in the URI. All additional port numbers SHOULD be
identified in <int-addl-port> elements.
The <int-uri> element occurs exactly once inside a The <int-uri> element occurs exactly once inside a <media-
<media-intermediary> element. intermediary> element.
5.3.13 The <int-lroute> Element 4.4.13 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.
The <int-addl-port> element is optional and MAY occur multiple times
inside a <media-intermediary> element.
4.4.14 The <int-lroute> Element
The <int-lroute> element identifies the loose source routing protocol The <int-lroute> element identifies the loose source routing protocol
to be used with this intermediary. The value of this element can be to be used with this intermediary. The value of this element can be
one of the following: one of the following:
o ip-in-ip: IP-in-IP tunneling is used to specify the hops of media o ip-in-ip: IP-in-IP tunneling is used to specify the hops of media
traversal. The ultimate destination is specified in the traversal. The ultimate destination is specified in the
destination IP of the innermost packet. Each subsequent hop destination IP address of the innermost packet. Each subsequent
results in another encapsulation, with the destination of that hop hop results in another encapsulation, with the destination of that
in the destination IP address of the packet. hop in the destination IP address of the packet.
o ip-loose: IP provides a loose routing mechanism that allows the o ip-loose: IP provides a loose routing mechanism that allows the
sender of an IP datagram to specify a set of IP addresses that are 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. to be visited on the way before reaching the final destination.
o turn: TURN provides a mechanism for inserting a media relay into
the 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.
o media-specific: media protocols can provide their own loose o media-specific: media protocols can provide their own loose
routing mechanism. If that is the case, the loose routing routing mechanism. If that is the case, the loose routing
mechanism of that protocol is used. As an example, SIP provides mechanism of that protocol is used. As an example, SIP provides
its own loose routing mechanisms with the Route header. It can be its own loose routing mechanisms with the Route header. It can be
used to direct an instant message using the SIP MESSAGE method used to direct an instant message using the SIP MESSAGE method
through a set of intermediaries. through a set of intermediaries.
o none: if there is no loose-routing mechanism available, the media o none: if there is no loose-routing mechanism available, the media
is just sent to the first media intermediary listed in the header. is just sent to the first media intermediary listed in the header.
Note that this requires the intermediary to know where to forward Note that this requires the intermediary to know where to forward
the packets to. Such a route must be set up in the intermediary the packets to. Such a route must be set up in the intermediary
through other means. For example, with session-specific policies, through other means. For example, with session-specific policies,
the policy server can extract the destination address from the the policy server can extract the destination address from the
session description. session description.
The <int-lroute> element occurs exactly once inside a The <int-lroute> element occurs exactly once inside a <media-
<media-intermediary> element. intermediary> element.
5.3.14 The <max-bandwidth> Element 4.4.15 The <max-bandwidth> Element
The <max-bandwidth> element contains the maximum bandwidth in The <max-bandwidth> element contains the maximum bandwidth in
kilobits per second an entity can use for its media streams. kilobits per second an entity can use for its media streams.
This element has an optional 'direction' attribute as defined in This element may have the following attributes (see Section 4.3):
Section 4.2. If the direction attribute is present, the visibility, policy, direction, media-type.
<max-bandwidth> element contains the bandwidth available in the
identified direction.
The <max-bandwidth> element is optional in a <session-policy> element The <max-bandwidth> element is optional and MAY occur multiple times
and MAY occur only once. inside a <session-policy> element. If it occurs multiple times, each
instance MUST apply to different media streams (i.e. one <max-
bandwidth> element for outgoing and one for incoming streams).
Merging policies: the lowest max-bandwidth value is used. Merging rule: the lowest max-bandwidth value is used.
Open issue: The maximum bandwidth policy is not part of the policy 4.4.16 The <qos-dscp> Element
requirements. Should it be part of BSPF?
5.3.15 The <qos> Element The <qos-dscp> element contains an Differentiated Services Codepoint
(DSCP) [10] 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.
Open issue: what needs to go in here? This element may have the following attributes (see Section 4.3):
visibility, policy, direction, stream-label, media-type.
5.3.16 Open Issue: Other Elements The <qos-dscp> element is optional and MAY occur multiple times
inside a <session-policy> element. If it 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 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"
[13]. The DSCP value from the closest server is used.
4.4.17 Other Elements
A number of additional elements have been proposed for a policy A number of additional elements have been proposed for a policy
language: language. These elements are deemed to be outside the scope of a
basic media policy format. However, they may be defined in
extensions of BMPF or other profile data sets.
o maximum number of streams o maximum number of streams
o maximum number of sessions o maximum number of sessions
o maximum number of streams per session o maximum number of streams per session
o maximum bandwidth per session o maximum bandwidth per session
o maximum bandwidth per stream o maximum bandwidth per stream
o external address and port o external address and port
o media transport protocol o media transport protocol
o outbound proxy o outbound proxy
o SIP methods o SIP methods
o SIP option tags o SIP option tags
o SIP transport protocol o SIP transport protocol
o body disposition o body disposition
o body format o body format
o body encryption o body encryption
Is it desirable to add any of these to the BSPF format? Some of these 4.5 Example
items could become part of an extension to BSPF.
5.4 Example
The following example describes a policy that requires the use of The following example describes a policy that requires the use of
audio, allows the use of video and prohibits the use of other media audio, allows the use of video and prohibits the use of other media
types. It allows the use of any codec except G.723 and G.729. The 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. policy also inserts a media intermediary into outgoing media streams.
<property-set>
<session-policy> <session-policy>
<context> <context>
<domain>example.com</domain> <domain>example.com</domain>
<contact>sip:policy_manager@example.com</contact> <contact>sip:policy_manager@example.com</contact>
<info>Access network policies</info> <info>Access network policies</info>
</context> </context>
<media-types policy="disallow"> <media-types excluded-policy="disallow">
<media-type policy="mandatory">audio</media-type> <media-type policy="mandatory">audio</media-type>
<media-type policy="allow">video</media-type> <media-type policy="allow">video</media-type>
</media-types> </media-types>
<codecs policy="allow"> <codecs excluded-policy="allow">
<codec policy="disallow">G729</codec> <codec policy="disallow">G729</codec>
<codec policy="disallow">G723</codec> <codec policy="disallow">G723</codec>
</codecs> </codecs>
<media-intermediary direction="sendonly" policy="mandatory"> <media-intermediary direction="sendonly" policy="mandatory">
<int-uri>123.234.123.234:6000</int-uri> <int-uri>192.0.2.0:6000</int-uri>
<int-addl-port>6001</int-addl-port>
<int-lroute>ip-in-ip</int-lroute> <int-lroute>ip-in-ip</int-lroute>
</media-intermediary> </media-intermediary>
</session-policy> </session-policy>
</property-set>
5.5 Schema Definition 4.6 Schema Definition
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:sessionpolicy" <xs:schema targetNamespace="urn:ietf:params:xml:ns:mediadataset"
xmlns:tns="urn:ietf:params:xml:ns:sessionpolicy" xmlns:tns="urn:ietf:params:xml:ns:mediadataset"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" xmlns:spds="http://sipfoundry.org/schema/profile-data-sets-00">
attributeFormDefault="unqualified">
<xs:element name="session-policy" type="tns:session-policy"/> <xs:attributeGroup name="single_stream_attributes" >
<xs:attribute name="stream-label"
type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:complexType name="session-policy"> <xs:attributeGroup name="media_type_attributes" >
<xs:attribute name="media-type"
type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:element name="session-policy">
<xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="context" type="tns:context" minOccurs="0" <xs:element ref="tns:context"
maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="media-types" type="tns:media-types" <xs:element ref="tns:media-types"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="codecs" type="tns:codecs" minOccurs="0" <xs:element ref="tns:codecs"
maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="media-intermediary" <xs:element ref="tns:media-intermediary"
type="tns:media-intermediary" minOccurs="0" minOccurs="0" maxOccurs="unbounded"/>
maxOccurs="unbounded"/> <xs:element ref="tns:max-bandwidth"
<xs:element name="max-bandwidth" type="tns:max-bandwidth" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:qos-dscp"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:complexType name="context"> <xs:element name="context">
<xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="tns:dialog-ID"
minOccurs="0" maxOccurs="1"/>
<xs:element name="domain" type="xs:anyURI" minOccurs="0" <xs:element name="domain" type="xs:anyURI" minOccurs="0"
maxOccurs="1"/> maxOccurs="1"/>
<xs:element name="contact" type="xs:anyURI" minOccurs="0" <xs:element name="contact" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="info" type="xs:string" <xs:element name="info" type="xs:string"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="entity" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:complexType name="media-types"> <xs:element name="media-types"
substitutionGroup="spds:setting_container">
<xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="media-type" type="tns:media-type" minOccurs="1" <xs:element ref="tns:media-type"
maxOccurs="unbounded"/> minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="policy" type="tns:policyValue" <xs:attributeGroup ref="spds:directional_setting_attributes" />
use="required"/>
<xs:attribute name="direction" type="tns:directionValue"
use="optional" default="sendrecv"/>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:complexType name="codecs"> <xs:element name="codecs"
substitutionGroup="spds:setting_container">
<xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="codec" type="tns:codec" minOccurs="1" <xs:element ref="tns:codec"
maxOccurs="unbounded"/> minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="policy" type="tns:policyValue" <xs:attributeGroup ref="spds:directional_setting_attributes" />
use="required"/> <xs:attributeGroup ref="tns:single_stream_attributes" />
<xs:attribute name="direction" type="tns:directionValue"
use="optional" default="sendrecv"/>
<xs:attribute name="label" type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:complexType name="media-intermediary"> <xs:element name="media-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="int-uri" type="xs:anyURI" minOccurs="1" <xs:element name="int-uri" type="xs:anyURI"
maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<xs:element name="int-lroute" type="tns:int-lroute" minOccurs="1" <xs:element name="int-addl-port"
maxOccurs="1"/> type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="int-lroute" type="tns:int-lroute"
minOccurs="1" maxOccurs="1"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="policy" type="tns:policyValue" <xs:attributeGroup ref="spds:directional_setting_attributes" />
use="required"/> <xs:attributeGroup ref="tns:single_stream_attributes" />
<xs:attribute name="label" type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:complexType name="max-bandwidth"> <xs:element name="max-bandwidth"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:positiveInteger"> <xs:extension base="xs:positiveInteger" />
<xs:attribute name="policy" type="tns:policyValue"
use="required"/>
</xs:extension>
</xs:simpleContent> </xs:simpleContent>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:media_type_attributes" />
</xs:complexType> </xs:complexType>
</xs:element>
<xs:complexType name="media-type"> <xs:element name="qos-dscp"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:restriction base="xs:integer" >
<xs:attribute name="policy" type="tns:policyValue" <xs:minInclusive value="0" />
use="required"/> <xs:maxInclusive value="63" />
</xs:extension> </xs:restriction>
</xs:simpleContent> </xs:simpleContent>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
<xs:attributeGroup ref="tns:media_type_attributes" />
</xs:complexType> </xs:complexType>
</xs:element>
<xs:complexType name="codec"> <xs:element name="dialog-ID">
<xs:complexType>
<xs:sequence>
<xs:element name="call-ID" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="local-tag" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="remote-tag" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="media-type"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:restriction base="xs:string" />
<xs:attribute name="policy" type="tns:policyValue"
use="required"/>
</xs:extension>
</xs:simpleContent> </xs:simpleContent>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType> </xs:complexType>
</xs:element>
<xs:element name="codec"
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:simpleType name="int-lroute"> <xs:simpleType name="int-lroute">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="ip-in-ip"/> <xs:enumeration value="ip-in-ip"/>
<xs:enumeration value="ip-loose"/> <xs:enumeration value="ip-loose"/>
<xs:enumeration value="turn"/>
<xs:enumeration value="media-specific"/> <xs:enumeration value="media-specific"/>
<xs:enumeration value="none"/> <xs:enumeration value="none"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="policyValue">
<xs:restriction base="xs:string">
<xs:enumeration value="mandatory"/>
<xs:enumeration value="allow"/>
<xs:enumeration value="disallow"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="directionValue">
<xs:restriction base="xs:string">
<xs:enumeration value="sendrecv"/>
<xs:enumeration value="sendonly"/>
<xs:enumeration value="recvonly"/>
</xs:restriction>
</xs:simpleType>
</xs:schema> </xs:schema>
6. Security Considerations 5. Security Considerations
Session policy information can be sensitive information. The Session policy information can be sensitive information. The
protocol used to distribute it SHOULD ensure privacy, message protocol used to distribute it SHOULD ensure privacy, message
integrity and authentication. Furthermore, the protocol SHOULD integrity and authentication. Furthermore, the protocol SHOULD
provide access controls which restrict who can see who else's session provide access controls which restrict who can see who else's session
policy information. policy information.
7. IANA Considerations 6. IANA Considerations
This document registers a new MIME type, This document registers a new MIME type, application/
application/session-policy+xml, and registers a new XML namespace. session-policy+xml, and registers a new XML namespace.
7.1 MIME Registration for application/session-policy+xml 6.1 MIME Registration for application/session-policy+xml
MIME media type name: application MIME media type name: application
MIME subtype name: session-policy+xml MIME subtype name: session-policy+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [10]. specified in RFC 3023 [9].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [10]. application/xml as specified in RFC 3023 [9].
Security considerations: See Section 10 of RFC 3023 [10] and Section Security considerations: See Section 10 of RFC 3023 [9] and Section 5
6 of this specification. of this specification.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to download the session policy of a domain to SIP user agents. used to download the session policy of a domain to SIP user agents.
Additional Information: Additional Information:
skipping to change at page 19, line 15 skipping to change at page 20, line 4
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .wif or .xml File Extension: .wif or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Volker Hilt, Personal and email address for further information: Volker Hilt,
<volkerh@bell-labs.com> <volkerh@bell-labs.com>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
7.2 URN Sub-Namespace Registration for 6.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:sessionpolicy urn:ietf:params:xml:ns:mediadataset
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[6] [5]
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:sessionpolicy. urn:ietf:params:xml:ns:mediadataset.
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Volker Hilt, <volkerh@bell-labs.com> Volker Hilt, <volkerh@bell-labs.com>
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Session Policy Namespace</title> <title>Session Policy Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Session Policy Information</h1> <h1>Namespace for Session Policy Information</h1>
<h2>urn:ietf:params:xml:ns:sessionpolicy</h2> <h2>urn:ietf:params:xml:ns:mediadataset</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
8 References 7. References
7.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session [2] Handley, M., "SDP: Session Description Protocol",
Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005.
progress), September 2004.
[3] Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for
Session-Specific Session Policies in the Session Initiation
Protocol (SIP)", draft-hilt-sipping-session-spec-policy-01
(work in progress), October 2004.
[4] Hilt, V., Rosenberg, J. and G. Camarillo, "Media Type Extension [3] Hilt, V., Rosenberg, J., and G. Camarillo, "Media Type
Negotiation in the Session Initiation Protocol (SIP) Accept Extension Negotiation in the Session Initiation Protocol (SIP)
Header Field", draft-hilt-sip-ext-neg-00 (work in progress), Accept Header Field", draft-hilt-sip-ext-neg-00 (work in
January 2005. progress), January 2005.
[5] Hollander, D., Bray, T. and A. Layman, "Namespaces in XML", W3C [4] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML",
REC REC-xml-names-19990114, January 1999. W3C REC REC-xml-names-19990114, January 1999.
[6] Mealling, M., "The IETF XML Registry", [5] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June draft-mealling-iana-xmlns-registry-05 (work in progress),
2003. June 2003.
[7] Levin, O. and G. Camarillo, "The SDP (Session Description [6] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute", Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-01 (work in progress), draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005. January 2005.
[8] Moats, R., "URN Syntax", RFC 2141, May 1997. [7] Moats, R., "URN Syntax", RFC 2141, May 1997.
[9] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [8] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[10] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC [9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
3023, January 2001. RFC 3023, January 2001.
[11] Perkins, C., "IP Encapsulation within IP", RFC 2003, October [10] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
1996. 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., "A Framework for Session Initiation Protocol User [12] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-05 Agent Profile Delivery", draft-ietf-sipping-config-framework-06
(work in progress), October 2004. (work in progress), February 2005.
[13] Petrie, D., "A Schema for Session Initiation Protocol User [13] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and
Agent Profile Data Sets", Guidelines for Defining Session Initiation Protocol User Agent
draft-petrie-sipping-profile-datasets-00 (work in progress), Profile Data Sets", draft-petrie-sipping-profile-datasets-02
July 2004. (work in progress), April 2005.
[14] Rosenberg, J., "Requirements for Session Policy for the Session [14] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
Initiation Protocol (SIP)", draft-rosenberg-midcom-turn-07 (work in progress),
draft-ietf-sipping-session-policy-req-02 (work in progress), February 2005.
July 2004.
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[16] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T. and E. [16] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E.
Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C REC REC-xml-20040204, February 2004. W3C REC REC-xml-20040204, February 2004.
7.2 Informative References
[17] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for
Session-Specific Session Policies in the Session Initiation
Protocol (SIP)", draft-hilt-sipping-session-spec-policy-01
(work in progress), October 2004.
[18] Rosenberg, J., "Requirements for Session Policy for the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-session-policy-req-02 (work in progress),
July 2004.
Authors' Addresses Authors' Addresses
Volker Hilt Volker Hilt
Bell Labs/Lucent Technologies Bell Labs/Lucent Technologies
101 Crawfords Corner Rd 101 Crawfords Corner Rd
Holmdel, NJ 07733 Holmdel, NJ 07733
USA USA
EMail: volkerh@bell-labs.com Email: volkerh@bell-labs.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
USA USA
EMail: jdrosen@cisco.com Email: jdrosen@cisco.com
Appendix A. Acknowledgements Appendix A. Acknowledgements
Many thanks to Allison Mankin for the discussions and the suggestions Many thanks to Allison Mankin, Dan Petrie and Martin Dolly for the
for this draft. Many thanks also to Dan Petrie and Martin Dolly. great discussions and suggestions. A big thanks also to everyone who
contributed by providing feedback on the mailing list and in IETF
meetings.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/