From: http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-dataset-06.txt Title: A User Agent Profile Data Set for Media Policy Reference: IETF SIPPING Working Group, Internet Draft 'draft-ietf-sipping-media-policy-dataset-06' Date: July 12, 2008 I-D Tracker: http://ietfreport.isoc.org/idref/draft-ietf-sipping-media-policy-dataset/ Tools: http://tools.ietf.org/html/draft-ietf-sipping-media-policy-dataset-06 See also: IETF Session Initiation Proposal Investigation (SIPPING) Working Group Charter http://www.ietf.org/html.charters/sipping-charter.html Session Initiation Proposal Investigation Status Pages http://tools.ietf.org/wg/sipping (SIPPING) Working Group Supplemental Home Page http://www.softarmor.com/sipping IETF Real-time Applications and Infrastructure Area http://www.ietf.org/html.charters/wg-dir.html#Real-time%20Applications%20and%20Infrastructure%20Area ============================================================================== Sipping Working Group V. Hilt Internet-Draft Bell Labs/Alcatel-Lucent Intended status: Standards Track G. Camarillo Expires: January 13, 2009 Ericsson J. Rosenberg Cisco July 12, 2008 A User Agent Profile Data Set for Media Policy draft-ietf-sipping-media-policy-dataset-06 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 13, 2009. Abstract This specification defines a document format for the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in a session. This document format is based on XML and extends the Schema for SIP User Agent Profile Data Sets. It can be used to describe the properties of a specific SIP session or to define policies that are then applied to different SIP sessions. Hilt, et al. Expires January 13, 2009 [Page 1] Internet-Draft Media Policy Dataset July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 3.1. Namespace and MIME Type . . . . . . . . . . . . . . . . . 5 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Inheritance from the Profile Data Set . . . . . . . . . . 6 4. Session Info Documents . . . . . . . . . . . . . . . . . . . . 6 4.1. The Element . . . . . . . . . . . . . . . . 7 4.2. Mapping SDP to Session Info Documents . . . . . . . . . . 7 5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 8 5.1. The Element . . . . . . . . . . . . . . . 8 6. Media Property Elements . . . . . . . . . . . . . . . . . . . 8 6.1. The Element . . . . . . . . . . . . . . . . 8 6.1.1. The Element . . . . . . . . . . . . . . . 9 6.2. The Element . . . . . . . . . . . . . . . . . . . 9 6.2.1. The Element . . . . . . . . . . . . . . . . . 10 6.3. The Element . . . . . . . . . . . . . . . . . . 10 6.3.1. The Element . . . . . . . . . . . . . . . . . 11 6.4. The Element . . . . . . . . . . . . . . . . . . . 12 6.5. The Element . . . . . . . . . . . . . . . 12 6.6. The Element . . . . . . . . . . . . . . . 13 6.7. The Element . . . . . . . . . . . . 14 6.7.1. The Element . . . . . . . . . . . 15 6.7.2. The Element . . . . . . . . . . . 16 6.8. The Element . . . . . . . . . . . . . . . . . . 16 6.9. The Element . . . . . . . . . . . . . . . . 17 6.10. The Element . . . . . . . . . . . . . . . . . . 17 6.10.1. The Element . . . . . . . . . . . . . . . . . 17 6.10.2. The Element . . . . . . . . . . . . . . . . 18 6.10.3. The Element . . . . . . . . . . . . . . . . . . 18 6.10.4. The Element . . . . . . . . . . . . . . 18 6.10.5. The Element . . . . . . . . . . . . . . . . . 18 6.11. Other Session Properties . . . . . . . . . . . . . . . . . 18 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Session Policy Documents . . . . . . . . . . . . . . . . . 19 7.2. Session Information Documents . . . . . . . . . . . . . . 19 7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 20 8. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10.1. MIME Registration . . . . . . . . . . . . . . . . . . . . 30 10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . . 33 Hilt, et al. Expires January 13, 2009 [Page 2] Internet-Draft Media Policy Dataset July 2008 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 35 Hilt, et al. Expires January 13, 2009 [Page 3] Internet-Draft Media Policy Dataset July 2008 1. Introduction The Framework for Session Initiation Protocol (SIP) [RFC3261] User Agent Profile Delivery [I-D.ietf-sipping-config-framework] and the Framework for SIP Session Policies [I-D.ietf-sip-session-policy-framework] define mechanisms to convey session policies and configuration information from a network server to a user agent. An important piece of the information conveyed to the user agent relates to the media properties of the SIP sessions set up by the user agent. Examples for these media properties are the codecs and media types used, the media-intermediaries to be traversed or the maximum bandwidth available for media streams. This specification defines a document format for media properties of SIP sessions, the Media Policy Dataset Format (MPDF). This format can be used in two ways: first, it can be used to describe the properties of a given SIP session (e.g., the media types and codecs used). These MPDF documents are called session info documents and they are usually created based on the session description of a session. Second, the MPDF format can be used to define policies for SIP sessions in a session policy document. A session policy document defines properties (e.g., the media types) that can or can not be used in a session, independent of a specific session description. If used with the Framework for SIP Session Policies [I-D.ietf-sip-session-policy-framework], session info documents are used in conjunction with session-specific policies. A session info document is created by a UA based on the current session description and submitted to the policy server. The policy server examines the session info document, modifies it if necessary (e.g., by removing video streams if video is not permitted) and returns the possibly modified session info document to the UA. Session policy documents on the other hand are used to describe session-independent policies that can be submitted to the UA independent of a specific session. The two types of MPDF documents, session information and session policy documents, share the same set of XML elements to describe session properties. Since the usage of these elements differs between the two document types, they both use different root elements: is the root element for session information documents and is the root element for session policy documents. This enables the recipient of a document to determine the document type and to correctly interpret the media properties defined. A user agent can receive multiple session policy documents from different sources. These documents need to be merged into a single document the user agent can work with. This document specifies rules Hilt, et al. Expires January 13, 2009 [Page 4] Internet-Draft Media Policy Dataset July 2008 for merging each of the XML elements defined. It should be noted that these merging rules are part of the semantics of the XML element. User agents implement the merging rules as part of implementing the element semantics. As a consequence, it is not possible to build an entity that can mechanically merge two session policy documents without understanding the semantics of all elements in the input documents. The Schema for SIP User Agent Profile Data Sets [I-D.ietf-sipping-profile-datasets] describes common merging rules that are referred to in this specification. Merging is not needed for session information documents since they are created by one source and describe a specific session. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Design Considerations This section discusses design considerations for the Media Policy Dataset Format. 3.1. Namespace and MIME Type The MPDF format is based on XML [W3C.REC-xml-20040204]. A MPDF document MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validator and applicable to the XML document. MPDF documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The namespace URIs for schemas defined in this specification are URNs [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. The namespace URN for the MPDF schema is: urn:ietf:params:xml:ns:mediadataset The MIME type for the Media Policy Dataset Format is: application/media-policy-dataset+xml Hilt, et al. Expires January 13, 2009 [Page 5] Internet-Draft Media Policy Dataset July 2008 3.2. Extensibility The MPDF format extends the Schema for SIP User Agent Profile Data Sets [I-D.ietf-sipping-profile-datasets] by specifying a data set for media properties. Elements from the MPDF namespace can be used in conjunction with elements from other extensions of this schema. The MPDF format itself can also be extended using XML extension mechanisms if additional media properties are needed. In particular, elements from different XML namespaces MAY be present within a MPDF document for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. 3.3. Inheritance from the Profile Data Set The MPDF format inherits the following attributes from the Profile Data Set Schema [I-D.ietf-sipping-profile-datasets]: o Property Access Control: 'visibility' attribute o Policies: 'policy' and 'excluded-policy' attribute o Unidirectional Properties: 'direction' attribute o Preferences: 'q' attribute The use of these attributes is defined individually for each element in the XML format below. The MPDF format also uses merging algorithms that are defined in the Profile Data Set Schema. The use of these algorithms is defined individually for each element in the XML format below. 4. Session Info Documents Session info documents describe key properties of a SIP session such as the media streams used in the session. Session info documents are typically created based on an SDP [RFC4566] session description or an SDP offer/answer pair [RFC3264]. Session info documents can be used for session-specific policies [I-D.ietf-sip-session-policy-framework]. In this usage, a UA creates a session info document based on its SDP description(s) and sends this document to the policy server. The policy server modifies this document according to the policies that apply to the described session and returns a version of the session info document that is compliant to all policies. For example, if video streams are not permissible under current policies and the UA submits a session info document that contains a video stream, the policy server will remove the video stream from the XML markup and return the modified session Hilt, et al. Expires January 13, 2009 [Page 6] Internet-Draft Media Policy Dataset July 2008 info document to the UA. Session info documents use the element. A policy server can completely reject a session by returning an session info document with an empty element: <\session-info> 4.1. The Element The element describes the properties of a specific SIP session. The element MAY occur multiple times inside a [I-D.ietf-sipping-profile-datasets] element. The element MAY contain one optional , and multiple (including zero) , , , and elements as well as elements from other namespaces. The MPDF elements are defined in Section 6. 4.2. Mapping SDP to Session Info Documents If a UA has an SDP offer as well as an answer [RFC3264] and wants to create a session info document, the UA MUST use the answer to fill in the elements of the session info document except for the remote-host- port and local-host-port elements, which are taken from the remote and local session description respectively. The local session description is the one created locally by the UA (i.e., the offer if the UA has initiated the offer/answer exchange). The remote session description is the one received from the remote UA. The following rules describe the creation of session info documents based on SDP description(s) for a few exemplary elements. Other elements are created following the same principles. A UA MUST create a separate element for each m= line in an SDP description. The UA MUST insert the media type from the m= line into a element and MUST create a element for each codec listed in the m= line. The UA MUST create a element for each stream using the port taken from the m= line and the address from the corresponding c= line of the local session description. The UA MUST create a element using the port and address from the m= and c= lines for the same stream taken from the remote session description if this session description is available. Hilt, et al. Expires January 13, 2009 [Page 7] Internet-Draft Media Policy Dataset July 2008 The mapping from a session info document to a SDP description follows the same rules in the reverse direction. 5. Session Policy Documents Session policy documents describe a policy for SIP sessions. Session policy documents are independent of a specific session description and express general policies for SIP sessions. A session policy document is used to determine if a SIP session is policy conformant and to modify this session, if needed, according to the described policies. Session policy documents can be used to encode session-independent policies [I-D.ietf-sip-session-policy-framework]. In this usage, a policy server creates a session policy document and passes this document to a UA. The UA applies the policies defined to the SIP sessions it is establishing. For example, a session policy document can contain an element that prohibits the use of video. To set up a session that is compliant to this policy, a UA does not include the media type video in its SDP offer or answer. Session policy documents use the element. 5.1. The Element The element describes a policy that applies to SIP sessions. The element MAY occur multiple times inside a [I-D.ietf-sipping-profile-datasets] element. The element MAY contain one optional and element and multiple (including zero) , , , , and elements as well as elements from other namespaces. The MPDF elements are defined in Section 6. 6. Media Property Elements This section describes XML elements that are used in session info and session policy documents to encode the media properties of SIP sessions. 6.1. The Element The element is a container that is used to define the set of media types (e.g., audio, video) that can or cannot be used in a session. A specific media type is included in the set by adding Hilt, et al. Expires January 13, 2009 [Page 8] Internet-Draft Media Policy Dataset July 2008 the corresponding element to this container. The element can only be used in session policy document (i.e., inside the container). This element MAY have the following attributes (see Section 3.3): direction, visibility, excluded-policy. Multiple elements MAY only be present in a container element if each applies to a different set of streams (e.g., one element for incoming and one for outgoing streams). The element MUST contain one or more elements. Merging of session-policy documents: containers are merged using the "Multiple Enumerated Value Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. 6.1.1. The Element The element identifies a specific media type. The value of this element MUST be the name of a IANA registered media type (see RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 'application'. This element MAY have the following attribute (see Section 3.3): q. If used inside a element, this element MAY have the following additional attribute (see Section 3.3): policy. Media types that have the policy 'allowed' MAY be used and media types with the policy 'disallowed' MUST NOT be used. 6.2. The Element The element is a container that is used to define the set of codecs that may or may not be used in a session. A policy MUST allow the use of at least one codec per media type. A specific codec is included in the set by adding the corresponding element to this container. The element can only be used in a session policy document (i.e., inside the container). The element MAY have the following attributes (see Section 3.3): direction, visibility, excluded-policy. Multiple elements MAY only be present in a container element if each applies to a different set of streams (e.g., one Hilt, et al. Expires January 13, 2009 [Page 9] Internet-Draft Media Policy Dataset July 2008 element for incoming and one for outgoing streams). The element MUST contain one or more elements. Merging of session-policy documents: containers are merged using the "Multiple Enumerated Value Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. 6.2.1. The Element The element identifies a specific codec. The content of this element MUST be a registered MIME type [RFC4855] using media type and subtype (e.g., audio/PCMA [RFC4856] or video/H263 [RFC4629]) and possibly additional registered MIME type parameters. The element MAY have the following attribute (see Section 3.3): q. If used inside a element, the element MAY have the following additional attribute (see Section 3.3): policy. Codecs that have the policy 'allowed' MAY be used and codecs with the policy 'disallowed' MUST NOT be used. The element MUST contain one element and MAY contain multiple optional elements. 6.2.1.1. The Element The element contains a MIME type that identifies a codec. The value of this element MUST be a combination of a registered MIME media type and subtype [RFC4855] separated by a "/" (e.g., audio/ PCMA, audio/G726-16 [RFC4856] or video/H263 [RFC4629]). 6.2.1.2. The Element The element may be needed for some codecs to identify a particular encoding or profile. The value of this element MUST be a name-value pair containing the name and the value of a registered MIME type parameter for the codec [RFC4855]. The name and value are separated by a "=". For example, the parameter "profile=0" can be used to specify a specific profile for the codec "video/ H263-2000" [RFC4629]. 6.3. The Element The element is a container that is used to describe the media streams used in a session. A element can contain multiple elements. Each element describes the properties (e.g., media type, codecs and IP addresses and ports) of a Hilt, et al. Expires January 13, 2009 [Page 10] Internet-Draft Media Policy Dataset July 2008 single media stream. The element is only defined for session information documents (i.e., in a container). The element MUST contain one or more elements. 6.3.1. The Element The element describes a specific media stream. It contains the media type, codecs and the hostname(s) or IP address(es) and port(s) of this stream. The hostname(s) or IP address(es) and port number(s) of a stream correspond to the ones listed in the session description(s). A UA that generates element MUST insert the hostname/port found in the local session description for this media stream into the local-host-port element. The UA MUST insert the hostname/port of the remote session description into the remote-host-port element, if the remote session description is available to the UA. If not, the UA generates a stream element that only contains the local-host-port element. This element MAY have the following attributes (see Section 3.3): direction, label. The label attribute is used to identify a specific media stream in a session description. The value of the label attribute is a token. The token can be chosen freely, however, it MUST be unique among all element in a session-info document. If a label attribute [RFC4574] is present in the SDP description, its value MUST be carried over to the label attribute of the corresponding element. The element MUST contain one element, one or more elements and one element. The element MAY contain one element. 6.3.1.1. The Element The element contains the hostname or IP address and the port number of the media stream in the local session description. The hostname or IP address is separated from the port by a ":". An example is: "host.example.com:49562". The hostname or IP address of element is found in the c= element for the stream in the local SDP description. The port number is found in the m= element. Hilt, et al. Expires January 13, 2009 [Page 11] Internet-Draft Media Policy Dataset July 2008 6.3.1.2. The Element The element is structured exactly as the element. However, it identifies the hostname or IP address and port number of the media stream in the remote session description. 6.4. The Element The element defines the overall maximum bandwidth in kilobits per second an entity can/will use for media streams at any point in time. It defines an upper limit for the total bandwidth an entity can/will use for the transmission of media streams. The limit corresponds to the sum of the maximum session bandwidth of all sessions a UA may set up in parallel. The bandwidth limit given in the element includes the bandwidth needed for lower-layer transport and network protocols (e.g., UDP and IP). The element MAY have the following attribute (see Section 3.3): direction. If used in a element, the element MAY have the following additional attribute (see Section 3.3): visibility. If the element occurs multiple times in a container element, each instance MUST apply to a different set of media streams (i.e., one element for outgoing and one for incoming streams). Merging of session-policy documents: the lowest max-bw value is used. 6.5. The Element The element defines the maximum bandwidth in kilobits per second an entity can/will use for media streams in the described session. It defines an upper limit for the total bandwidth of a single session. This limit corresponds to the sum of the maximum stream bandwidth of all media streams in a session. The bandwidth limit given in the element includes the bandwidth needed for lower-layer transport and network protocols (e.g., UDP and IP). The value of the element is equivalent to the CT bandwidth in the b= line of an SDP [RFC4566] annoncement. Hilt, et al. Expires January 13, 2009 [Page 12] Internet-Draft Media Policy Dataset July 2008 The element MAY have the following attribute (see Section 3.3): direction. If used in a element, the element MAY have the following additional attribute (see Section 3.3): visibility. If the element occurs multiple times in a container element, each instance MUST apply to a different set of media streams (i.e., one element for outgoing and one for incoming streams). Merging of session-policy documents: the lowest max-session-bw value is used. 6.6. The Element The element defines the maximum bandwidth in kilobits per second an entity can/will use for each media stream in the described session. The bandwidth limit given in the element includes the bandwidth needed for lower-layer transport and network protocols (e.g., UDP and IP). The value of the element is equivalent to the AS bandwidth in the b= line of an SDP [RFC4566] annoncement. The element MAY have the following attribute (see Section 3.3): direction, media-type. If used in a element, the element MAY have the following additional attribute (see Section 3.3): visibility. If used in a element, the element MAY have the following additional attribute: label. The media-type attribute is used to define that the element only applies to streams of a certain media type. For example, it may only apply to audio streams. The value of the 'media-type' attribute MUST be the name of a IANA registered media type (see RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 'application'. The label attribute is used to define a bandwidth limit for a specific media stream. The use of this attribute requires that the element that respresents the media stream to which this Hilt, et al. Expires January 13, 2009 [Page 13] Internet-Draft Media Policy Dataset July 2008 bandwidth limit applies also has a label attribute. A element with a label attribute applies only to the stream element that has a label attribute with the same value. If no matching element exists, then the element MUST be ignored. If the element occurs multiple times in a container element, each instance MUST apply to a different set of media streams (i.e., one element for outgoing and one for incoming streams). Merging of session-policy documents: the lowest max-stream-bw value is used. 6.7. The Element The element expresses a policy for routing a media stream through a media intermediary. The purpose of the element is to tell the UA to send a media stream through one (or a chain of) media intermediaries. Instead of sending the media directly to its final destination, the UA specifies a source route, which touches each intermediary and then reaches the final recipient. If there are N hops, including the final recipient, there needs to be a way for the media stream to specify N destinations. The element is a container that lists all media intermediaries to be traversed. Media intermediaries should be traversed in the order in which they appear in this list. The topmost entry should be traversed first, the last entry should be traversed last. Different types of intermediaries exist. These intermediaries are not necessarily interoperable and it may not be possible to chain them in an arbitrary order. A element SHOULD therefore only contain intermediary elements of the same type. This element MAY have the following attributes (see Section 3.3): direction. Multiple elements MAY only be present in a container if each applies to a different set of streams (e.g., one element for incoming and one for outgoing streams). The element MUST contain one or more of the following elements: and . Hilt, et al. Expires January 13, 2009 [Page 14] Internet-Draft Media Policy Dataset July 2008 Merging of session-policy documents: the intermediaries defined in all policies are traversed. In general, local intermediaries should be traversed before remote intermediaries. During the merging process, element values from different servers are ordered using the "Closest Value First Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The intermediaries should be traversed in this order. Note: it is not intended that the element replaces connectivity discovery mechanisms such as ICE. Instead of finding media relays that provide connectivity, this element defines a policy for media intermediaries that should be traversed. The set of intermediaries defined in the element and the ones discovered through ICE may overlap but don't have to. 6.7.1. The Element A fixed intermediary relies on pre-configured forwarding rules. The user agent simply sends media to the first media intermediary listed. It can assume that this media intermediary has been pre-configured with a forwarding rule for the media stream and knows where to forward the packets to. The configuration of forwarding rules in the intermediary must be done through other means. The element MUST contain one element and MAY contain multiple optional elements. 6.7.1.1. The Element The element contains the hostname or IP address and port number of a media intermediary. The UA uses this hostname/IP address and port to send its media streams to the intermediary. The hostname or IP address is separated from the port by a ":". If a protocol uses multiple subsequent ports (e.g., RTP), the lowest port number SHOULD be included in the element. All additional port numbers SHOULD be identified in elements. 6.7.1.2. The Element If a protocol uses multiple subsequent ports (e.g., RTP), the lowest port number SHOULD be included in the element. All additional port numbers SHOULD be identified in elements. Hilt, et al. Expires January 13, 2009 [Page 15] Internet-Draft Media Policy Dataset July 2008 6.7.2. The Element The TURN [I-D.ietf-behave-turn] protocol provides a mechanism for inserting a relay into the media path. Although the main purpose of TURN is NAT traversal, it is possible for a TURN relay to perform other media intermediary functionalities. The user agent establishes a binding on the TURN server and uses this binding to transmit and receive media. The element MUST contain one element and MAY contain multiple optional elements and one optional element. 6.7.2.1. The Element The element contains the shared secret needed to authenticate at the TURN server. 6.8. The Element The element contains an Differentiated Services Codepoint (DSCP) [RFC2474] value that should be used to populate the IP DS field of media packets. The contains an integer value that represents a 6 bit field and therefore ranges from 0 to 63. This element MAY have the following attributes (see Section 3.3): direction, media-type. If used in a element, the element MAY have the following additional attribute (see Section 3.3): visibility. The media-type attribute is used to define that element only applies to streams of a certain media type. For example, it may only apply to audio streams. The value of the 'media-type' attribute MUST be the name of a IANA registered media type (see RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 'application'. The element is optional and MAY occur multiple times inside a container. If the element occurs multiple times, each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). Merging of session-policy documents: the domain that is first traversed by the media stream has precedence and its DSCP value is used. During the merging process, element values from different servers are ordered using the "Closest Value First Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The DSCP Hilt, et al. Expires January 13, 2009 [Page 16] Internet-Draft Media Policy Dataset July 2008 value from the closest server is used. 6.9. The Element Domains often require that a user agent only uses ports in a certain range for media streams. The element defines a policy for the ports a user agent can use for media. The value of this element consists of a start port and an end port separated by a "-". The start/end port is the first/last port that can be used. This element MAY have the following attributes (see Section 3.3): visibility. The element is only defined for session policy documents (i.e., in a container). Merging of session-policy documents: the domain that is first traversed by the media stream has precedence and its local ports value is used. During the merging process, element values from different servers are ordered using the "Closest Value First Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The value from the closest server is used. 6.10. The Element The element provides context information about a session policy or session information document. The element MAY contain multiple and one element. If used in a element, the element MAY also contain a element. If used in a element, the element MAY also contain a and a element. Merging of session-policy documents: the element is not subject to merging. 6.10.1. The Element The element contains a URI that identifies the domain which has issued this policy. The element is only defined inside a element. Hilt, et al. Expires January 13, 2009 [Page 17] Internet-Draft Media Policy Dataset July 2008 6.10.2. The Element The element contains a contact address (e.g., a SIP URI or email address) under which the issuer of this document can be reached. 6.10.3. The Element The element provides a short textual description of the policy or session that should be intelligible to the human user. 6.10.4. The Element The element identifies the request-URI the dialog initiating request of a session is sent to. The element is only defined inside a element. 6.10.5. The Element The element provides a mechanism for a policy server to return an opaque token to a UA. This is sometimes needed to ensure that all requests for a session are routed to the same policy server. The use of this token is described in the Framework for SIP Session Policies [I-D.ietf-sip-session-policy-framework]. The element is only defined inside a element. 6.11. Other Session Properties A number of additional elements have been proposed for a media property language. These elements are deemed to be outside the scope of this format. However, they may be defined in extensions of MPDF or other profile data sets. o maximum number of streams o maximum number of sessions o maximum number of streams per session o external address and port o media transport protocol o outbound proxy o SIP methods o SIP option tags o SIP transport protocol o body disposition Hilt, et al. Expires January 13, 2009 [Page 18] Internet-Draft Media Policy Dataset July 2008 o body format o body encryption 7. Examples 7.1. Session Policy Documents The following example describes a session policy document that allows the use of audio and video and prohibits the use of other media types. It allows the use of any codec except G.723 and G.729. example.com sip:policy_manager@example.com Access network policies audio video audio/G729 audio/G723 7.2. Session Information Documents The following examples contain session descriptions and the session information documents that represent these sessions. 7.2.1. Example 1 In this example, a session info document is created based on one session description. This session info document would be created, for example, by a UA that has composed an offer and is now contacting a policy server. Local SDP session description: Hilt, et al. Expires January 13, 2009 [Page 19] Internet-Draft Media Policy Dataset July 2008 v=0 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example s= c=IN IP4 host.somewhere.example t=0 0 m=audio 49562 RTP/AVP 0 1 3 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 m=video 51234 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000 MPDF document: sip:alice@somewhere.example session information audio audio/PCMU audio/1016 audio/GSM host.somewhere.example:49562 video video/H261 video/H263 host.somewhere.example:51234 7.2.2. Example 2 In this example, a session info document is created that represents two session descriptions (i.e., an offer and answer). This session info document would be created, for example, by a UA that has received an answer from another UA and is now contacting a policy server. Local SDP session description: Hilt, et al. Expires January 13, 2009 [Page 20] Internet-Draft Media Policy Dataset July 2008 v=0 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example s= c=IN IP4 host.somewhere.example t=0 0 m=audio 49562 RTP/AVP 0 1 3 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 m=video 51234 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000 Remote SDP session description: v=0 o=bob 2890844730 2890844730 IN IP4 host.anywhere.example s= c=IN IP4 host.anywhere.example t=0 0 m=audio 52124 RTP/AVP 0 3 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 m=video 50286 RTP/AVP 31 a=rtpmap:31 H261/90000 MPDF document that represents the local and the remote session description: Hilt, et al. Expires January 13, 2009 [Page 21] Internet-Draft Media Policy Dataset July 2008 sip:alice@somewhere.example session information audio audio/PCMU audio/GSM host.somewhere.example:49562 host.anywhere.example:52124 video video/H261 host.somewhere.example:51234 host.anywhere.example:50286 The following MPDF document is a modified version of the above document, which can be returned by a policy server. This document reflects a policy that defines a maximum session bandwidth of 192 kbit and a maximum bandwidth for the H261 video stream of 128 kbit. Hilt, et al. Expires January 13, 2009 [Page 22] Internet-Draft Media Policy Dataset July 2008 sip:alice@somewhere.example modified session information audio audio/PCMU audio/GSM host.somewhere.example:49562 host.anywhere.example:52124 video video/H261 host.somewhere.example:51234 host.anywhere.example:50286 128 192 8. Relax NG Definition ?xml version="1.0"?> Hilt, et al. Expires January 13, 2009 [Page 23] Internet-Draft Media Policy Dataset July 2008 Hilt, et al. Expires January 13, 2009 [Page 24] Internet-Draft Media Policy Dataset July 2008 Hilt, et al. Expires January 13, 2009 [Page 25] Internet-Draft Media Policy Dataset July 2008 Hilt, et al. Expires January 13, 2009 [Page 26] Internet-Draft Media Policy Dataset July 2008 Hilt, et al. Expires January 13, 2009 [Page 27] Internet-Draft Media Policy Dataset July 2008 Hilt, et al. Expires January 13, 2009 [Page 28] Internet-Draft Media Policy Dataset July 2008 Hilt, et al. Expires January 13, 2009 [Page 29] Internet-Draft Media Policy Dataset July 2008 9. Security Considerations Session policy information can be sensitive information. The protocol used to distribute session policy information SHOULD ensure privacy, message integrity and authentication. Furthermore, the protocol SHOULD provide access controls which restrict who can see who else's session policy information. 10. IANA Considerations This document registers a new MIME type, application/ media-policy-dataset+xml, and a new XML namespace. 10.1. MIME Registration MIME media type name: application MIME subtype name: media-policy-dataset+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [RFC3023]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023]. Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 9 of this specification. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type has been used to convey media policy information between SIP user agents and a domain. Additional Information: Magic Number: None File Extension: .mpf or .xml Macintosh file type code: "TEXT" Personal and email address for further information: Volker Hilt, Hilt, et al. Expires January 13, 2009 [Page 30] Internet-Draft Media Policy Dataset July 2008 Intended usage: COMMON Author/Change controller: The IETF. 10.2. URN Sub-Namespace Registration This section registers a new XML namespace, as per the guidelines in [RFC3688] URI: The URI for this namespace is urn:ietf:params:xml:ns:mediadataset. Registrant Contact: IETF, SIPPING working group, , Volker Hilt, XML: BEGIN Media Policy Dataset Namespace

