Session Initiation Proposal V. Hilt Investigation Working Group Bell Labs/Lucent Technologies Internet-Draft G. Camarillo Expires: April 24, 2005 Ericsson J. Rosenberg Cisco Systems October 24, 2004 Session-Independent Session Initiation Protocol (SIP) Policies - Mechanism and Policy Schema draft-ietf-sipping-session-indep-policy-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This draft specifies an XML schema for profile data for SIP session-policies. It defines a delivery mechanism for SIP session-policies that are independent of a specific SIP session. Hilt, et al. Expires April 24, 2005 [Page 1] Internet-Draft Session-Independent Policies October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Session-Independent Policy Mechanism . . . . . . . . . . . . . 4 3.1 Subscriber Behavior . . . . . . . . . . . . . . . . . . . 4 3.2 Notifier Behavior . . . . . . . . . . . . . . . . . . . . 6 4. Session Policy Schemas . . . . . . . . . . . . . . . . . . . . 6 4.1 Specifying Constraints . . . . . . . . . . . . . . . . . . 6 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 4.3 General Policy Schema . . . . . . . . . . . . . . . . . . 7 4.3.1 Elements and Attributes . . . . . . . . . . . . . . . 8 4.4 Media Policy Schema . . . . . . . . . . . . . . . . . . . 9 4.4.1 Elements and Attributes . . . . . . . . . . . . . . . 9 4.4.2 Conflict Resolution . . . . . . . . . . . . . . . . . 11 4.4.3 Example . . . . . . . . . . . . . . . . . . . . . . . 11 4.5 Protocol Policy Schema . . . . . . . . . . . . . . . . . . 12 4.5.1 Elements and Attributes . . . . . . . . . . . . . . . 12 4.5.2 Conflict Resolution . . . . . . . . . . . . . . . . . 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 Hilt, et al. Expires April 24, 2005 [Page 2] Internet-Draft Session-Independent Policies October 2004 1. Introduction Some domains have policies in place, which impact the sessions established using the Session Initiation Protocol (SIP) [10]. These policies are often needed to support the network infrastructure or the execution of services. For example, wireless networks usually have limited resources for media traffic. During periods of high activity, a wireless network provider may want to restrict codec usage on the network to lower rate codecs. In another example, a SIP user agent is using a network which connects to the public Internet through a firewall at the network edge. The provider would like to tell the user agent to direct the media streams to the appropriate open ip/ports on that firewall. Knowing this policy enables these user agents to setup sessions with user agents on the public Internet. In a third example, a domain A has a limited bandwidth pipe to another domain B. The pipe is realized through two routers that are managed. Domain A would like to direct each call to one of the routers based on their capacity. With session policies, the domain can inform the user agent about the route with the most capacity available. Domains sometimes enforce policies they have in place. For example, a domain might have a configuration in which all packets containing a certain audio codec are dropped. Unfortunately, enforcement mechanisms usually do not inform the user about the policies they are enforcing and silently keep the user from doing anything against them. This may lead to the malfunctioning of devices that is incomprehensible to the user. With session policies, the user knows about the restricted codecs and can use a different codec or simply 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. Some policies are created specifically for a certain session. Such policies usually require that the user agent provides information about the session to the network and receives policies that are tailored to this session. Session-specific policies can be set up using the framework for session-specific policies [3]. Session policies are often independent of a certain session and generally apply to the sessions that are set up by a user agent. In principle, these policies could also be set up on a session-to-session basis. However, it is much more efficient to enable user agents to obtain the policies relevant for them and to Hilt, et al. Expires April 24, 2005 [Page 3] Internet-Draft Session-Independent Policies October 2004 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 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 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, [1] and indicate requirement levels for compliant implementations. 3. Session-Independent Policy Mechanism This draft defines a mechanism for the delivery of session-independent policies to UAs. Session-independent policies 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. This mechanism enables UAs to indicate their support for session policies and to receive policies from different policy servers. 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 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]. Hilt, et al. Expires April 24, 2005 [Page 4] Internet-Draft Session-Independent Policies October 2004 Session-independent policies are frequently provided to a UA by the 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 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: o One (or more) AoRs registered by the UA change. This might be due to a change in the AoR of an existing user or a user is added to/removed from the set of users of a device. The UA SHOULD subscribe each AoR that as changed using the "user" as well as the "local" profile-type. It SHOULD terminate all subscriptions for AoRs not in use any more. 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 Hilt, et al. Expires April 24, 2005 [Page 5] Internet-Draft Session-Independent Policies October 2004 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. Hilt, et al. Expires April 24, 2005 [Page 6] Internet-Draft Session-Independent Policies October 2004 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 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. Hilt, et al. Expires April 24, 2005 [Page 7] Internet-Draft Session-Independent Policies October 2004 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. Hilt, et al. Expires April 24, 2005 [Page 8] Internet-Draft Session-Independent Policies October 2004 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. Hilt, et al. Expires April 24, 2005 [Page 9] Internet-Draft Session-Independent Policies October 2004 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 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 maxBandwidthStream element defines the maximum bandwidth in 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". Hilt, et al. Expires April 24, 2005 [Page 10] Internet-Draft Session-Independent Policies October 2004 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. Hilt, et al. Expires April 24, 2005 [Page 11] Internet-Draft Session-Independent Policies October 2004 PCMU PCMA 4 audio RTP/AVP sendonly RTP/SAVP 4.5 Protocol Policy Schema The protocol policy schema defines the elements and attributes needed to describe protocol characteristics. The namespace of the protocol policy schema is: urn:ietf:params:xml:ns:protocolpolicy 4.5.1 Elements and Attributes The following elements and attributes are defined in the protocol policy schema. 4.5.1.1 Protocol The protocol element defines a protocol policy. Each protocols 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: Hilt, et al. Expires April 24, 2005 [Page 12] Internet-Draft Session-Independent Policies October 2004 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 Hilt, et al. Expires April 24, 2005 [Page 13] Internet-Draft Session-Independent Policies October 2004 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? Hilt, et al. Expires April 24, 2005 [Page 14] Internet-Draft Session-Independent Policies October 2004 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". MESSAGE 100rel application/sdp preconditions 4.6 Media Routing Policy Schema The media routing schema defines the elements and attributes needed to describe address and ports of a media stream. This schema can be used to route the media stream through a NAT, a firewall or a media relay. The namespace of the protocol policy schema is: urn:ietf:params:xml:ns:mediaroutingpolicy OPEN ISSUE: This schema probably needs to go into a separate draft along with some text about the mechanics. Hilt, et al. Expires April 24, 2005 [Page 15] Internet-Draft Session-Independent Policies October 2004 4.6.1 Elements and Attributes The following elements and attributes are defined in the protocol policy schema. 4.6.1.1 Media Routing The mediaRouting element defines a media routing policy. A media routing element MAY appear zero, one or multiple times in a constraint element. Each protocol element has the following sub-elements. 4.6.1.1.1 Address The address element contains the destination address of a media stream, i.e., the address that is contained in an SDP announcement for a media stream. The address element MUST have the following attribute: 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. The address element is optional and MAY appear at most once within a media routing element. 4.6.1.1.2 Port 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. The address element MUST have the following attribute: 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. The port element is optional and MAY appear multiple times within a media routing element. 4.6.1.1.3 Port Range The portRange element identifies a range of ports that apply to the Hilt, et al. Expires April 24, 2005 [Page 16] Internet-Draft Session-Independent Policies October 2004 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: 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. The portRange element is optional and MAY appear multiple times within a media routing element. It has the following two sub-elements. 4.6.1.1.3.1 Start Port The startPort element identifies the lowest port number that belongs to the port range. 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. Hilt, et al. Expires April 24, 2005 [Page 17] Internet-Draft Session-Independent Policies October 2004
123.124.125.126
8000 9000 5. Schema Definitions 5.1 General Policy Schema [TBD.] 5.2 Media Policy Schema 5.3 Protocol Policy Schema Hilt, et al. Expires April 24, 2005 [Page 19] Internet-Draft Session-Independent Policies October 2004 5.4 Media Routing Policy Schema Hilt, et al. Expires April 24, 2005 [Page 21] Internet-Draft Session-Independent Policies October 2004 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 Levels", BCP 14, RFC 2119, March 1997. [2] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in progress), September 2004. [3] Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for Session-Specific Session Policies in the Session Initiation Protocol (SIP)", October 2004. [4] Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003. [5] Moats, R., "URN Syntax", RFC 2141, May 1997. [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [7] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-04 (work in progress), July 2004. [8] Petrie, D., "A Schema for Session Initiation Protocol User Agent Profile Data Sets", draft-petrie-sipping-profile-datasets-00 (work in progress), July 2004. [9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Hilt, et al. Expires April 24, 2005 [Page 22] Internet-Draft Session-Independent Policies October 2004 Session Initiation Protocol", RFC 3261, June 2002. Authors' Addresses Volker Hilt Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA EMail: volkerh@bell-labs.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 USA EMail: jdrosen@dynamicsoft.com Appendix A. Acknowledgements Many thanks to Allison Mankin for the discussions and the suggestions for this draft. Hilt, et al. Expires April 24, 2005 [Page 23] Internet-Draft Session-Independent Policies October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hilt, et al. Expires April 24, 2005 [Page 24]