| SIPPING Working Group | V.H. Hilt |
| Internet-Draft | Bell Labs/Alcatel-Lucent |
| Intended status: Standards Track | D.R. Worley |
| Expires: February 05, 2012 | Avaya Inc. |
| G. Camarillo | |
| Ericsson | |
| J.R. Rosenberg | |
| jdrosen.net | |
| August 04, 2011 |
A User Agent Profile Data Set for Media Policy
draft-ietf-sipping-media-policy-dataset-12
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 can be used to describe the properties of a specific SIP session or to define policies that are then applied to SIP sessions.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 05, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This version of this Internet-Draft is similar to the previous version. It removes earlier revisions to take into account that the formats of session info documents and session policy documents are distinctly different. It has also been submitted to maintain the draft as active. A number of significant open issues are described in this section.
In -10, all media type names that are mentioned in a MPDF are explicitly required to be IANA-registered. Technically, this means that experimental or private-use types can not be used, even in situations where all participants are aware of non-registered media types. In practice, people will go ahead and use them anyway. I am proposing to remove the "registered" requirement.
Per Camarillo (February 25, 2011) this change has been done.
In a number of places, media types are called "MIME types". The latter is common usage, but it is not official, and as RFC 4288 makes clear, media types are independent of their use within MIME. I've fixed the wording of the draft in a number of places to correct this.
Per Camarillo (February 25, 2011) this change has been done.
There is an element <mime-type> that is a child of the <codec> element that carries a media type and subtype. The natural fix would be to change this to <media-type>, but there is already an element of that name that is a child of <stream> that carries a media type (without subtype). I would like a name that means "media type and subtype", but I can't think of a short one. Suggestions?
Per Camarillo (February 25, 2011) the <mime-type> child of <codec> has been changed to <media-type-subtype>.
The Relax NG schema given in draft-ietf-sipping-media-policy-dataset includes "uaprofile.rng". As far as I can figure out, uaprofile.rng is the schema defined in draft-ietf-sipping-profile-datasets, which has been abandoned. So we need to remove the reference to uaprofile.rng. It's possible that there are things defined in that schema that need to be either deleted from draft-ietf-sipping-media-policy-dataset, or copied from the abandoned draft into the schema in draft-ietf-sipping-media-policy-dataset.
If anyone has further information about this, please tell me.
Per Camarillo (February 25, 2011) the line referencing uaprofile.rng has been deleted. The Relax NG definition needs to be reviewed and updated.
I have updated the text of draft-ietf-sipping-media-policy-dataset-11 to consistently use "property-set" rather than sometimes using "property_set". However, it seems to me that the <property-set> element serves no use (now that sipping-profile-datasets has been abandoned). The draft says that each <session-info> and <session-policy> appears in a <property-set>, and <property-set> can contain more than one of each. But there seems to be no practical use for this grouping; the semantics of <session-info> and <session-policy> is completely standalone.
So I am proposing eliminating the <property-set> element entirely, making <session-info> and <session-policy> into top-level elements.
Per Camarillo (February 25, 2011) this change has been done.
There are many properties for which the values are sets of primitive values. The current syntax for specifying sets is awkward. In addition, it is not permitted to specify a set containing zero elements. Sessions containing empty sets are not useful to write, but it is easy to generate them when applying a policy to a <session-info>. So the syntax for set values needs to be updated.
Looking at the XML of draft-ietf-sipping-media-policy-dataset, I see this paragraph:
<!--
<t>If a b= line is present for a media stream, this line MUST be
used to create the bandwidth elements.</t>
-->
SDP provides "b=" lines for specifying bandwidth limitations. Similarly, MPD provides <max-bw>, <max-session-bw>, and <max-stream-bw> elements, and the draft states that they are equivalent to various forms of the b= line. Should we require that when SDP is translated into MPD that the bandwidth limitations be translated?
Per Camarillo (February 25, 2011) this change has been done.
In draft-ietf-sipping-media-policy-dataset-10 there is no explicit way to indicate that a stream has been rejected (which is needed to correspond to an m= line in SDP where the port number is 0). Implicitly, this can be done by setting the port number in the <local-host-port> or <remote-host-port> to 0. But that is pretty ugly. I propose that we introduce an attribute of the <stream> element to indicate that a stream has been rejected/disabled:
<stream enabled="no">
The default value of "enabled" would be "yes".
This resolves the problem of how a policy server would modify a <session-info> to make it conform to a policy if one of the <stream>s contradicted the policy: The policy server would put enabled="no" onto the <stream>.
For consistency, a policy server could effectively reject a proposed session by rejecting all of the streams within it. This would be slightly different than rejecting the session as a whole by returning an empty session-info document, <session-info/>. This distinction corresponds to the difference between an SDP offer/answer negotiation failing, and the negotiation succeeding but the answer rejecting all the m= lines in the SDP.
Now that it has been clarified that session info documents and session policy documents have different formats (though they share many subordinate elements), the use of "MPDF" (Media Policy Document Format) needs to be clarified. I expect that we can use MPDF generically to cover both types of documents, since they are distinguished by their root elements and in most situations by context.
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 for a session (e.g., the media types allowed 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 these elements are used in different contexts for session info and session policy documents, two different root elements exist for the two document types: <session-info> is the root element for session information documents and <session-policy> is the root element for session policy documents.
A user agent can receive multiple session policy documents from different sources. This can lead to a situation in which the user agent needs to apply multiple session policy documents to the same session. This standard specifies merging rules for those XML elements that can be present in session policy documents. It should be noted that these merging rules are part of the semantics of a session policy 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.
Merging rules are not needed for elements of session information documents since they are created by one source and describe a specific session.
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].
This section discusses fundamental properties of the Media Policy Dataset Format (MPDF).
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:
The media type for the Media Policy Dataset Format is:
The MPDF format can 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.
The following attributes can be used with elements of the MPDF format. The specifcation of each MPDF element lists which of these attributes MAY be used. If an element bears an attribute which may not be used with it, the recipient MUST ignore the attribute.
The attribute "visibility" specifies whether or not the user agent is permitted to display the property value to the user. This is used to hide setting values that the administrator may not want the user to see or know. The "visibility" attribute has two possible values:
Some properties are unidirectional and only apply to messages or data streams transmitted into one direction. For example, a property for media streams can be restricted to outgoing media streams only. Unidirectional properties can be expressed by adding a 'direction' attribute to the respective element.
The 'direction' attribute can have the following values:
It is possible to express a preference for a certain value relative to the other values within a set of multiple values that are allowed within a property. For example, it is possible to express that the codecs G.711 and G.729 are allowed, but G.711 is preferred. Preferences are be expressed by adding a 'q' attribute to a property element. As specified for the elements which can have the 'q' attribute, it is only allowed in contexts which specify permitted values (as opposed to contexts which specify forbidden values).
The value of the 'q' attribute is a decimal number within the range 0 to 1, inclusive. An element with a higher 'q' value is preferred over one with a lower 'q' value.
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 the 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 disable the video stream in the session info document that it returns to the UA.
Session info documents use the <session-info> root element. They use elements described in this section and common elements described in Section 7.
Elements that are only present in session info document do not require merging rules. If used in the context of session-specific policies, session info documents are sent to one policy server at a time only, therefore a UA does not need to merge multiple session info documents into one. A policy server needs to modify a session info document it has received according to its policies. The modification of session info documents is determined by the local policies of the policy server and outside the scope of this standard.
A policy server can completely reject a session by returning an session info document with an empty <session-info> element:
If a UA has an SDP offer and answer pair [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 SDP respectively. (The local SDP is the one sent by the UA; 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 <stream> element for each m= line in an SDP description; the order of the <stream> elements corresponds to the order of the m= lines. The UA MUST insert the media type from the m= line into a <media-type> element and MUST create a <codec> element for each codec listed in the m= line.
The UA MUST create a <local-host-port> 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 <remote-host-port> 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.
The numeric value in a "b=CT:..." attribute in a session description is used to set the content of a <max-bw> element with the direction attribute value corresponding to which SDP contains the b= attribute.
The numeric value in a "b=AS:..." attribute in a session description is used to set the content of a <max-session-bw> element with the direction attribute value corresponding to the SDP which contains the b= attribute.
The numeric value in a "b=AS:..." attribute in a media description is used to set the content of a <max-stream-bw> element child of the appropriate <stream> element, with the direction attribute value corresponding to the SDP which contains the b= attribute.
An "a=label:..." attribute [RFC4574] is used to set the 'label' attribute of the appropriate <stream> element.
The mapping from a session info document to a SDP description follows the same rules in the reverse direction.
The <session-info> element describes the properties of a specific SIP session. The <session-info> element MAY contain one optional <streams>, <context> and multiple (including zero) <max-bw>, <max-session-bw>, <max-stream-bw>, <media-intermediaries> and <qos-dscp> elements as well as elements from other namespaces. The MPDF elements are defined in Section 7.
The <streams> element is a container that is used to describe the media streams used in a session. A <streams> element contains zero or more <stream> elements. Each <stream> element describes the properties (e.g., media type, codecs and IP addresses and ports) of a single media stream.
The <stream> 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 a <stream> 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 4.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, whose syntax is defined in [RFC4566]. The token can be chosen freely, however, it MUST be unique among all <stream> elements in a session-info document. If a label attribute [RFC4574] is present in the SDP description, its value MUST be used as the label attribute value of the corresponding <stream> element.
The <stream> element MUST contain one <media-type> element, one or more <codec> elements and one <local-host-port> element. The <stream> element MAY contain one <remote-host-port> element.
The <local-host-port> element contains the hostname or IP address and the receiving 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.
The <remote-host-port> element is structured exactly as the <local-host-port> element. However, it identifies the hostname or IP address and receiving port number of the media stream in the remote session description.
The <media-intermediaries> element expresses a policy for routing a media stream through a media intermediary. The purpose of the <media-intermediaries> 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 <media-intermediaries> 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 <media-intermediaries> element SHOULD therefore only contain intermediary elements of the same type.
This element MAY have the following attributes (see Section 4.3): direction.
Multiple <media-intermediaries> elements MAY only be present in a container if each applies to a different set of streams (e.g., one <media-intermediaries> element for incoming and one for outgoing streams). The <media-intermediaries> element MUST contain one or more elements defining a specific media intermediary, such as <fixed-intermediary> or <turn-intermediary>.
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 contents of a <fixed-intermediary> element MUST be echoed to all policy servers that provide policies for a session. I.e., if multiple policy servers provide policies for the same session, this element needs to be forwarded to all of them, possibly in a second round of session-specific policy subscriptions as described in [I-D.ietf-sip-session-policy-framework] in section Contacting the Policy Server.
The <fixed-intermediary> element MUST contain one <int-host-port> element and MAY contain multiple optional <int-addl-port> elements.
The <int-host-port> 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 <int-host-port> element. All additional port numbers SHOULD be identified in <int-addl-port> elements.
If a protocol uses multiple subsequent ports (e.g., RTP), the lowest port number SHOULD be included in the <int-host-port> element. All additional port numbers SHOULD be identified in <int-addl-port> elements.
The TURN [RFC5766] 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 <turn-intermediary> element MUST contain one <int-host-port> element and MAY contain multiple optional <int-addl-port> elements and zero or one each of the <shared-secret>, <user>, and <transport> elements. If no <transport> element is present, UDP is assumed.
The <shared-secret> element contains the shared secret needed to authenticate at the media intermediary.
The <user> element contains the user ID needed to authenticate to the media intermediary.
The <transport> element contains the name of the transport to be used for communicating with the TURN server. This document defines the values "tcp" and "udp" for use in the <transport> element. Other specifications may define additional values.
The MSRP Relay Extensions [RFC4976] define a means for incorporating relays into the media path of an MSRP [RFC4975] session. MSRP is explicitly designed for a variety of purposes, including policy enforcement.
The <msrp-intermediary> element MUST contain one <msrp-uri> element, and may contain zero or one each of the <shared-secret> and <user> elements.
The <msrp-uri> element contains a URI that indicates the MSRP server to use for an intermediary. The UA uses this URI to authenticate with the MSRP relay, and then uses the URI it learns through that authentication process for any MSRP media it sends or receives. Only URIs with a scheme of "msrps:" are valid in the <msrp-uri> element.
Session policy documents describe policies for SIP sessions. Session policy documents are independent of any 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 can be used to modify the session, if needed, to conform 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 <session-policy> root element. They use elements described in this section and common elements described in Section 7.
A UA may receive session policy documents from multiple sources; multiple session policy documents can be merged into a single session policy document which expresses the logical AND of the policies.
Properties that have a single value (e.g., the maximum bandwidth allowed) require that a common value is determined for this property during the merging process. The merging rules for determining this value need to be defined individually for each element in the schema definition (e.g., select the lowest maximum bandwidth).
The media-types-allowed, media-types-excluded, codecs-allowed and codecs-excluded are containers that contain a set of media-types/codecs. The values defined in these containers need to be merged to determine the set of media-types/codecs that are permissible in a session.
To merge the media-types-* and codecs-* containers a UA needs to apply all containers it has received one after the other the set of media-types/codecs it supports. After applying media-types-*/codecs-* elements, the UA has the list of media-types/codecs that are allowed in a session. The containers can be applied in any order. However, each time a container is applied to the set of media-types/codecs allowed, this set MUST stay the same or be reduced. Media-types/codecs cannot be added during this process.
The following example illustrates the merging process for two data sets. In this example, the UA supports the following set of audio codecs: PCMA, PCMU and G729. After applying session policy document 1, the UA removes PCMA as it is disallowed by this policy. The remaining set of codecs is: PCMU and G729. Session policy document 2 disallows all codecs that are not listed. After applying this policy, the set of codecs allowed is: G729.
Session Policy Document 1: <codecs-excluded> <codec><media-type-subtype>audio/PCMA</media-type-subtype></codec> </codecs> Session Policy Document 2: <codecs-allowed> <codec><media-type-subtype>audio/PCMA</media-type-subtype></codec> <codec><media-type-subtype>audio/G729</media-type-subtype></codec> </codecs>
It is possible that two session policy documents define non-overlapping sets of allowed media-types or codecs. The resulting merged set would be empty, which is illegal according to the schema definition of the media-types/codecs element. This constitutes a conflict that cannot be resolved automatically. If these properties are enforced by both networks, the UA will not be able to set up a session.
The combined set of media-types/codecs MUST again be valid and well-formed according to the schema definitions. A conflict occurs if the combined property set is not a well-formed document after the merging process is completed.
Some properties require that only values from the local policy server are used. The local policy server is the policy server that is in the local domain of the user agent.
If policy documents are delivered through the configuration framework [I-D.ietf-sipping-config-framework], the value received through a subscription using the "local-network" profile-type is used. Values received through other profile-type subscriptions are discarded.
If policy documents are delivered through the session-specific policy mechanism [I-D.ietf-sip-session-policy-framework] the value received from the policy server identified by the Local Policy Server URI are used. Values received from other policy servers are discarded.
The <session-policy> element describes a policy that applies to SIP sessions. The <session-policy> element MAY contain one optional <context> and <local-ports> element and multiple (including zero) <media-types-allowed>, <media-types-excluded>, <codecs-allowed>, <codecs-excluded>, <max-bw>, <max-session-bw>, <max-stream-bw> and <qos-dscp> elements as well as elements from other namespaces. The MPDF elements are defined in Section 7.
The <media-types-allowed> element is a container that is used to define the set of media types (e.g., audio, video) that are allowed in a session. All media types that are not listed in this container are not permitted in a session. A specific media type is allowed by adding the corresponding <media-type> element to this container.
This element MAY have the following attributes (see Section 4.3): direction, visibility.
Multiple <media-types-allowed> elements MAY only be present in a container element if each applies to a different set of streams (e.g., one <media-types-allowed> element for incoming and one for outgoing streams). The <media-types-allowed> element MUST contain zero or more <media-type> elements.
A <media-types-allowed> element MUST NOT be used in a container that contains a <media-types-excluded> element.
The <media-types-excluded> element is a container that is used to define the set of media types (e.g., audio, video) that are not permitted in a session. All media types that are not listed in this container are allowed and can be used in a session. A specific media type is excluded from a session by adding the corresponding <media-type> element to this container.
This element MAY have the following attributes (see Section 4.3): direction, visibility.
Multiple <media-types-excluded> elements MAY only be present in a container element if each applies to a different set of streams (e.g., one <media-types-excluded> element for incoming and one for outgoing streams). The <media-types-excluded> element MUST contain zero or more <media-type> elements.
A <media-types-excluded> element MUST NOT be used in a container that contains a <media-types-allowed> element.
The <codecs-allowed> element is a container that is used to define the set of codecs that may be used in a session. All codes not listed in the <codecs-allowed> element are disallowed and MUST NOT be used in a session. A policy MUST allow the use of at least one codec per media type. A specific codec is allowed by adding the corresponding <codec> element to this container.
The <codecs-allowed> element MAY have the following attributes (see Section 4.3): direction, visibility.
Multiple <codecs-allowed> elements MAY only be present in a container element if each applies to a different set of streams (e.g., one <codecs-allowed> element for incoming and one for outgoing streams). The <codecs-allowed> element MUST contain zero or more <codec> elements.
A <codecs-allowed> element MUST NOT be used in a container that contains a <codecs-excluded> element.
The <codecs-excluded> element is a container that is used to define the set of codecs that are disallowed in a session. All codes not listed in the <codecs-excluded> element are permitted and MAY be used in a session. A specific codec is disallowed by adding the corresponding <codec> element to this container.
The <codecs-excluded> element MAY have the following attributes (see Section 4.3): direction, visibility.
Multiple <codecs-excluded> elements MAY only be present in a container element if each applies to a different set of streams (e.g., one <codecs-excluded> element for incoming and one for outgoing streams). The <codecs-excluded> element MUST contain zero or more <codec> elements.
A <codecs-excluded> element MUST NOT be used in a container that contains a <codecs-allowed> element.
Domains often require that a user agent only uses ports in a certain range for media streams. The <local-ports> element defines a policy for the ports a user agent can use for media. The value of this element consists of the decimal representation of a start port number and an end port number, separated by a "-". The start/end port numbers are the first/last port numbers that can be used, that is, the range is inclusive. The start/end port numbers must be in the range 1 to 65535 (inclusive).
As with other policy elements, there are values of the <local-ports> element that allow no sessions. This happens if the start port number is greater than the end port number.
The default value for <local-ports> is "1-65535".
This element MAY have the following attributes (see Section 4.3): visibility.
This section describes common XML elements that are used in session info and session policy documents to encode the media properties of SIP sessions.
The <media-type> element identifies a specific media type. The value of this element MUST be the name of a media type, such as 'audio', 'video', 'text', or 'application'.
This element MAY have the following attribute (see Section 4.3): q.
If used in a session policy document inside a <media-types-allowed> element, the media types defined MAY be used in a session. If used in a session policy document inside a <media-types-excluded> element, the media types defined MUST NOT be used in a session.
The <codec> element identifies a specific codec. The content of this element MUST be a media type and subtype (e.g., audio/PCMA [RFC4856] or video/H263 [RFC4629]), possibly with parameters.
The <codec> element MAY have the following attribute (see Section 4.3): q.
If used in a session policy document inside a <codecs-allowed> element, the codec defined MAY be used in a session. If used in a session policy document inside a <codecs-excluded> element, the codec defined MUST NOT be used in a session.
The <codec> element MUST contain one <media-type-subtype> element and MAY contain multiple optional <mime-parameter> elements.
The <media-type-subtype> element contains a media type and subtype that identifies a codec. The value of this element MUST be a media type and subtype [RFC4855] separated by a "/" (e.g., audio/PCMA, audio/G726-16 [RFC4856] or video/H263 [RFC4629]).
The <mime-parameter> 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 media 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].
The <max-bw> 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 <max-bw> element includes the bandwidth needed for lower-layer transport and network protocols (e.g., UDP and IP).
The <max-bw> element MAY have the following attribute (see Section 4.3): direction.
If used in a <session-policy> element, the <max-bw> element MAY have the following additional attribute (see Section 4.3): visibility.
If the <max-bw> element occurs multiple times in a container element, each instance MUST apply to a different set of media streams (i.e., one <max-bw> element for outgoing and one for incoming streams).
The <max-session-bw> 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 <max-session-bw> element includes the bandwidth needed for lower-layer transport and network protocols (e.g., UDP and IP).
The <max-session-bw> element MAY have the following attribute (see Section 4.3): direction.
If used in a <session-policy> element, the <max-session-bw> element MAY have the following additional attribute (see Section 4.3): visibility.
If the <max-session-bw> element occurs multiple times in a container element, each instance MUST apply to a different set of media streams (i.e., one <max-session-bw> element for outgoing and one for incoming streams).
The <max-stream-bw> 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 <max-stream-bw> element includes the bandwidth needed as encapsulated in IP (i.e., the RTP, UDP, and IP overheads are included).
The <max-stream-bw> element MAY have the following attributes (see Section 4.3): direction, media-type (only in session policy documents).
If used in a <session-policy> element, the <max-stream-bw> element MAY have the following additional attribute (see Section 4.3): visibility.
If used in a <session-info> element, the <max-stream-bw> element MAY have the following additional attribute: label.
The media-type attribute is used to define that the <max-stream-bw> 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 media type, 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 <stream> element that represents the media stream to which this bandwidth limit applies also has a label attribute. A <max-stream-bw> element with a label attribute applies only to the stream element that has a label attribute with the same value. If no matching <stream> element exists, then the <max-stream-bw> element MUST be ignored.
If the <max-stream-bw> element occurs multiple times in a container element, each instance MUST apply to a different set of media streams (i.e., one <max-stream-bw> element for outgoing and one for incoming streams).
The <qos-dscp> element contains an Differentiated Services Codepoint (DSCP) [RFC2474] value that should be used to populate the IP DS field of media packets. The <qos-dscp> contains a decimal integer value that represents a 6 bit field and therefore ranges from 0 to 63.
This element MAY have the following attributes (see Section 4.3): direction, media-type (only in session policy documents).
If used in a <session-policy> element, the <qos-dscp> element MAY have the following additional attribute (see Section 4.3): visibility.
The media-type attribute is used to specify that the <qos-dscp> 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 media type, such as 'audio', 'video', 'text', or 'application'.
The <qos-dscp> element is optional and MAY occur multiple times inside a container. If the <qos-dscp> element occurs multiple times, each instance MUST apply to a different media stream (i.e., one <qos-dscp> element for audio and one for video streams).
The <context> element provides context information about a session policy or session information document.
The <context> element MAY contain multiple <contact> and one <info> element.
If used in a <session-policy> element, the <context> element MAY also contain a <policy-server-URI> element.
If used in a <session-info> element, the <context> element MAY also contain a <request-URI> and a <token> element.
The <policy-server-URI> element contains the URI of the policy server that has issued this policy.
The <policy-server-URI> element is only permitted inside a <session-policy> element.
The <contact> element contains a URI which is a contact address (e.g., a SIP URI or mailto URI) by which a human representative of the issuer of this document can be reached.
The <info> element provides a short textual description of the policy or session that should be intelligible to the human user.
The <request-URI> element contains the request-URI of the dialog-initiating request of the session.
The <request-URI> element is only permitted inside a <session-info> element.
The <token> element provides a mechanism for a policy server to return an opaque string to a UA. Such a string is sometimes needed to construct a Policy-Id header which ensures that all policy requests concerning a single 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]. Since the token value must be encodable as a SIP URI parameter value, it must consist of ASCII characters, that is, in the range U+0020 to U+007E.
The <token> element is only permitted inside a <session-info> element.
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.
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.
<session-policy>
<context>
<policy-server-URI>policy@biloxi.example.com</policy-server-URI>
<contact>sip:policy_manager@example.com</contact>
<info>Access network policies</info>
</context>
<media-types-allowed>
<media-type>audio</media-type>
<media-type>video</media-type>
</media-types>
<codecs-excluded>
<codec><media-type-subtype>audio/G729</media-type-subtype></codec>
<codec><media-type-subtype>audio/G723</media-type-subtype></codec>
</codecs>
</session-policy>
The following examples contain session descriptions and the session information documents that represent these sessions.
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:
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:
<session-info>
<context>
<contact>sip:alice@somewhere.example</contact>
<info>session information</info>
</context>
<streams>
<stream>
<media-type>audio</media-type>
<codec><media-type-subtype>audio/PCMU</media-type-subtype></codec>
<codec><media-type-subtype>audio/1016</media-type-subtype></codec>
<codec><media-type-subtype>audio/GSM</media-type-subtype></codec>
<local-host-port>host.somewhere.example:49562</local-host-port>
</stream>
<stream>
<media-type>video</media-type>
<codec><media-type-subtype>video/H261</media-type-subtype></codec>
<codec><media-type-subtype>video/H263</media-type-subtype></codec>
<local-host-port>host.somewhere.example:51234</local-host-port>
</stream>
</streams>
</session-info>
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:
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:
<session-info>
<context>
<contact>sip:alice@somewhere.example</contact>
<info>session information</info>
</context>
<streams>
<stream>
<media-type>audio</media-type>
<codec><media-type-subtype>audio/PCMU</media-type-subtype></codec>
<codec><media-type-subtype>audio/GSM</media-type-subtype></codec>
<local-host-port>host.somewhere.example:49562</local-host-port>
<remote-host-port>host.anywhere.example:52124</remote-host-port>
</stream>
<stream>
<media-type>video</media-type>
<codec><media-type-subtype>video/H261</media-type-subtype></codec>
<local-host-port>host.somewhere.example:51234</local-host-port>
<remote-host-port>host.anywhere.example:50286</remote-host-port>
</stream>
</streams>
</session-info>
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.
<session-info>
<context>
<contact>sip:alice@somewhere.example</contact>
<info>modified session information</info>
</context>
<streams>
<stream label='1'>
<media-type>audio</media-type>
<codec><media-type-subtype>audio/PCMU</media-type-subtype></codec>
<codec><media-type-subtype>audio/GSM</media-type-subtype></codec>
<local-host-port>host.somewhere.example:49562</local-host-port>
<remote-host-port>host.anywhere.example:52124</remote-host-port>
</stream>
<stream label='2'>
<media-type>video</media-type>
<codec><media-type-subtype>video/H261</media-type-subtype></codec>
<local-host-port>host.somewhere.example:51234</local-host-port>
<remote-host-port>host.anywhere.example:50286</remote-host-port>
</stream>
</streams>
<max-stream-bw label='2'>128</max-stream-bw>
<max-session-bw>192</max-session-bw>
</session-info>
This section needs to be updated.
<?xml version="1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
ns="urn:ietf:params:xml:ns:mediadataset"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<define name="PropertySetExtension" combine="interleave">
<choice>
<element name="session-info">
<ref name="SettingContainerAttributes"/>
<optional>
<ref name="ElementContext"/>
</optional>
<optional>
<ref name="ElementStreams"/>
</optional>
<zeroOrMore>
<ref name="ElementMaxBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxSessionBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxStreamBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMediaIntermediaries"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementQoSDSCP"/>
</zeroOrMore>
</element>
<element name="session-policy">
<ref name="SettingContainerAttributes"/>
<optional>
<ref name="ElementContext"/>
</optional>
<optional>
<ref name="ElementLocalPorts"/>
</optional>
<zeroOrMore>
<ref name="ElementMediaTypes"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementCodecs"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxSessionBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxStreamBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementQoSDSCP"/>
</zeroOrMore>
</element>
</choice>
</define>
<define name="ElementMediaTypes">
<element name="media-types">
<ref name="PolicyGeneralAttributes"/>
<optional>
<ref name="SettingContainerAttributes"/>
</optional>
<zeroOrMore>
<ref name="ElementMediaType"/>
</zeroOrMore>
</element>
</define>
<define name="ElementMediaType">
<element name="media-type">
<data type="string" />
<optional>
<ref name="AttributeQ"/>
</optional>
<optional>
<ref name="AttributePolicy"/>
</optional>
<optional>
<ref name="AttributeGeneric"/>
</optional>
</element>
</define>
<define name="ElementCodecs">
<element name="codecs">
<ref name="PolicyGeneralAttributes"/>
<optional>
<ref name="SettingContainerAttributes"/>
</optional>
<zeroOrMore>
<ref name="ElementCodec"/>
</zeroOrMore>
</element>
</define>
<define name="ElementCodec">
<element name="codec">
<optional>
<ref name="AttributeQ"/>
</optional>
<optional>
<ref name="AttributePolicy"/>
</optional>
<optional>
<ref name="AttributeGeneric"/>
</optional>
<element name="media-type-subtype">
<data type="string" />
</element>
<zeroOrMore>
<element name="mime-parameter">
<data type="string" />
</element>
</zeroOrMore>
</element>
</define>
<define name="ElementStreams">
<element name="streams">
<optional>
<ref name="AttributeGeneric"/>
</optional>
<oneOrMore>
<ref name="ElementStream"/>
</oneOrMore>
</element>
</define>
<define name="ElementStream">
<element name="stream">
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeLabel"/>
</optional>
<optional>
<ref name="AttributeGeneric"/>
</optional>
<ref name="ElementMediaType"/>
<oneOrMore>
<ref name="ElementCodec"/>
</oneOrMore>
<element name="local-host-port">
<data type="string" />
</element>
<optional>
<element name="remote-host-port">
<data type="string" />
</element>
</optional>
</element>
</define>
<define name="ElementMaxBandwidth">
<element name="max-bw">
<data type="integer" />
<ref name="PolicyGeneralAttributes"/>
</element>
</define>
<define name="ElementMaxSessionBandwidth">
<element name="max-session-bw">
<data type="integer" />
<ref name="PolicyGeneralAttributes"/>
</element>
</define>
<define name="ElementMaxStreamBandwidth">
<element name="max-stream-bw">
<data type="integer" />
<ref name="PolicyGeneralAttributes"/>
<optional>
<ref name="AttributeMediaType"/>
</optional>
<optional>
<ref name="AttributeLabel"/>
</optional>
</element>
</define>
<define name="ElementMediaIntermediaries">
<element name="media-intermediaries">
<ref name="PolicyGeneralAttributes"/>
<oneOrMore>
<choice>
<element name="fixed-intermediary">
<element name="int-host-port">
<data type="string" />
</element>
<zeroOrMore>
<element name="int-addl-port">
<data type="integer" />
</element>
</zeroOrMore>
</element>
<element name="turn-intermediary">
<element name="int-host-port">
<data type="string" />
</element>
<zeroOrMore>
<element name="int-addl-port">
<data type="integer" />
</element>
</zeroOrMore>
<zeroOrMore>
<element name="shared-secret">
<data type="string" />
</element>
</zeroOrMore>
</element>
</choice>
</oneOrMore>
</element>
</define>
<define name="ElementQoSDSCP">
<element name="qos-dscp">
<data type="integer" />
<ref name="PolicyGeneralAttributes"/>
<optional>
<ref name="AttributeMediaType"/>
</optional>
</element>
</define>
<define name="ElementLocalPorts">
<element name="local-ports">
<data type="string" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeGeneric"/>
</optional>
</interleave>
</element>
</define>
<define name="ElementContext">
<element name="context">
<interleave>
<optional>
<element name="info">
<data type="string" />
</element>
</optional>
<optional>
<element name="domain">
<data type="string" />
</element>
</optional>
<optional>
<element name="request-URI">
<data type="string" />
</element>
</optional>
<optional>
<element name="token">
<data type="string" />
</element>
</optional>
<zeroOrMore>
<element name="contact">
<data type="string" />
</element>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="PolicyGeneralAttributes">
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeGeneric"/>
</optional>
</define>
<define name="AttributeMediaType">
<attribute name="media-type">
<data type="string" />
</attribute>
</define>
<define name="AttributeLabel">
<attribute name="label">
<data type="string" />
</attribute>
</define>
</grammar>
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.
This document registers a new media type, application/media-policy-dataset+xml, and a new XML namespace.
Media type name: application
Media 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 10 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, <volkerh@bell-labs.com>
Intended usage: COMMON
Author/Change controller: The IETF.
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, <sipping@ietf.org>, Volker Hilt, <volkerh@bell-labs.com>
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Media Policy Dataset Namespace</title>
</head>
<body>
<h1>Namespace for Media Policy Datasets</h1>
<h2>urn:ietf:params:xml:ns:mediadataset</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
| [I-D.ietf-sip-session-policy-framework] | Hilt, V, Camarillo, G and J Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", Internet-Draft draft-ietf-sip-session-policy-framework-10, February 2011. |
| [I-D.ietf-sipping-config-framework] | Channabasappa, S, "A Framework for Session Initiation Protocol User Agent Profile Delivery", Internet-Draft draft-ietf-sipping-config-framework-18, October 2010. |
| [RFC2648] | Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. |
| [RFC4856] | Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007. |
| [RFC4629] | Ott, H.263Video.J., Bormann, C., Sullivan, G., Wenger, S. and R. Even, "RTP Payload Format for ITU-T Rec", RFC 4629, January 2007. |
| [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. |
Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach and Ben Campbell 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.