draft-ietf-sipping-session-indep-policy-00.txt   draft-ietf-sipping-session-indep-policy-01.txt 
Session Initiation Proposal V. Hilt Session Initiation Proposal V. Hilt
Investigation Working Group Bell Labs/Lucent Technologies Investigation Working Group Bell Labs/Lucent Technologies
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Expires: January 8, 2005 Ericsson Expires: April 24, 2005 Ericsson
J. Rosenberg J. Rosenberg
dynamicsoft Cisco Systems
July 10, 2004 October 24, 2004
Profile Data for Session Initiation Protocol (SIP) Policies Session-Independent Session Initiation Protocol (SIP) Policies -
draft-ietf-sipping-session-indep-policy-00 Mechanism and Policy Schema
draft-ietf-sipping-session-indep-policy-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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 become aware will be disclosed, in accordance with
RFC 3668. 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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-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 http:// The list of current Internet-Drafts can be accessed at
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 January 8, 2005. This Internet-Draft will expire on April 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This draft specifies an XML schema for profile data for SIP session This draft specifies an XML schema for profile data for SIP
policies. This schema can be used within the user agent profile session-policies. It defines a delivery mechanism for SIP
devliery framework to implement session-independent SIP session session-policies that are independent of a specific SIP session.
policies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Considerations for Policy-related Profile Data . . . . . . . . 4 3. Session-Independent Policy Mechanism . . . . . . . . . . . . . 4
4. User Agent Profile Data for Session Policies . . . . . . . . . 5 3.1 Subscriber Behavior . . . . . . . . . . . . . . . . . . . 4
4.1 Policy Document Format . . . . . . . . . . . . . . . . . . 5 3.2 Notifier Behavior . . . . . . . . . . . . . . . . . . . . 6
4.1.1 Protocols Element . . . . . . . . . . . . . . . . . . 5 4. Session Policy Schemas . . . . . . . . . . . . . . . . . . . . 6
4.1.2 Media Element . . . . . . . . . . . . . . . . . . . . 7 4.1 Specifying Constraints . . . . . . . . . . . . . . . . . . 6
4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 General Policy Schema . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.3.1 Elements and Attributes . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.4 Media Policy Schema . . . . . . . . . . . . . . . . . . . 9
6.1 MIME Registration for application/session-policy+xml . . . 10 4.4.1 Elements and Attributes . . . . . . . . . . . . . . . 9
6.2 URN Sub-Namespace Registration for 4.4.2 Conflict Resolution . . . . . . . . . . . . . . . . . 11
urn:ietf:params:xml:ns:sessionpolicy . . . . . . . . . . . 11 4.4.3 Example . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Protocol Policy Schema . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5.1 Elements and Attributes . . . . . . . . . . . . . . . 12
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 4.5.2 Conflict Resolution . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 14 4.5.3 Example . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 Media Routing Policy Schema . . . . . . . . . . . . . . . 15
4.6.1 Elements and Attributes . . . . . . . . . . . . . . . 16
4.6.2 Conflict Resolution . . . . . . . . . . . . . . . . . 17
4.6.3 Example . . . . . . . . . . . . . . . . . . . . . . . 17
5. Schema Definitions . . . . . . . . . . . . . . . . . . . . . . 18
5.1 General Policy Schema . . . . . . . . . . . . . . . . . . 18
5.2 Media Policy Schema . . . . . . . . . . . . . . . . . . . 18
5.3 Protocol Policy Schema . . . . . . . . . . . . . . . . . . 19
5.4 Media Routing Policy Schema . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 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). These established using the Session Initiation Protocol (SIP) [10]. These
policies are typically needed to support the operation of the network policies are often needed to support the network infrastructure or
infrastructure or certain services. For example, a SIP user agent the execution of services. For example, wireless networks usually
might be located in a domain that is behind a Network Address have limited resources for media traffic. During periods of high
Translator (NAT). This domain might have a policy in place that activity, a wireless network provider may want to restrict codec
requires the user agent to contact a TURN [10] relay before setting usage on the network to lower rate codecs.
up a session. Information about this policy is essential for a user
agent to successfully set up a session.
In another example, SIP is used in a wireless network. The network In another example, a SIP user agent is using a network which
provider has limited resources for media traffic. During periods of connects to the public Internet through a firewall at the network
high activity, the provider would like to restrict codec usage on the edge. The provider would like to tell the user agent to direct the
network to lower rate codecs. In existing approaches, this is media streams to the appropriate open ip/ports on that firewall.
frequently accomplished by having the proxies examine the SDP [2] in Knowing this policy enables these user agents to setup sessions with
the body and remove the higher rate codecs or reject the call and user agents on the public Internet.
require the UA to start over with a different set of codecs. Having
information about the current policy would enable user agents to
initiate a session with an acceptable codec.
In a third example, a domain has established policies regarding the In a third example, a domain A has a limited bandwidth pipe to
type of user agents that can use their network. For example, a domain another domain B. The pipe is realized through two routers that are
could require that user agents using its network use a particular managed. Domain A would like to direct each call to one of the
protocol (e.g., SIP) with a set of extensions (e.g., preconditions routers based on their capacity. With session policies, the domain
must be used). A user agent needs to know the exact policy of a can inform the user agent about the route with the most capacity
domain in order to be able to use the right configuration to send and available.
receive traffic in that domain.
Some domains have policies in place that are enforced by network Domains sometimes enforce policies they have in place. For example,
elements. For example, a domain might have a configuration in which a domain might have a configuration in which all packets containing a
all packets containing a certain voice encoding are dropped. certain audio codec are dropped. Unfortunately, enforcement
Unfortunately, enforcement mechanisms usually do not inform the user mechanisms usually do not inform the user about the policies they are
about the policies they are enforcing and silently keep the user from enforcing and silently keep the user from doing anything against
doing anything against them. This may lead to the malfunctioning of them. This may lead to the malfunctioning of devices that is
devices that is in-apprehensible to the user. With session policies, incomprehensible to the user. With session policies, the user knows
the user could decide to switch to a different codec or connect to a about the restricted codecs and can use a different codec or simply
domain with less stringent policies. connect to a domain with less stringent policies. Session policies
provide an important combination of consent coupled with enforcement.
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.
Session policies may be specific to a certain session and may change Some policies are created specifically for a certain session. Such
from session to session. Such policies can be set up using the policies usually require that the user agent provides information
framework for session-specific policies [3]. Other session policies about the session to the network and receives policies that are
remain in place for a longer period of time, typically in the range tailored to this session. Session-specific policies can be set up
of hours or days. In principle, these policies could also be set up using the framework for session-specific policies [3].
on a session-to-session basis. However, establishing the same
policies over and over again is expensive, causing the continuous
transmission of the same information during session setup, and
possibly adding to session setup latencies. It is therefore desirable
to enable user agents to obtain the policies relevant for them and to
inform the user agents about changes in these policies.
This draft specifies a XML schema for media and protocol user agent Session policies are often independent of a certain session and
profile data. The media data defines properties of media streams generally apply to the sessions that are set up by a user agent. In
transmitted by a user agent. The protocol data defines the methods, principle, these policies could also be set up on a
extensions, bodies, etc. that should be supported by a user agent. session-to-session basis. However, it is much more efficient to
These formats can be used to define session policy documents. Session enable user agents to obtain the policies relevant for them and to
policy documents can be transmitted to user agents as part of their inform the user agents about changes in these policies. This draft
device configuration using the Framework for SIP User Agent Profile defines a mechanism for delivering session-independent policies to
Delivery [8]. user agents.
This draft also defines XML schemas for session policies. It defines
a general session policy schema acting as a framework for session
policies. It also defines schemas for media policies, protocol
policies and media routing policies. Policy instance documents can
be delivered to user agents as session-independent policies using the
mechanisms below or as session-specific policies [3].
Note: The difference between session-independent and
session-specific policies needs more discussion here.
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. Considerations for Policy-related Profile Data 3. Session-Independent Policy Mechanism
Policy documents should support versioning so that the recipients of This draft defines a mechanism for the delivery of
policy document can properly order them. This may be achieved using a session-independent policies to UAs. Session-independent policies
version attribute. can be part of the device configuration and reside on the same
configuration server. They can be delivered to UAs in conjunction
with the device configuration. Session-independent policies may also
be independent of other configuration information and reside on
different servers.
A policy document may contain multiple policies. Each policy in the This mechanism enables UAs to indicate their support for session
document may have a different scope. For example, a policy for policies and to receive policies from different policy servers. A UA
firewall traversal would only apply to external calls whereas a subscribes to session-independent policies. It receives these
policy limiting the bandwidth available could be in effect during policies when the subscription is established and is notified if
peak hours. A policy document may define a scope attribute that updates to session policies become available. The
specifies to which sessions a certain policy applies. Possible scopes session-independent policy mechanism is based on the Framework for
are: SIP User Agent Profile Delivery [7] and RFC3265 [9].
o Time and day: limits the use of a policy to certain times or days.
o Local entity: limits the use of a policy to a specific to a
certain local user. This is in particular useful for devices that
supports multiple identities.
o Remote entity: limits the use of a policy to sessions involving
certain remote addresses, for example all non-local addresses.
o Media streams: limits the use of a policy to certain media
streams.
The use of policies may be mandatory or optional. A policy document 3.1 Subscriber Behavior
may specify whether a policy is mandatory or optional.
4. User Agent Profile Data for Session Policies A UA can express interest in session-independent policies by
subscribing to session policies a policy server. If the UA has
already received the URIs of all relevant session policy documents
(e.g., through configuration) it SHOULD use these URIs to create a
subscription as defined in [7].
TODO: This specification needs to be alinged the schema for SIP Session-independent policies are frequently provided to a UA by the
protocol user agent profile data sets so that it can co-exist with following two network domains: the domain a user registers at (i.e.,
other data delivered through the user agent configuration the domain in the address-of-record (AoR)) and the domain the UA is
framework. physically connected to. The AoR-domain may, for example, provide
policies that are needed for services the user has subscribed. The
domain that provides the physical network connection may hand have
policies helping to maintain the functionality of the network, e.g.,
by limiting the bandwidth a single UA can consume. A UA can
subscribe to these two domains without having previous knowledge
about the policy server URI by using the profile-types "user" and
"local" defined in [7]. Since a UA has no way of knowing whether a
domain has a policy server, it SHOULD attempt to subscribe to these
two profile-types if the following events occur:
A session policy document is an XML document that MUST be well-formed o One (or more) AoRs registered by the UA change. This might be due
and SHOULD be valid. Policy documents MUST be based on XML 1.0 and to a change in the AoR of an existing user or a user is added
MUST be encoded using UTF-8. This specification makes use of XML to/removed from the set of users of a device. The UA SHOULD
namespaces for identifying session policy documents. The namespace subscribe each AoR that as changed using the "user" as well as the
URI for elements defined by this specification is a URN [5], using "local" profile-type. It SHOULD terminate all subscriptions for
the namespace identifier 'ietf' defined by RFC 2648 [6] and extended AoRs not in use any more.
by [4]. This URN is: o The domain the UA is connected to changes. The UA SHOULD create a
subscription for each AoR it maintains using the "local"
profile-type. It SHOULD terminate all existing subscriptions for
the "local" profile-type.
If a subscriber is unable to successfully establish a subscription,
it SHOULD NOT attempt to re-try this particular subscription at a
later point, 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 MUST indicate its
support for session policies by adding the MIME types of supported
session policy formats to the Accept header of the SUBSCRIBE request.
This specification defines the new MIME type
"application/session-policy+xml". All UAs compliant to this
specification MUST support this MIME type and MUST include it in the
Accept header of SUBSCRIBE requests.
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.
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. UAs that do not support these policies may experience
problems when setting up a session. For example, a network may have
a policy enabling firewall traversal.
A UA lists all the session policy formats it supports in the Accept
header of a SUBSCRIBE request. If the notifier receives a SUBSCRIBE
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 urn:ietf:params:xml:ns:sessionpolicy
A session policy document begins with the root element tag This document specifies a MIME type for policy instance documents.
"sessionpolicy". The new MIME type is:
application/session-policy+xml
4.1 Policy Document Format 4.3.1 Elements and Attributes
A session policy document starts with a sessionpolicy element. This The following elements are defined in the session policy schema.
element has three mandatory attributes: They are optional elements that MAY appear once inside a settings
version: This attribute allows the recipient of session policy element [8]. They do not refer to a particular property set and
information documents to properly order them. Versions start at 0, therefore appear outside of a property_set element.
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.
domain: This attribute contains the domain the policy belongs to.
entity: This attribute contains a URI that identifies the user
whose policy information is reported in the remainder of the
document.
The sessionpolicy element has a series of sessionpolicy sub-elements: 4.3.1.1 Version
zero or one protocols element and zero or one media element.
4.1.1 Protocols Element 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.
The protocols element contains a series of protocol sub-elements. 4.3.1.2 Domain
Each protocol sub-element contains the policy related to the usage of
a particular protocol.
The protocol element has a single mandatory attribute, name. The name The domain element contains a URI that identifies the domain to which
attribute identifies a protocol the policy of each protocol element this setting instance belongs to.
is referring to. The protocol element has a series of sub-elements:
methods, option-tags, feature-tags, and bodies.
4.1.1.1 Methods Element 4.3.1.3 Entity
The methods element contains a default-policy attribute and method The entity element contains a URI that identifies the user or device
elements. The default-policy attribute contains the policy for whose policy information is reported in this setting instance. If
methods that are not listed as method elements. A method element has this element is not present, the setting applies to all entities on a
two attributes: name and policy. The name attribute identifies a device.
method, and the policy attribute contains the policy for that method
(allowed or disallowed).
4.1.1.2 Option-tags Element 4.3.1.4 Include Target
The option-tags element contains a default-policy attribute and The includeTarget element contains a URI that identifies the remote
option-tag elements. The default-policy attribute contains the policy target of a dialog. A setting which in which this element is
for option-tags that are not listed as option-tag elements. An contained applies to all dialogs which have this URI as their remote
option-tag element has two attributes: name and policy. The name target. Missing URI elements MUST match to any value. For example,
attribute identifies a method, and the policy attribute contains the a URI without a user name matches to all users in this domain.
policy for that method (mandatory, allowed, or disallowed).
4.1.1.3 Feature-tags Element 4.3.1.5 Exclude Target
The feature-tags element contains a default-policy attribute and The excludeTarget element contains a URI that identifies the remote
feature-tag elements. The default-policy attribute contains the target of a dialog. The setting in which this element is contained
policy for feature-tags that are not listed as feature-tag elements. applies to all dialogs which do not have this URI as the remote
An feature-tag element has two attributes: name and policy. The name target. Missing URI elements MUST match to any value. For example,
attribute identifies a method, and the policy attribute contains the a URI without a user name matches to all users in this domain.
policy for that method (allowed, or disallowed).
4.1.1.4 Bodies Element 4.3.1.6 Info
The bodies element contains a default-policy attribute, a The info element provides a short textual description of the setting
default-encryption attribute and body-disposition elements. The that should be intelligible to the human user.
default-policy attribute contains the policy for body dispositions
that are not listed as body-disposition elements. The
default-encryption attribute contains the encryption policy for body
dispositions that are not listed as body-disposition elements.
A body-disposition element can have a number of attributes: name, 4.4 Media Policy Schema
policy, default-policy, and encryption. The name attribute identifies
a body-disposition, and the policy attribute contains the policy for
that body-disposition (allowed, or disallowed). The default-policy
attribute contains the policy for body formats that are not listed as
body-format elements. The encryption attribute indicates whether or
not encryption is allowed for a particular body disposition.
A body-disposition element contains body-format elements. A The media policy schema defines the elements and attributes needed to
body-format element can have a two attributes: name and policy. The describe the characteristics of media streams.
name attribute identifies a body-format, and the policy attribute
contains the policy for that body-format (allowed or disallowed).
4.1.1.5 Extensibility The namespace of the media policy schema is:
urn:ietf:params:xml:ns:mediapolicy
Other elements from different namespaces MAY be present within a 4.4.1 Elements and Attributes
protocol element for the purposes of extensibility; elements or
attributes from unknown namespaces MUST be ignored.
4.1.1.6 Example of a Protocol Element The following elements and attributes are defined in the media policy
schema.
<protocols> 4.4.1.1 Media
<protocol name="SIP">
<methods default-policy="allowed">
<method name="MESSAGE" policy="disallowed"/>
</methods>
<option-tags default-policy="disallowed">
<option-tag name="100rel" policy="mandatory"/>
<option-tag name="preconditions" policy="allowed"/>
</option-tags>
<feature-tags default-policy="disallowed">
<feature-tag name="video" policy="allowed"/>
</feature-tags>
<bodies default-policy="allowed" default-encryption="allowed">
<body-disposition name="session" policy="allowed"
encryption="disallowed" default-policy="disallowed">
<body-format name="application/sdp" policy="allowed"/>
</body-disposition>
</bodies>
</protocol>
</protocols>
4.1.2 Media Element The media element defines a media policy. A media element MAY appear
zero, one or multiple times in a constraint element.
The media element contains the policy related to the characteristics The media element has the following sub-elements.
of media streams of different types. It has three attributes:
maxbandwidth, maxnostreams, and default-policy. They contain the
maximum bandwidth the user can count on, the maximum number of media
streams that the user is allowed to established at the same time, and
the default policy (allowed or disallowed) for stream types that are
not listed as stream elements.
The media element contains a series of stream elements. 4.4.1.1.1 Max Bandwidth
4.1.2.1 Stream Element The maxBandwidth element defines the maximum bandwidth in kilobits
per second an entity can count on.
A stream element can have a number of attributes: type, policy, The maxBandwidth element is optional and can only appear once within
maxbandwidth, and maxnostreams. The type attribute identifies a media a media element. All subsequent instances MUST be ignored. It has
type, and the policy attribute contains the policy for that media no meaning and MUST be ignored if it is inside a forbid constraint.
type (allowed or disallowed).
The stream element has a number of optional sub-element: the codecs 4.4.1.1.2 Maxno Streams
element, the transports element and the directions element.
4.1.2.1.1 Codecs Element The maxnoStreams element defines the maximum number of streams an
entity is allowed to handle at the same time.
The codecs element contains a default-policy attribute and codec The maxnoStreams element is optional and can only appear once within
elements. The default-policy attribute contains the policy for codecs a media element. All subsequent instances MUST be ignored. It has
that are not listed as codec elements. A codec element can have two no meaning and MUST be ignored if it is inside a forbid constraint.
attributes: name and policy. The name attribute identifies a codec
name, and the policy attribute contains the policy for that codec
(allowed, or disallowed). The codec name is the encoding name as
defined by the respective RTP profile.
4.1.2.1.2 Transports Element 4.4.1.1.3 Maxno Sessions
The transports element contains a default-policy attribute and The maxnoSessions element defines the maximum number of sessions an
transport elements. The default-policy attribute contains the policy entity is allowed to establish at the same time.
for transports that are not listed as transport elements. A transport
element can have two attributes: name and policy. The name attribute
identifies a transport, and the policy attribute contains the policy
for that transport (allowed, or disallowed).
4.1.2.1.3 Directions Element 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.
The directions element contains a default-policy attribute and 4.4.1.1.4 Maxno Streams Session
direction elements. The default-policy attribute contains the policy
for directions that are not listed as direction elements. A direction
element can have two attributes: name and policy. The name attribute
identifies a direction (sendrecv, sendonly, recvonly), and the policy
attribute contains the policy for that direction (allowed, or
disallowed).
4.1.2.1.4 Extensibility The maxnoStreamsSession element defines the maximum number of streams
an entity is allowed to establish within a session.
Other elements from different namespaces MAY be present within a The maxnoStreamsSession element is optional and can only appear once
stream element for the purposes of extensibility; elements or within a media element. All subsequent instances MUST be ignored.
attributes from unknown namespaces MUST be ignored. It has no meaning and MUST be ignored if it is inside a forbid
constraint.
4.1.2.2 Example of a Media Element 4.4.1.1.5 Max Bandwidth Session
<media maxnostreams="4" default-policy="disallowed">
<stream type="audio" policy="allowed"> The maxBandwidthSession element defines the maximum bandwidth in
<codecs default-policy="allowed"> kilobits per second available to the entity within one session.
<codec name="PCMU" policy="disallowed"/>
<codec name="PCMA" policy="disallowed"/> The maxBandwidthSession element is optional and can only appear once
</codecs> within a media element. All subsequent instances MUST be ignored.
<transports default-policy="disallowed"> It has no meaning and MUST be ignored if it is inside a forbid
<transport name="RTP/AVP" policy="allowed"/> constraint.
</transports>
<directions default-policy="disallowed"> 4.4.1.1.6 Max Bandwidth Stream
<direction name="sendonly" policy="allowed"/>
</directions> The maxBandwidthStream element defines the maximum bandwidth in
</stream> kilobits per second available to the entity for one stream.
The maxBandwidthStream 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.7 Type
The type element identifies a media type. The value of this element
MUST be the name of a IANA registered media type (see [2]), such as
"audio", "video", "text", or "application".
The type element is optional and MAY appear multiple times within a
media element.
4.4.1.1.8 Codec
The codec element identifies a media codec. The value of this
element MUST be the name of a registered MIME type for a encoding
(see [2]), such as "PCMA", "G729", or "H263".
The codec element is optional and MAY appear multiple times within a
media element.
4.4.1.1.9 Transport
The transport element identifies a transport protocol for media
streams. The value of this element MUST be the name of a IANA
registered protocol (see [2]), such as "udp", "RTP/AVP", or
"RTP/SAVP".
The transport element has an optional attribute:
type - the type attribute identifies the media type to which the
transport element applies to. The value of this attribute MUST be
a legal type element value.
The transport element is optional and MAY appear multiple times
within a media element.
4.4.1.1.10 Direction
The direction element identifies a media stream direction. The value
of this element MUST be "sendrec", "sendonly", or "recvonly".
The direction element has an optional attribute:
type - the type attribute identifies the media type to which the
direction element applies to. The value of this attribute MUST be
a legal type element value.
The direction element is optional and MAY appear multiple times
within a media element.
4.4.2 Conflict Resolution
The UA SHOULD alert the user in case a media policy conflicts with
another policy.
OPEN ISSUE: Can we be more specific what to do if a conflict
occurs in the general case?
4.4.3 Example
The following example describes a policy that limits the number of
streams a UA can create to 4. It only allows audio streams and
prohibits the use of the PCMU and PCMA codecs. It requires the UA to
support RTP/AVP as a transport and optionally allows RTP/SAVP but no
other transport protocols. Audio streams can only be sent.
<property_set>
<forbid>
<media>
<type />
<codec>PCMU</codec>
<codec>PCMA</codec>
<transport />
</media> </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.2 Schema 4.5 Protocol Policy Schema
The following is the schema for the application/session-policy+xml The protocol policy schema defines the elements and attributes needed
type: to describe protocol characteristics.
<?xml version="1.0" encoding="UTF-8"?> The namespace of the protocol policy schema is:
TBD urn:ietf:params:xml:ns:protocolpolicy
4.3 Example 4.5.1 Elements and Attributes
The following is is an example of an application/session-policy+xml The following elements and attributes are defined in the protocol
document: policy schema.
<?xml version="1.0" encoding="UTF-8"?> 4.5.1.1 Protocol
<sessionpolicy xmlns="urn:ietf:params:xml:ns:sessionpolicy"
version="0" The protocol element defines a protocol policy. Each protocols
domain="example.com" element contains the policy related to the usage of a particular
entity="sip:alice@example.com"> protocol. A protocol element MAY appear zero, one or multiple times
<protocols> in a constraint element.
The protocol element has an optional attribute:
name - the name attribute identifies the name of the protocol, to
which the policy of the protocol element is referring to.
Each protocol element has the following sub-elements.
4.5.1.1.1 Proxy
The proxy element identifies the URI of a proxy. The proxy values
MUST be used to create a route set.
The proxy element is optional and may appear multiple times inside a
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 method element identifies a method. The value of this 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
protocol element.
4.5.1.1.3 Option Tag
The optionTag element identifies an optionTag. The value of this
element MUST be the name of an option tag registered for the protocol
identified by in the protocol element in the IANA registry.
The optionTag element is optional and MAY appear multiple times
within a protocol element.
4.5.1.1.4 Transport
The transport element identifies a transport protocol for the
protocol identified by the protocol element. The value of this
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
within a protocol element.
4.5.1.1.5 Body-disposition
The body-disposition element identifies a body-disposition. The
value of this element MUST be a name registered in the IANA registry
for Content-Dispositions.
The body-disposition element is optional and MAY appear multiple
times within a protocol element.
4.5.1.1.6 Body-format Element
A body-format element identifies a body-format. The value of this
element MUST be the name of a MIME type registered in the IANA
registry.
The body-format element has an optional attribute:
body-disposition - the body-disposition attribute identifies the body
disposition used with this body-format. The value of this
attribute MUST be a value legal for the body-disposition element.
The body-format element is optional and MAY appear multiple times
within a protocol element.
4.5.1.1.7 Body-encryption
The body-encryption indicates whether or not encryption is allowed
for a particular body disposition. This element MUST NOT have a
value.
The body-encryption element has the following optional attributes:
body-disposition - the body-disposition attribute identifies the body
disposition this encryption setting applies to. The value of this
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
within a protocol element.
4.5.2 Conflict Resolution
The UA SHOULD alert the user in case a protocol policy conflicts with
another policy.
OPEN ISSUE: Can we be more specific what to do if a conflict
occurs in the general case?
4.5.3 Example
The following example describes a policy saying that use of the
MESSAGE method is prohibited in the network. It states that the use
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>
<forbid>
<protocol name="SIP"> <protocol name="SIP">
<methods default-policy="allowed"/> <method>MESSAGE</method>
<option-tags default-policy="allowed"/> <optionTag />
<feature-tags default-policy="allowed"/> <body-format />
<bodies default-policy="allowed" default-encryption="allowed"/> <body-encryption body-disposition="session" />
</protocol> </protocol>
</protocols> </forbid>
<media default-policy="allowed"/> <set_all>
</sessionpolicy> <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>
5. Security Considerations 4.6 Media Routing Policy Schema
Session policy information can be sensitive information. The protocol The media routing schema defines the elements and attributes needed
used to distribute it SHOULD ensure privacy, message integrity and to describe address and ports of a media stream. This schema can be
authentication. Furthermore, the protocol SHOULD provide access used to route the media stream through a NAT, a firewall or a media
controls which restrict who can see who else's session policy relay.
information.
6. IANA Considerations The namespace of the protocol policy schema is:
urn:ietf:params:xml:ns:mediaroutingpolicy
This document registers a new MIME type, application/ OPEN ISSUE: This schema probably needs to go into a separate draft
session-policy+xml, and registers a new XML namespace. along with some text about the mechanics.
6.1 MIME Registration for application/session-policy+xml 4.6.1 Elements and Attributes
MIME media type name: application The following elements and attributes are defined in the protocol
policy schema.
MIME subtype name: session-policy+xml 4.6.1.1 Media Routing
Mandatory parameters: none The mediaRouting element defines a media routing policy. A media
routing element MAY appear zero, one or multiple times in a
constraint element.
Optional parameters: Same as charset parameter application/xml as Each protocol element has the following sub-elements.
specified in RFC 3023 [7].
Encoding considerations: Same as encoding considerations of 4.6.1.1.1 Address
application/xml as specified in RFC 3023 [7].
Security considerations: See Section 10 of RFC 3023 [7] and Section 5 The address element contains the destination address of a media
of this specification. stream, i.e., the address that is contained in an SDP announcement
for a media stream.
Interoperability considerations: none. The address element MUST have the following attribute:
Published specification: This document. direction - the direction attribute identifies the direction of a
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.
Applications which use this media type: This document type has been The address element is optional and MAY appear at most once within a
used to download the session policy of a domain to SIP user agents. media routing element.
Additional Information: 4.6.1.1.2 Port
Magic Number: None The port element identifies the destination port of a media stream,
i.e., the address that is contained in an SDP announcement for a
media stream.
File Extension: .wif or .xml The address element MUST have the following attribute:
Macintosh file type code: "TEXT" direction - the direction attribute identifies the direction of a
Personal and email address for further information: Gonzalo media stream. The value of this element MUST be "send" or "recv".
Camarillo, <Gonzalo.Camarillo@ericsson.com> It determines whether the element applies to the session
description offer or answer.
Intended usage: COMMON The port element is optional and MAY appear multiple times within a
media routing element.
Author/Change controller: The IETF. 4.6.1.1.3 Port Range
6.2 URN Sub-Namespace Registration for The portRange element identifies a range of ports that apply to the
urn:ietf:params:xml:ns:sessionpolicy 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.
This section registers a new XML namespace, as per the guidelines in The address element MUST have the following attribute:
[4]
URI: The URI for this namespace is direction - the direction attribute identifies the direction of a
urn:ietf:params:xml:ns:sessionpolicy. 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.
Registrant Contact: IETF, SIPPING working group,<sipping@ietf.org>, The portRange element is optional and MAY appear multiple times
Gonzalo Camarillo, <Gonzalo.Camarillo@ericsson.com> within a media routing element. It has the following two
sub-elements.
XML: 4.6.1.1.3.1 Start Port
BEGIN The startPort element identifies the lowest port number that belongs
<?xml version="1.0"?> to the port range.
<!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>application/session-policy+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
7 References The startPort element MUST appear exactly once inside a port range
element.
4.6.1.1.3.2 End Port
The endPort element identifies the highest port number that belongs
to the port range.
The endPort element MUST appear exactly once inside a port range
element.
4.6.2 Conflict Resolution
The UA SHOULD alert the user in case a media route policy conflicts
with another policy.
OPEN ISSUE: Can we be more specific what to do if a conflict
occurs in the general case?
4.6.3 Example
The following example describes a policy that instructs the UA to use
the address 123.124.125.126 and a port in the range of 8000 - 9000 in
the session descriptions it creates. This information can assist a
UA, for example, to traverse a NAT.
<property_set>
<set_all>
<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.1 General Policy Schema
[TBD.]
5.2 Media Policy Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:mediapolicy"
xmlns:tns="urn:ietf:params:xml:ns:mediapolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="media" type="tns:media"/>
<xs:complexType name="media">
<xs:sequence>
<xs:element name="maxBandwidth" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1"/>
<xs:element name="maxnoStreams" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1"/>
<xs:element name="maxnoSessions" type="xs:positiveInteger"
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"/>
<xs:element name="codec" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="transport" type="tns:transport"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="direction" type="tns:direction"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="transport">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="direction">
<xs:simpleContent>
<xs:extension base="tns:directionValue">
<xs:attribute name="type" type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="directionValue">
<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:element name="proxy" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="method" type="xs:string" minOccurs="0"
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:attribute name="name" type="xs:string" use="optional"/>
</xs:complexType>
<xs:complexType name="body-format">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="body-disposition" type="xs:string"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="body-encryption">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="body-disposition" type="xs:string"
use="optional"/>
<xs:attribute name="body-format" type="xs:string"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
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:extension base="xs:anyURI">
<xs:attribute name="direction" type="tns:directionValue"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="portRange">
<xs:sequence>
<xs:element name="startPort" type="xs:anyURI" minOccurs="1"
maxOccurs="1"/>
<xs:element name="endPort" type="xs:anyURI" minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="direction" type="tns:directionValue"
use="optional"/>
</xs:complexType>
<xs:simpleType name="directionValue">
<xs:restriction base="xs:string">
<xs:enumeration value="send"/>
<xs:enumeration value="recv"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
6. Security Considerations
Session policy information can be sensitive information. The
protocol used to distribute it SHOULD ensure privacy, message
integrity and authentication. Furthermore, the protocol SHOULD
provide access controls which restrict who can see who else's session
policy information.
7. IANA Considerations
[TBD.]
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. and V. Jacobson, "SDP: Session Description [2] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in
progress), September 2004.
[3] Hilt, V. and J. Rosenberg, "A Framework for Session-Specific [3] Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for
Intermediary Session Policies in SIP", September 2003. Session-Specific Session Policies in the Session Initiation
Protocol (SIP)", October 2004.
[4] Mealling, M., "The IETF XML Registry", [4] 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. [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[7] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC [7] Petrie, D., "A Framework for Session Initiation Protocol User
3023, January 2001. Agent Profile Delivery", draft-ietf-sipping-config-framework-04
(work in progress), July 2004.
[8] Petrie, D., "A Framework for Session Initiation Protocol User [8] Petrie, D., "A Schema for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-03 Agent Profile Data Sets",
(work in progress), May 2004. draft-petrie-sipping-profile-datasets-00 (work in progress),
July 2004.
[9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[10] Rosenberg, J., "Traversal Using Relay NAT (TURN)", [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
draft-rosenberg-midcom-turn-04 (work in progress), February
2004.
[11] 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.
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
skipping to change at page 13, line 4 skipping to change at page 23, line 16
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
dynamicsoft Cisco Systems
72 Eagle Rock Avenue 600 Lanidex Plaza
East Hanover, NJ 07936 Parsippany, NJ 07054
USA USA
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@dynamicsoft.com
Appendix A. Acknowledgements Appendix A. Acknowledgements
Many thanks to Allison Mankin and Markus Hofmann for their Many thanks to Allison Mankin for the discussions and the suggestions
contributions to this draft. for this draft.
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 IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
 End of changes. 

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