Namespace for Media Policy Datasets

urn:ietf:params:xml:ns:mediadataset

See RFCXXXX.

END 11. References 11.1. Normative References [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-08 (work in progress), June 2008. Hilt, et al. Expires January 13, 2009 [Page 31] Internet-Draft Media Policy Dataset July 2008 [I-D.ietf-sipping-profile-datasets] Dolly, M., Channabasappa, S., Ganesan, S., and V. Hilt, "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets", draft-ietf-sipping-profile-datasets-01 (work in progress), July 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [W3C.REC-xml-20040204] Maler, E., Bray, T., Sperberg-McQueen, C., Yergeau, F., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml- 20040204, February 2004, . [W3C.REC-xml-names-19990114] Layman, A., Hollander, D., and T. Bray, "Namespaces in XML", World Wide Web Consortium FirstEdition REC-xml- names-19990114, January 1999, . Hilt, et al. Expires January 13, 2009 [Page 32] Internet-Draft Media Policy Dataset July 2008 11.2. Informative References [I-D.ietf-sip-session-policy-framework] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", draft-ietf-sip-session-policy-framework-03 (work in progress), April 2008. [I-D.ietf-sipping-config-framework] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-15 (work in progress), February 2008. [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. Even, "RTP Payload Format for ITU-T Rec", RFC 4629, January 2007. [RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007. Appendix A. Acknowledgements Many thanks to Allison Mankin, Dan Petrie and Martin Dolly for the discussions and suggestions. Many thanks to Roni Even and Mary Barnes for reviewing the draft and to Jari Urpalainen for helping with the Relax NG schema. Hilt, et al. Expires January 13, 2009 [Page 33] Internet-Draft Media Policy Dataset July 2008 Authors' Addresses Volker Hilt Bell Labs/Alcatel-Lucent 791 Holmdel-Keyport 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 Edison, NJ USA Email: jdrosen@cisco.com Hilt, et al. Expires January 13, 2009 [Page 34] Internet-Draft Media Policy Dataset July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Hilt, et al. Expires January 13, 2009 [Page 35]