draft-ietf-sipping-session-indep-policy-01.txt   draft-ietf-sipping-session-indep-policy-02.txt 
Session Initiation Proposal V. Hilt SIPPING Working Group V. Hilt
Investigation Working Group Bell Labs/Lucent Technologies Internet-Draft Bell Labs/Lucent Technologies
Internet-Draft G. Camarillo Expires: August 10, 2005 G. Camarillo
Expires: April 24, 2005 Ericsson Ericsson
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
October 24, 2004 February 9, 2005
Session-Independent Session Initiation Protocol (SIP) Policies - Session Initiation Protocol (SIP) Session Policies - Document Format
Mechanism and Policy Schema and Session-Independent Delivery Mechanism
draft-ietf-sipping-session-indep-policy-01 draft-ietf-sipping-session-indep-policy-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 24, 2005. This Internet-Draft will expire on August 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This draft specifies an XML schema for profile data for SIP This draft defines a delivery mechanism for SIP session policies that
session-policies. It defines a delivery mechanism for SIP is independent of a specific SIP session. It also defines the Basic
session-policies that are independent of a specific SIP session. Session Policy Format (BSPF), which is a minimal, XML-based format
for session policies.
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 3.2 Notifier Behavior . . . . . . . . . . . . . . . . . . . . 6
4. Session Policy Schemas . . . . . . . . . . . . . . . . . . . . 6 4. Policy Format Design . . . . . . . . . . . . . . . . . . . . 6
4.1 Specifying Constraints . . . . . . . . . . . . . . . . . . 6 4.1 Policy Model . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Unidirectional Policies . . . . . . . . . . . . . . . . . 7
4.3 General Policy Schema . . . . . . . . . . . . . . . . . . 7 4.3 Per-Stream Policies . . . . . . . . . . . . . . . . . . . 7
4.3.1 Elements and Attributes . . . . . . . . . . . . . . . 8 4.4 Merging Policies . . . . . . . . . . . . . . . . . . . . . 7
4.4 Media Policy Schema . . . . . . . . . . . . . . . . . . . 9 5. Basic Session Policy Format . . . . . . . . . . . . . . . . 8
4.4.1 Elements and Attributes . . . . . . . . . . . . . . . 9 5.1 MIME Type and Namespace . . . . . . . . . . . . . . . . . 8
4.4.2 Conflict Resolution . . . . . . . . . . . . . . . . . 11 5.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
4.4.3 Example . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 XML Format Definition . . . . . . . . . . . . . . . . . . 9
4.5 Protocol Policy Schema . . . . . . . . . . . . . . . . . . 12 5.3.1 The <session-policy> Element . . . . . . . . . . . . . 9
4.5.1 Elements and Attributes . . . . . . . . . . . . . . . 12 5.3.2 The <context> Element . . . . . . . . . . . . . . . . 9
4.5.2 Conflict Resolution . . . . . . . . . . . . . . . . . 14 5.3.3 The <domain> Element . . . . . . . . . . . . . . . . . 10
4.5.3 Example . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.4 The <contact> Element . . . . . . . . . . . . . . . . 10
4.6 Media Routing Policy Schema . . . . . . . . . . . . . . . 15 5.3.5 The <info> Element . . . . . . . . . . . . . . . . . . 10
4.6.1 Elements and Attributes . . . . . . . . . . . . . . . 16 5.3.6 The <entity> Element . . . . . . . . . . . . . . . . . 10
4.6.2 Conflict Resolution . . . . . . . . . . . . . . . . . 17 5.3.7 The <media-types> Element . . . . . . . . . . . . . . 10
4.6.3 Example . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.8 The <media-type> Element . . . . . . . . . . . . . . . 11
5. Schema Definitions . . . . . . . . . . . . . . . . . . . . . . 18 5.3.9 The <codecs> Element . . . . . . . . . . . . . . . . . 11
5.1 General Policy Schema . . . . . . . . . . . . . . . . . . 18 5.3.10 The <codec> Element . . . . . . . . . . . . . . . . 12
5.2 Media Policy Schema . . . . . . . . . . . . . . . . . . . 18 5.3.11 The <media-intermediary> Element . . . . . . . . . . 12
5.3 Protocol Policy Schema . . . . . . . . . . . . . . . . . . 19 5.3.12 The <int-uri> Element . . . . . . . . . . . . . . . 13
5.4 Media Routing Policy Schema . . . . . . . . . . . . . . . 20 5.3.13 The <int-lroute> Element . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5.3.14 The <max-bandwidth> Element . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.3.15 The <qos> Element . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 5.3.16 Open Issue: Other Elements . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 5.5 Schema Definition . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
7.1 MIME Registration for application/session-policy+xml . . . 18
7.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:sessionpolicy . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . 23
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) [10]. 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
the execution of services. For example, wireless networks usually for the execution of services. For example, wireless networks
have limited resources for media traffic. During periods of high usually have limited resources for media traffic. A wireless network
activity, a wireless network provider may want to restrict codec provider may want to restrict codec usage on the network to lower
usage on the network to lower rate codecs. rate codecs or disallow the use of high bandwidth media types such as
video.
In another example, a SIP user agent is using a network which In another example, a network has a resource reservation
connects to the public Internet through a firewall at the network infrastructure in place, which enables user agents to request Quality
edge. The provider would like to tell the user agent to direct the of Service (QoS) for media streams. With session policies, the
media streams to the appropriate open ip/ports on that firewall. network can tell user agents that a QoS infrastructure is present and
Knowing this policy enables these user agents to setup sessions with ask user agents to use specific parameters or provide certain
user agents on the public Internet. credentials when requesting QoS.
In a third example, a domain A has a limited bandwidth pipe to In a third example, a user has subscribed to a service that requires
another domain B. The pipe is realized through two routers that are the media streams to be routed through a media intermediary. The
managed. Domain A would like to direct each call to one of the service provider would like to tell the user agent to direct the
routers based on their capacity. With session policies, the domain media streams to this intermediary and to use a certain source
can inform the user agent about the route with the most capacity routing scheme (e.g. IP-in-IP tunneling). Knowing this policy
available. enables the user to use this service in any network from which the
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
provide an important combination of consent coupled with enforcement. provide an important combination of consent coupled with enforcement.
That is, the user becomes aware of the policy and needs to act on it, That is, the user becomes aware of the policy and needs to act on it,
but the provider still retains the right to enforce the policy. but the provider still retains the right to enforce the policy.
Some policies are created specifically for a certain session. Such Session-policies can be set up in two different ways: specifically
policies usually require that the user agent provides information for a session or independent of a session. Session-specific policies
about the session to the network and receives policies that are are created for one particular session, usually under consideration
tailored to this session. Session-specific policies can be set up of certain aspects of this session (e.g. the IP addresses and ports
using the framework for session-specific policies [3]. that are used for media). Since session-specific policies are
tailored to a session, they only apply to the session they are
Session policies are often independent of a certain session and created for. These policies require a delivery mechanism that
generally apply to the sessions that are set up by a user agent. In enables the exchange of session policy information at the time a
principle, these policies could also be set up on a session is established. The framework for session-specific policies
session-to-session basis. However, it is much more efficient to [3] defines such a delivery mechanism for session-specific policies.
enable user agents to obtain the policies relevant for them and to
inform the user agents about changes in these policies. This draft
defines a mechanism for delivering session-independent policies to
user agents.
This draft also defines XML schemas for session policies. It defines Session-independent policies on the other hand are independent of a
a general session policy schema acting as a framework for session specific session and generally apply to the sessions set up by a user
policies. It also defines schemas for media policies, protocol agent. An example is a policy which prohibits the use of
policies and media routing policies. Policy instance documents can high-bandwidth codecs. In principle, these policies could also be
be delivered to user agents as session-independent policies using the delivered to user agents individually for each session, using the
mechanisms below or as session-specific policies [3]. session-specific policy framework. However, since these policies
apply to many sessions, it is more efficient to deliver them to user
agents only when the user agent is initialized or a policy changes.
This draft defines a delivery mechanism for session-independent
policies.
Note: The difference between session-independent and This draft also defines the Basic Session Policy Format (BSPF). BSPF
session-specific policies needs more discussion here. is a minimal session policy format aimed at achieving
interoperability between different user agents and policy servers.
This format introduces a common data model and defines a basic set of
policy elements. The format is based on XML [16] and can be extended
using XML extension mechanisms. The document format is independent
of the policy delivery mechanism and can be used for
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
This draft defines a mechanism for the delivery of Session-independent policies can be delivered to UAs using the
session-independent policies to UAs. Session-independent policies mechanism defined in the Framework for SIP User Agent Profile
can be part of the device configuration and reside on the same Delivery [12]. Session-independent policies can reside on the same
configuration server. They can be delivered to UAs in conjunction server as other configuration information and they can be delivered
with the device configuration. Session-independent policies may also to UAs in conjunction with this information. Session-independent
be independent of other configuration information and reside on policies can also reside on a separate policy server, which is
different servers. independent of a configuration server. A UA may receive
session-independent policies from multiple policy servers. The
This mechanism enables UAs to indicate their support for session following sections describe the subscription to the
policies and to receive policies from different policy servers. A UA session-independent policies relevant for a UA.
subscribes to session-independent policies. It receives these
policies when the subscription is established and is notified if
updates to session policies become available. The
session-independent policy mechanism is based on the Framework for
SIP User Agent Profile Delivery [7] and RFC3265 [9].
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 a policy server. If the UA has subscribing to session policies using the mechanism defined in [12].
already received the URIs of all relevant session policy documents If the UA has already received the URIs of all relevant session
(e.g., through configuration) it SHOULD use these URIs to create a policy servers (e.g., through configuration) it SHOULD use these URIs
subscription as defined in [7]. to subscribe to session-independent 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. The AoR-domain may, for example, provide physically connected to. A policy server in the AoR-domain may, for
policies that are needed for services the user has subscribed. The example, provide policies needed for services the user has subscribed
domain that provides the physical network connection may hand have to. The domain that provides the physical network connection may
policies helping to maintain the functionality of the network, e.g., have policies needed to ensure the operativeness of the network,
by limiting the bandwidth a single UA can consume. A UA can e.g., by limiting the bandwidth available to a UA. A UA SHOULD
subscribe to these two domains without having previous knowledge attempt to subscribe to the policy servers in both domains. These
about the policy server URI by using the profile-types "user" and subscriptions are established using the "user" (for subscriptions to
"local" defined in [7]. Since a UA has no way of knowing whether a the AoR-domains) and the "local" (for subscriptions to the network
domain has a policy server, it SHOULD attempt to subscribe to these domain) profile-types [12]. A UA SHOULD modify these subscriptions
two profile-types if the following events occur: as described below in following events:
o One (or more) AoRs registered by the UA change. This might be due o The UA changes the registration status of one of its AoR. This
to a change in the AoR of an existing user or a user is added occurs, for example, when a UA starts up and registers its AoRs,
to/removed from the set of users of a device. The UA SHOULD when it shuts down and deregisters AoRs, or when a new AoR is
subscribe each AoR that as changed using the "user" as well as the added to a UA. In these events, the UA SHOULD establish
"local" profile-type. It SHOULD terminate all subscriptions for subscriptions for each new AoR using the "user" and the "local"
AoRs not in use any more. 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 o The domain the UA is connected to changes. The UA SHOULD create a
subscription for each AoR it maintains using the "local" new subscription for each AoR using the "local" profile-type. It
profile-type. It SHOULD terminate all existing subscriptions for SHOULD terminate all existing subscriptions for the "local"
the "local" profile-type. profile-type. It does not need to change the subscriptions for
"user" profiles.
If a subscriber is unable to successfully establish a subscription, If a subscriber is unable to successfully establish a subscription,
it SHOULD NOT attempt to re-try this particular subscription at a it SHOULD NOT attempt to re-try this subscription, unless one of the
later point, unless one of the above events occurs again. This is to above events occurs again. This is to limit the number of SUBSCRIBE
limit the number of SUBSCRIBE requests sent within domains that do requests sent within domains that do not support session-policies.
not support session-policies.
A subscriber compliant to this specification MUST indicate its A subscriber compliant to this specification MUST indicate its
support for session policies by adding the MIME types of supported support for session-independent session policies by adding the MIME
session policy formats to the Accept header of the SUBSCRIBE request. types of supported session policy formats to the Accept header of the
This specification defines the new MIME type SUBSCRIBE request. This specification defines the new MIME type
"application/session-policy+xml". All UAs compliant to this "application/session-policy+xml", which MUST be supported by UAs
specification MUST support this MIME type and MUST include it in the compliant to this specification. UAs MAY also indicate support for
Accept header of SUBSCRIBE requests. MIME type extensions (e.g. an additional XML namespace) using [4].
OPEN ISSUE: The subscriber also needs to be able to indicate
support for a certain XML schema, i.e., an XML namespace!
A subscriber may receive a 406 in response to a SUBSCRIBE request. A subscriber may receive a 406 in response to a SUBSCRIBE request.
This indicates that the notifier requires the support of a session This indicates that the notifier requires the support of a session
policy format that was not in the Accept header of the SUBSCRIBE policy format that was not in the Accept header of the SUBSCRIBE
request. This means that the notifier has session policies that are request. This means that the notifier has session policies that are
required in the network but not supported by the subscriber. As a required in the network but not supported by the subscriber. As a
consequence, the subscriber may experience difficulties when setting consequence, the subscriber may experience difficulties when setting
up a session without these policies. up a session without these policies.
3.2 Notifier Behavior 3.2 Notifier Behavior
A network may have session policies in place that must be supported A network may have session policies in place that must be supported
by a UA. UAs that do not support these policies may experience by a UA. If the notifier receives a SUBSCRIBE request, which does
problems when setting up a session. For example, a network may have not list all MIME types and MIME type extensions in the Accept header
a policy enabling firewall traversal. 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
A UA lists all the session policy formats it supports in the Accept this format that must be used by the UA. The notifier SHOULD NOT
header of a SUBSCRIBE request. If the notifier receives a SUBSCRIBE return a 406 if an unsupported format contains optional policies.
request that does not contain the MIME types of all policy formats
required in the network, it MUST reject the request with a 406
response. A policy format is required, if the network has policy
documents in this format and these documents contain constraints that
must be applied by the UA. The notifier SHOULD NOT return a 406 if
an unsupported format only contains optional policies.
4. Session Policy Schemas
The schemas for session policies defined in this document extend the
schema for user agent profile data sets [8]. This simplifies the
processing of policy data and other user agent configuration data and
enables them to share the delivery mechanisms and to co-exist in the
same instance documents.
This draft specifies a general schema for session policies, which
covers the common aspects of session policies. It acts as a
framework schema for session policies. Based on this framework,
specific session policy schemas can be defined. This draft defines
policy schemas for media policies, protocol policies and media
routing policies. It is expected that other session policy schemas
will be defined in the future.
This specification makes use of XML namespaces. The namespace URIs
for schemas defined in this specification are URNs [5], using the
namespace identifier 'ietf' defined by RFC 2648 [6] and extended by
[4].
4.1 Specifying Constraints
Policies are defined by using the constraint elements defined in [8].
The specification of constraints is centered around the concept of a
working profile. A working profile is the set of properties a UA is
actually using during operation. The following sections defines how
session policies constraints influence the working profile of a UA.
forbid - the values of elements contained inside of a forbid element
MUST NOT be used in the working profile. If a policy element
value in a forbid element is in the working profile, it MUST be
removed. For example, the forbid element may contain the name of
codecs that are prohibited in the local local network. The forbid
element can contain empty policy elements. This means that all
possible values for that element MUST be removed from the working
profile. For example, a <codec /> element in the forbid container
indicates that all codecs must be removed from the working
profile. Specific codecs can be added to the working profile
again by listing them in a set_all, set_one or set_any element
inside the same the same property_set. Policy element values that
were removed in one property_set can't be added again by a
different property_set. This would constitute a policy conflict
between the two property_sets.
set_all - the set_all element contains policy element values that
MUST be present in the working profile of a UA. They MUST be
added to the working profile if they are supported by the UA and
not forbidden by another property_set. A policy conflict occurs
if they can't be added to the working profile.
set_one - the semantics of the set_one element is similar to the
set_all element except that the set_one element may contain
alternative policy element and the UA MUST apply the first policy
element that does not cause conflicts.
set_any - the set_any element contains policy element values that
SHOULD be added to the working profile if they are supported by
the UA and do not conflict with other policies.
A UA MUST process the forbid element before processing the set_all,
set_one, and set_any elements within a property_set.
Note: The structure of the schema and the way constraints are
specified has changed significantly since the last revision. The
goal was to better align with the profile data set framework and
to simplify the specification of policies.
4.2 Extensibility
Other elements from different namespaces MAY be present within an
element of a policy schema for the purposes of extensibility;
elements or attributes from unknown namespaces MUST be ignored.
4.3 General Policy Schema
The general session policy schema defines the elements and attributes
that are common to all session policy schemas. All session policy
documents MUST import this schema.
The namespace of the general session policy schema is:
urn:ietf:params:xml:ns:sessionpolicy
This document specifies a MIME type for policy instance documents.
The new MIME type is:
application/session-policy+xml
4.3.1 Elements and Attributes
The following elements are defined in the session policy schema.
They are optional elements that MAY appear once inside a settings
element [8]. They do not refer to a particular property set and
therefore appear outside of a property_set element.
4.3.1.1 Version
The version element allows the recipient to properly order setting
instances. Versions start at 0, and increment by one for each new
document sent to a subscriber. Versions are scoped within a
subscription. Versions MUST be representable using a 32 bit integer.
4.3.1.2 Domain
The domain element contains a URI that identifies the domain to which
this setting instance belongs to.
4.3.1.3 Entity
The entity element contains a URI that identifies the user or device
whose policy information is reported in this setting instance. If
this element is not present, the setting applies to all entities on a
device.
4.3.1.4 Include Target
The includeTarget element contains a URI that identifies the remote
target of a dialog. A setting which in which this element is
contained applies to all dialogs which have this URI as their remote
target. Missing URI elements MUST match to any value. For example,
a URI without a user name matches to all users in this domain.
4.3.1.5 Exclude Target
The excludeTarget element contains a URI that identifies the remote
target of a dialog. The setting in which this element is contained
applies to all dialogs which do not have this URI as the remote
target. Missing URI elements MUST match to any value. For example,
a URI without a user name matches to all users in this domain.
4.3.1.6 Info
The info element provides a short textual description of the setting
that should be intelligible to the human user.
4.4 Media Policy Schema
The media policy schema defines the elements and attributes needed to
describe the characteristics of media streams.
The namespace of the media policy schema is:
urn:ietf:params:xml:ns:mediapolicy
4.4.1 Elements and Attributes
The following elements and attributes are defined in the media policy
schema.
4.4.1.1 Media
The media element defines a media policy. A media element MAY appear
zero, one or multiple times in a constraint element.
The media element has the following sub-elements.
4.4.1.1.1 Max Bandwidth
The maxBandwidth element defines the maximum bandwidth in kilobits
per second an entity can count on.
The maxBandwidth element is optional and can only appear once within
a media element. All subsequent instances MUST be ignored. It has
no meaning and MUST be ignored if it is inside a forbid constraint.
4.4.1.1.2 Maxno Streams
The maxnoStreams element defines the maximum number of streams an
entity is allowed to handle at the same time.
The maxnoStreams element is optional and can only appear once within
a media element. All subsequent instances MUST be ignored. It has
no meaning and MUST be ignored if it is inside a forbid constraint.
4.4.1.1.3 Maxno Sessions
The maxnoSessions element defines the maximum number of sessions an
entity is allowed to establish at the same time.
The maxnoSessions element is optional and can only appear once within
a media element. All subsequent instances MUST be ignored. It has
no meaning and MUST be ignored if it is inside a forbid constraint.
4.4.1.1.4 Maxno Streams Session
The maxnoStreamsSession element defines the maximum number of streams
an entity is allowed to establish within a session.
The maxnoStreamsSession element is optional and can only appear once
within a media element. All subsequent instances MUST be ignored.
It has no meaning and MUST be ignored if it is inside a forbid
constraint.
4.4.1.1.5 Max Bandwidth Session
The maxBandwidthSession element defines the maximum bandwidth in
kilobits per second available to the entity within one session.
The maxBandwidthSession element is optional and can only appear once 4. Policy Format Design
within a media element. All subsequent instances MUST be ignored.
It has no meaning and MUST be ignored if it is inside a forbid
constraint.
4.4.1.1.6 Max Bandwidth Stream The following sections describe design considerations for an
XML-based model for session policies.
The maxBandwidthStream element defines the maximum bandwidth in 4.1 Policy Model
kilobits per second available to the entity for one stream.
The maxBandwidthStream element is optional and can only appear once Session policies influence aspects of a SIP session by defining
within a media element. All subsequent instances MUST be ignored. constraints. A constraint impacts a specific aspect of a SIP session
It has no meaning and MUST be ignored if it is inside a forbid (e.g. the codecs that can be used in this session). Policy
constraint. constraints are modeled as XML elements. Each policy element
expresses a certain constraint. Policy elements can contain a simple
value or act as a container, which holds multiple alternative values
for this policy.
4.4.1.1.7 Type Elements that express policies have a 'policy' attribute. This
attribute defines the constraining properties of the XML element.
The following values are defined for the 'policy' attribute:
The type element identifies a media type. The value of this element o mandatory: the value contained in the element is mandatory and
MUST be the name of a IANA registered media type (see [2]), such as MUST be used in sessions. This is the default value that is used
"audio", "video", "text", or "application". if the 'policy' attribute is omitted.
o allow: the value contained in the element is allowed and MAY be
used in sessions.
o disallow: the value contained in the element is forbidden and MUST
NOT be used in sessions.
The type element is optional and MAY appear multiple times within a Polices consisting of one single value can be expressed by a simple
media element. policy element. The following is an example of a policy defining an
upper limit for media bandwidth:
4.4.1.1.8 Codec <max-bandwidth>80</max-bandwidth>
The codec element identifies a media codec. The value of this Policies consisting of multiple values can be expressed using a
element MUST be the name of a registered MIME type for a encoding container element. The container contains multiple elements, which
(see [2]), such as "PCMA", "G729", or "H263". 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:
The codec element is optional and MAY appear multiple times within a <media-types policy="disallow">
media element. <media-type policy="mandatory">audio</media-type>
<media-type policy="allow">video</media-type>
</media-types>
4.4.1.1.9 Transport 4.2 Unidirectional Policies
The transport element identifies a transport protocol for media Some policies only affect media streams flowing into one direction,
streams. The value of this element MUST be the name of a IANA e.g., only outgoing streams. Unidirectional policies can be
registered protocol (see [2]), such as "udp", "RTP/AVP", or expressed by adding a 'direction' attribute to the respective policy
"RTP/SAVP". element.
The transport element has an optional attribute: The 'direction' attribute can have the following values:
type - the type attribute identifies the media type to which the o recvonly: the policy only applies to incoming streams.
transport element applies to. The value of this attribute MUST be o sendonly: the policy only applies to outgoing streams.
a legal type element value. o sendrecv: the policy applies to streams in both directions. This
is the default value that is used if the 'direction' attribute is
omitted.
The transport element is optional and MAY appear multiple times 4.3 Per-Stream Policies
within a media element.
4.4.1.1.10 Direction Policies can be specific to a certain media stream. The stream to
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.
The direction element identifies a media stream direction. The value Per-stream policies require that the policy server has access to the
of this element MUST be "sendrec", "sendonly", or "recvonly". session description in order to extract the stream label. For this
reason, per-stream policies are typically used in session-specific
policies.
The direction element has an optional attribute: 4.4 Merging Policies
type - the type attribute identifies the media type to which the A UA may receive policy documents from multiple sources, which need
direction element applies to. The value of this attribute MUST be to be merged into a single combined policy document the UA can work
a legal type element value. with.
The direction element is optional and MAY appear multiple times Policies that define a single value (e.g. maximum bandwidth) require
within a media element. the selection of one value during the merging process. The selection
criteria must be defined individually for each element (e.g. select
lowest value) in the schema definition.
4.4.2 Conflict Resolution Policies that allow multiple values can be merged by combining all
values and adjusting the 'policy' attribute for values that exist in
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.
The UA SHOULD alert the user in case a media policy conflicts with Some constellations are not feasible and constitute a policy conflict
another policy. 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.
OPEN ISSUE: Can we be more specific what to do if a conflict pol 1 \ pol 2 | mandatory | allow | disallow
occurs in the general case? --------------+-----------+-----------+-----------
mandatory | mandatory | mandatory | conflict!
allow | mandatory | allow | disallow
disallow | conflict! | disallow | disallow
4.4.3 Example Table 1: merging policies.
The following example describes a policy that limits the number of The combined policy MUST again be valid and well-formed according to
streams a UA can create to 4. It only allows audio streams and policy schema definitions. A policy conflict occurs if the combined
prohibits the use of the PCMU and PCMA codecs. It requires the UA to policy is not a well-formed document after the merging process is
support RTP/AVP as a transport and optionally allows RTP/SAVP but no completed.
other transport protocols. Audio streams can only be sent.
<property_set> 5. Basic Session Policy Format
<forbid>
<media>
<type />
<codec>PCMU</codec>
<codec>PCMA</codec>
<transport />
</media>
</forbid>
<set_all>
<media>
<maxnoStreams>4</maxnoStreams>
<type>audio</type>
<transport>RTP/AVP</transport>
<direction type="audio">sendonly</direction>
</media>
</set_all>
<set_any>
<media>
<transport>RTP/SAVP</transport>
</media>
</set_any>
</property_set>
4.5 Protocol Policy Schema The Basic Session Policy Format (BSPF) defines the structure of and a
root element for session policy documents. It provides a minimal set
of policy elements as required by [14]. To enable interoperability
between UAs and policy servers, this format MUST be supported by all
UAs compliant to this specification.
The protocol policy schema defines the elements and attributes needed Note: It is the goal to keep this specification aligned with the
to describe protocol characteristics. schema for user agent profile data sets [13] to simplify the
processing of policy and configuration data.
The namespace of the protocol policy schema is: 5.1 MIME Type and Namespace
urn:ietf:params:xml:ns:protocolpolicy
4.5.1 Elements and Attributes The MIME type for the Basic Session Policy Format is:
The following elements and attributes are defined in the protocol application/session-policy+xml
policy schema.
4.5.1.1 Protocol This specification makes use of XML namespaces [5]. The namespace
URIs for schemas defined in this specification are URNs [8], using
the namespace identifier 'ietf' defined by [9] and extended by [6].
The namespace URN for the BSPF schema is:
The protocol element defines a protocol policy. Each protocols urn:ietf:params:xml:ns:sessionpolicy
element contains the policy related to the usage of a particular
protocol. A protocol element MAY appear zero, one or multiple times
in a constraint element.
The protocol element has an optional attribute: 5.2 Extensibility
name - the name attribute identifies the name of the protocol, to The BSPF format can be extended using XML extension mechanisms. In
which the policy of the protocol element is referring to. 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.
Each protocol element has the following sub-elements. 5.3 XML Format Definition
4.5.1.1.1 Proxy A BSPF document is an XML [16] document that MUST be well-formed and
MUST be valid according to schemas, including extension schemas,
available to the validator and applicable to the XML document. BSPF
documents MUST be based on XML 1.0 and MUST be encoded using UTF-8.
The proxy element identifies the URI of a proxy. The proxy values 5.3.1 The <session-policy> Element
MUST be used to create a route set.
The proxy element is optional and may appear multiple times inside a The root element of a BSPF document is the <session-policy> element.
protocol element. Multiple appearances of this element are ordered.
It has no meaning and MUST be ignored if it is inside a forbid
constraint.
4.5.1.1.2 Method The <session-policy> element MAY contain an optional <context>
element and multiple (including zero) <media-types>, <codecs>,
<media-intermediary>, <qos>, and <max-bandwidth> elements as well as
elements from other namespaces.
The method element identifies a method. The value of this element 5.3.2 The <context> Element
MUST be the name of a valid method within the protocol identified by
in the protocol element.
The method element is optional and MAY appear multiple times within a The <context> element provides context information about this policy.
protocol element.
4.5.1.1.3 Option Tag The <context> element is optional in a <session-policy> element. It
MAY contain a <domain>, multiple <contact>, a <info>, and multiple
<entity> elements.
The optionTag element identifies an optionTag. The value of this Merging policies: the <context> element is not subject to merging.
element MUST be the name of an option tag registered for the protocol Information in the context element may be used to assist the user
identified by in the protocol element in the IANA registry. 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.
The optionTag element is optional and MAY appear multiple times 5.3.3 The <domain> Element
within a protocol element.
4.5.1.1.4 Transport The <domain> element contains a URI that identifies the domain which
has issued this policy.
The transport element identifies a transport protocol for the The <domain> element is optional and MAY occur only once inside a
protocol identified by the protocol element. The value of this <context> element.
element MUST identify a valid transport for the given protocol. For
SIP, the value MUST a value that is registered for the transport
header field parameter, such as "TCP", "UDP", or "SCTP".
The transport element is optional and MAY appear multiple times 5.3.4 The <contact> Element
within a protocol element.
4.5.1.1.5 Body-disposition 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.
The body-disposition element identifies a body-disposition. The The <contact> element is optional and MAY occur multiple times inside
value of this element MUST be a name registered in the IANA registry a <context> element.
for Content-Dispositions.
The body-disposition element is optional and MAY appear multiple 5.3.5 The <info> Element
times within a protocol element.
4.5.1.1.6 Body-format Element The <info> element provides a short textual description of the policy
that should be intelligible to the human user.
A body-format element identifies a body-format. The value of this The <info> element is optional and MAY occur only once inside a
element MUST be the name of a MIME type registered in the IANA <context> element.
registry.
The body-format element has an optional attribute: 5.3.6 The <entity> Element
body-disposition - the body-disposition attribute identifies the body The <entity> element contains a URI that identifies the user or
disposition used with this body-format. The value of this device whose policy information is reported in this policy instance.
attribute MUST be a value legal for the body-disposition element. 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 body-format element is optional and MAY appear multiple times The <entity> element is optional and MAY occur multiple times inside
within a protocol element. a <context> element.
4.5.1.1.7 Body-encryption 5.3.7 The <media-types> Element
The body-encryption indicates whether or not encryption is allowed The <media-types> element expresses a policy for the use of media
for a particular body disposition. This element MUST NOT have a types (e.g. audio, video). A policy defines the media types that
value. must be used, may be used, or must not be used in a session.
The body-encryption element has the following optional attributes: This element has an mandatory 'policy' attribute as defined in
Section 4.1. The 'policy' attribute specifies the default policy for
all media types that are not listed inside this element.
body-disposition - the body-disposition attribute identifies the body This element has an optional 'direction' attribute as defined in
disposition this encryption setting applies to. The value of this Section 4.2.
attribute MUST be a value legal for the body-disposition element.
body-format - the body-format attribute identifies the body format to
which this encryption setting applies to. The value of this
attribute MUST be a value legal for the body-format element.
The body-encryption element is optional and MAY appear multiple times The <media-types> element is optional in a <session-policy> element
within a protocol element. and MAY occur multiple times. It MUST contain one or more
<media-type> elements.
4.5.2 Conflict Resolution Merging policies: the 'policy' attribute of the <media-types>
element and <media-type> elements with the same value is adjusted
according to Table 1.
The UA SHOULD alert the user in case a protocol policy conflicts with 5.3.8 The <media-type> Element
another policy.
OPEN ISSUE: Can we be more specific what to do if a conflict The <media-type> element defines a policy for the use of the media
occurs in the general case? type identified by this elements value. This value MUST be the name
of a IANA registered media type (see [2]), such as 'audio', 'video',
'text', or 'application'.
4.5.3 Example This element has a mandatory 'policy' attribute as defined in Section
4.1.
The following example describes a policy saying that use of the The <media-type> element is mandatory and MAY occur multiple times
MESSAGE method is prohibited in the network. It states that the use inside a <media-types> element.
of the option tag 100rel is required and preconditions are allowed.
Other option tags are not allowed in the network. The only MIME type
for message bodies allowed is "application/sdp" with the
body-disposition "session". Encryption is not allowed for bodies
with body-disposition "session".
<property_set> 5.3.9 The <codecs> Element
<forbid>
<protocol name="SIP">
<method>MESSAGE</method>
<optionTag />
<body-format />
<body-encryption body-disposition="session" />
</protocol>
</forbid>
<set_all>
<protocol name="SIP">
<optionTag>100rel</optionTag>
<body-format body-disposition="session">application/sdp</body-format>
</protocol>
</set_all>
<set_any>
<protocol name="SIP">
<optionTag>preconditions</optionTag>
</protocol>
</set_any>
</property_set>
4.6 Media Routing Policy Schema 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
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
type.
The media routing schema defines the elements and attributes needed This element has a mandatory 'policy' attribute as defined in Section
to describe address and ports of a media stream. This schema can be 4.1. The 'policy' attribute specifies the default policy for all
used to route the media stream through a NAT, a firewall or a media codecs that are not listed inside this element.
relay.
The namespace of the protocol policy schema is: This element has an optional 'direction' attribute as defined in
urn:ietf:params:xml:ns:mediaroutingpolicy Section 4.2.
OPEN ISSUE: This schema probably needs to go into a separate draft This element has an optional 'label' attribute as defined in Section
along with some text about the mechanics. 4.3.
4.6.1 Elements and Attributes The <codecs> element is optional in a <session-policy> element and
MAY occur multiple times. It MUST contain one or more <codec>
elements.
The following elements and attributes are defined in the protocol Merging policies: the 'policy' attribute of the <codecs> element
policy schema. and <codec> elements with the same value is adjusted according to
Table 1.
4.6.1.1 Media Routing 5.3.10 The <codec> Element
The mediaRouting element defines a media routing policy. A media The <codec> element defines a policy for the use of the codec
routing element MAY appear zero, one or multiple times in a identified by this elements value. This value MUST be the name of a
constraint element. registered MIME type for a encoding (see [2]), such as "PCMA",
"G729", or "H263".
Each protocol element has the following sub-elements. This element has a mandatory 'policy' attribute as defined in Section
4.1.
4.6.1.1.1 Address The <codec> element is mandatory and MAY occur multiple times inside
a <codecs> element.
The address element contains the destination address of a media 5.3.11 The <media-intermediary> Element
stream, i.e., the address that is contained in an SDP announcement
for a media stream.
The address element MUST have the following attribute: The <media-intermediary> element expresses a policy for routing a
media stream through a media intermediary. The purpose of the
<media-intermediary> element is to tell the UA to send the media for
a particular stream through an IP address and port of an
intermediary. Instead of merely sending the media there, the UA can
instead specify a source route, which touches that intermediary, but
also any other intermediaries and then the final recipient. Thus, if
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
destinations should be identified when sending the media stream is
expressed using the <int-lroute> element.
direction - the direction attribute identifies the direction of a This element has a mandatory 'policy' attribute as defined in Section
media stream. The value of this element MUST be "send" or "recv". 4.1). This attribute defines whether routing media streams through
It determines whether the element applies to the session this intermediary is mandatory or allowed.
description offer or answer.
The address element is optional and MAY appear at most once within a This element has an optional 'label' attribute as defined in Section
media routing element. 4.3.
4.6.1.1.2 Port The <media-intermediary> element is optional in a <session-policy>
element and MAY occur multiple times. The order of
<media-intermediary> element instances is significant. It defines
the order in which the media intermediaries must be traversed. The
UA sends the media stream to the intermediary listed first, then to
the intermediary listed next and so on. The <media-intermediary>
element MUST contain one <int-uri> and one <int-lroute> element.
The port element identifies the destination port of a media stream, Merging policies: the intermediaries defined in all policies are
i.e., the address that is contained in an SDP announcement for a traversed. For session-independent policies, intermediaries
media stream. 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.
The address element MUST have the following attribute: local intermediaries first).
direction - the direction attribute identifies the direction of a 5.3.12 The <int-uri> Element
media stream. The value of this element MUST be "send" or "recv".
It determines whether the element applies to the session
description offer or answer.
The port element is optional and MAY appear multiple times within a The <int-uri> element contains a URI that identifies the IP address
media routing element. 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) only the lowest port number
needs to be identified.
4.6.1.1.3 Port Range The <int-uri> element occurs exactly once inside a
<media-intermediary> element.
The portRange element identifies a range of ports that apply to the 5.3.13 The <int-lroute> Element
destination of a media stream. This can, for example, be used to
determine the range of ports that can be used for media streams in
SDP announcements.
The address element MUST have the following attribute: The <int-lroute> element identifies the loose source routing protocol
to be used with this intermediary. The value of this element can be
one of the following:
direction - the direction attribute identifies the direction of a o ip-in-ip: IP-in-IP tunneling is used to specify the hops of media
media stream. The value of this element MUST be "send" or "recv". traversal. The ultimate destination is specified in the
It determines whether the element applies to the session destination IP of the innermost packet. Each subsequent hop
description offer or answer. results in another encapsulation, with the destination of that hop
in the destination IP address of the packet.
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
to be visited on the way before reaching the final destination.
o media-specific: media protocols can provide their own loose
routing mechanism. If that is the case, the loose routing
mechanism of that protocol is used. As an example, SIP provides
its own loose routing mechanisms with the Route header. It can be
used to direct an instant message using the SIP MESSAGE method
through a set of intermediaries.
o none: if there is no loose-routing mechanism available, the media
is just sent to the first media intermediary listed in the header.
Note that this requires the intermediary to know where to forward
the packets to. Such a route must be set up in the intermediary
through other means. For example, with session-specific policies,
the policy server can extract the destination address from the
session description.
The portRange element is optional and MAY appear multiple times The <int-lroute> element occurs exactly once inside a
within a media routing element. It has the following two <media-intermediary> element.
sub-elements.
4.6.1.1.3.1 Start Port 5.3.14 The <max-bandwidth> Element
The startPort element identifies the lowest port number that belongs The <max-bandwidth> element contains the maximum bandwidth in
to the port range. kilobits per second an entity can use for its media streams.
The startPort element MUST appear exactly once inside a port range This element has an optional 'direction' attribute as defined in
element. Section 4.2. If the direction attribute is present, the
<max-bandwidth> element contains the bandwidth available in the
identified direction.
4.6.1.1.3.2 End Port The <max-bandwidth> element is optional in a <session-policy> element
and MAY occur only once.
The endPort element identifies the highest port number that belongs Merging policies: the lowest max-bandwidth value is used.
to the port range.
The endPort element MUST appear exactly once inside a port range Open issue: The maximum bandwidth policy is not part of the policy
element. requirements. Should it be part of BSPF?
4.6.2 Conflict Resolution 5.3.15 The <qos> Element
The UA SHOULD alert the user in case a media route policy conflicts Open issue: what needs to go in here?
with another policy.
OPEN ISSUE: Can we be more specific what to do if a conflict 5.3.16 Open Issue: Other Elements
occurs in the general case?
4.6.3 Example A number of additional elements have been proposed for a policy
language:
The following example describes a policy that instructs the UA to use o maximum number of streams
the address 123.124.125.126 and a port in the range of 8000 - 9000 in o maximum number of sessions
the session descriptions it creates. This information can assist a o maximum number of streams per session
UA, for example, to traverse a NAT. 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
<property_set> Is it desirable to add any of these to the BSPF format? Some of these
<set_all> items could become part of an extension to BSPF.
<mediaRouting>
<address direction="recv">123.124.125.126</address>
<portRange direction="recv">
<startPort>8000</startPort>
<startPort>9000</startPort>
</portRange>
</mediaRouting>
</set_all>
</property_set>
5. Schema Definitions 5.4 Example
5.1 General Policy Schema The following example describes a policy that requires the use of
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
policy also inserts a media intermediary into outgoing media streams.
[TBD.] <session-policy>
<context>
<domain>example.com</domain>
<contact>sip:policy_manager@example.com</contact>
<info>Access network policies</info>
</context>
<media-types policy="disallow">
<media-type policy="mandatory">audio</media-type>
<media-type policy="allow">video</media-type>
</media-types>
<codecs policy="allow">
<codec policy="disallow">G729</codec>
<codec policy="disallow">G723</codec>
</codecs>
<media-intermediary direction="sendonly" policy="mandatory">
<int-uri>123.234.123.234:6000</int-uri>
<int-lroute>ip-in-ip</int-lroute>
</media-intermediary>
</session-policy>
5.2 Media Policy Schema 5.5 Schema Definition
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:mediapolicy" <xs:schema targetNamespace="urn:ietf:params:xml:ns:sessionpolicy"
xmlns:tns="urn:ietf:params:xml:ns:mediapolicy" xmlns:tns="urn:ietf:params:xml:ns:sessionpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:element name="media" type="tns:media"/> <xs:element name="session-policy" type="tns:session-policy"/>
<xs:complexType name="media"> <xs:complexType name="session-policy">
<xs:sequence> <xs:sequence>
<xs:element name="maxBandwidth" type="xs:positiveInteger" <xs:element name="context" type="tns:context" minOccurs="0"
minOccurs="0" maxOccurs="1"/> maxOccurs="1"/>
<xs:element name="maxnoStreams" type="xs:positiveInteger" <xs:element name="media-types" type="tns:media-types"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="maxnoSessions" type="xs:positiveInteger" <xs:element name="codecs" type="tns:codecs" minOccurs="0"
minOccurs="0" maxOccurs="1"/>
<xs:element name="maxnoStreamsSession"
type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/>
<xs:element name="maxBandwidthSession"
type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/>
<xs:element name="maxBandwidthStream"
type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/>
<xs:element name="type" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="codec" type="xs:string" minOccurs="0" <xs:element name="media-intermediary"
type="tns:media-intermediary" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="transport" type="tns:transport" <xs:element name="max-bandwidth" type="tns:max-bandwidth"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="direction" type="tns:direction"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="transport"> <xs:complexType name="context">
<xs:simpleContent> <xs:sequence>
<xs:extension base="xs:string"> <xs:element name="domain" type="xs:anyURI" minOccurs="0"
<xs:attribute name="type" type="xs:string" use="optional"/> maxOccurs="1"/>
</xs:extension> <xs:element name="contact" type="xs:anyURI" minOccurs="0"
</xs:simpleContent> maxOccurs="unbounded"/>
<xs:element name="info" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="entity" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="direction"> <xs:complexType name="media-types">
<xs:simpleContent> <xs:sequence>
<xs:extension base="tns:directionValue"> <xs:element name="media-type" type="tns:media-type" minOccurs="1"
<xs:attribute name="type" type="xs:string" use="optional"/> maxOccurs="unbounded"/>
</xs:extension> </xs:sequence>
</xs:simpleContent> <xs:attribute name="policy" type="tns:policyValue"
use="required"/>
<xs:attribute name="direction" type="tns:directionValue"
use="optional" default="sendrecv"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="directionValue"> <xs:complexType name="codecs">
<xs:restriction base="xs:string">
<xs:enumeration value="sendrec"/>
<xs:enumeration value="sendonly"/>
<xs:enumeration value="recvonly"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
5.3 Protocol Policy Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:protocolpolicy"
xmlns:tns="urn:ietf:params:xml:ns:protocolpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="protocol" type="tns:protocol"/>
<xs:complexType name="protocol">
<xs:sequence> <xs:sequence>
<xs:element name="proxy" type="xs:anyURI" minOccurs="0" <xs:element name="codec" type="tns:codec" minOccurs="1"
maxOccurs="unbounded"/>
<xs:element name="method" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="optionTag" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="transport" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="body-disposition" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="body-format" type="tns:body-format"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="body-encryption" type="tns:body-encryption"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="name" type="xs:string" use="optional"/> <xs:attribute name="policy" type="tns:policyValue"
use="required"/>
<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:complexType name="body-format"> <xs:complexType name="media-intermediary">
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI" minOccurs="1"
maxOccurs="1"/>
<xs:element name="int-lroute" type="tns:int-lroute" minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="policy" type="tns:policyValue"
use="required"/>
<xs:attribute name="label" type="xs:string" use="optional"/>
</xs:complexType>
<xs:complexType name="max-bandwidth">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:positiveInteger">
<xs:attribute name="body-disposition" type="xs:string" <xs:attribute name="policy" type="tns:policyValue"
use="optional"/> use="required"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="body-encryption"> <xs:complexType name="media-type">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute name="body-disposition" type="xs:string" <xs:attribute name="policy" type="tns:policyValue"
use="optional"/> use="required"/>
<xs:attribute name="body-format" type="xs:string"
use="optional"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> <xs:complexType name="codec">
5.4 Media Routing Policy Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:mediaroutingpolicy"
xmlns:tns="urn:ietf:params:xml:ns:mediaroutingpolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:attribute name="type" type="xs:string" use="optional"/>
<xs:element name="mediaRouting" type="tns:mediaRouting"/>
<xs:complexType name="mediaRouting">
<xs:sequence>
<xs:element name="address" type="xs:anyURI" minOccurs="0"
maxOccurs="1"/>
<xs:element name="port" type="tns:port"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="portRange" type="tns:portRange"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="port">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:anyURI"> <xs:extension base="xs:string">
<xs:attribute name="direction" type="tns:directionValue" <xs:attribute name="policy" type="tns:policyValue"
use="optional"/> use="required"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="portRange"> <xs:simpleType name="int-lroute">
<xs:sequence> <xs:restriction base="xs:string">
<xs:element name="startPort" type="xs:anyURI" minOccurs="1" <xs:enumeration value="ip-in-ip"/>
maxOccurs="1"/> <xs:enumeration value="ip-loose"/>
<xs:element name="endPort" type="xs:anyURI" minOccurs="1" <xs:enumeration value="media-specific"/>
maxOccurs="1"/> <xs:enumeration value="none"/>
</xs:sequence> </xs:restriction>
<xs:attribute name="direction" type="tns:directionValue" </xs:simpleType>
use="optional"/>
</xs:complexType>
<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:simpleType name="directionValue">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="send"/> <xs:enumeration value="sendrecv"/>
<xs:enumeration value="recv"/> <xs:enumeration value="sendonly"/>
<xs:enumeration value="recvonly"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
6. Security Considerations 6. 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 7. IANA Considerations
[TBD.] This document registers a new MIME type,
application/session-policy+xml, and registers a new XML namespace.
7.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 [10].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [10].
Security considerations: See Section 10 of RFC 3023 [10] and Section
6 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"
Personal and email address for further information: Volker Hilt,
<volkerh@bell-labs.com>
Intended usage: COMMON
Author/Change controller: The IETF.
7.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:sessionpolicy
This section registers a new XML namespace, as per the guidelines in
[6]
URI: The URI for this namespace is
urn:ietf:params:xml:ns:sessionpolicy.
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:sessionpolicy</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
8 References 8 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., Jacobson, V. and C. Perkins, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in
progress), September 2004. progress), September 2004.
[3] Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for [3] Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for
Session-Specific Session Policies in the Session Initiation Session-Specific Session Policies in the Session Initiation
Protocol (SIP)", October 2004. Protocol (SIP)", draft-hilt-sipping-session-spec-policy-01
(work in progress), October 2004.
[4] Mealling, M., "The IETF XML Registry", [4] Hilt, V., Rosenberg, J. and G. Camarillo, "Media Type Extension
Negotiation in the Session Initiation Protocol (SIP) Accept
Header Field", draft-hilt-sip-ext-neg-00 (work in progress),
January 2005.
[5] Hollander, D., Bray, T. and A. Layman, "Namespaces in XML", W3C
REC REC-xml-names-19990114, January 1999.
[6] 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), June
2003. 2003.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997. [7] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute",
draft-ietf-mmusic-sdp-media-label-01 (work in progress),
January 2005.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [8] Moats, R., "URN Syntax", RFC 2141, May 1997.
[9] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[7] Petrie, D., "A Framework for Session Initiation Protocol User [10] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
Agent Profile Delivery", draft-ietf-sipping-config-framework-04 3023, January 2001.
(work in progress), July 2004.
[8] Petrie, D., "A Schema for Session Initiation Protocol User [11] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[12] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-05
(work in progress), October 2004.
[13] Petrie, D., "A Schema for Session Initiation Protocol User
Agent Profile Data Sets", Agent Profile Data Sets",
draft-petrie-sipping-profile-datasets-00 (work in progress), draft-petrie-sipping-profile-datasets-00 (work in progress),
July 2004. July 2004.
[9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [14] Rosenberg, J., "Requirements for Session Policy for the Session
Notification", RFC 3265, June 2002. Initiation Protocol (SIP)",
draft-ietf-sipping-session-policy-req-02 (work in progress),
July 2004.
[10] 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.
Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C REC REC-xml-20040204, February 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
skipping to change at page 23, line 31 skipping to change at page 21, line 44
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@dynamicsoft.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 for the discussions and the suggestions
for this draft. for this draft. Many thanks also to Dan Petrie and Martin Dolly.
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
skipping to change at page 24, line 41 skipping to change at page 23, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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