[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-sipping-session-indep-policy) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 draft-camarillo-rai-media-policy-dataset

SIPPING Working Group                                            V. Hilt
Internet-Draft                                  Bell Labs/Alcatel-Lucent
Intended status: Standards Track                               D. Worley
Expires: August 6, 2011                                       Avaya Inc.
                                                            G. Camarillo
                                                                Ericsson
                                                            J. Rosenberg
                                                             jdrosen.net
                                                        February 2, 2011


             A User Agent Profile Data Set for Media Policy
               draft-ietf-sipping-media-policy-dataset-11

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 can be used to describe the
   properties of a specific SIP session or to define policies that are
   then applied to SIP sessions.

Status of this Memo

   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 August 6, 2011.

Copyright Notice

   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



Hilt, et al.             Expires August 6, 2011                 [Page 1]

Internet-Draft            Media Policy Dataset             February 2011


   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.


Table of Contents

   1.  Open Revision Items  . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Media Types  . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Require Registration . . . . . . . . . . . . . . . . .  4
       1.1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . .  4
       1.1.3.  Rename the <mime-type> child of <codec>  . . . . . . .  4
     1.2.  Remove reference to uaprofile.rng  . . . . . . . . . . . .  4
     1.3.  Remove <property-set>  . . . . . . . . . . . . . . . . . .  5
     1.4.  Specifying Sets  . . . . . . . . . . . . . . . . . . . . .  5
     1.5.  Specifying Bandwidth Limitations . . . . . . . . . . . . .  5
     1.6.  Rejecting a media stream . . . . . . . . . . . . . . . . .  5
     1.7.  The implied boolean logic of policy operations . . . . . .  6
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Media Policy Dataset Format  . . . . . . . . . . . . . . . . .  9
     4.1.  Namespace and Media Type . . . . . . . . . . . . . . . . .  9
     4.2.  Extensibility  . . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Attributes . . . . . . . . . . . . . . . . . . . . . . . .  9
       4.3.1.  The 'visibility' Attribute . . . . . . . . . . . . . . 10
       4.3.2.  The 'direction' Attributes . . . . . . . . . . . . . . 10
       4.3.3.  The 'q' Attribute  . . . . . . . . . . . . . . . . . . 10
       4.3.4.  The 'label' Attribute  . . . . . . . . . . . . . . . . 11
   5.  Session Info Documents . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Mapping SDP to Session Info Documents  . . . . . . . . . . 12
     5.2.  The <session-info> Element . . . . . . . . . . . . . . . . 12
     5.3.  The <streams> Element  . . . . . . . . . . . . . . . . . . 12
       5.3.1.  The <stream> Element . . . . . . . . . . . . . . . . . 13
     5.4.  The <media-intermediaries> Element . . . . . . . . . . . . 14
       5.4.1.  The <fixed-intermediary> Element . . . . . . . . . . . 14
       5.4.2.  The <turn-intermediary> Element  . . . . . . . . . . . 15
       5.4.3.  The <msrp-intermediary> Element  . . . . . . . . . . . 16
   6.  Session Policy Documents . . . . . . . . . . . . . . . . . . . 16
     6.1.  Merging Session Policies . . . . . . . . . . . . . . . . . 17
       6.1.1.  Single Value Selection . . . . . . . . . . . . . . . . 17
       6.1.2.  Merging Sets . . . . . . . . . . . . . . . . . . . . . 17
       6.1.3.  Local Policy Server Selection  . . . . . . . . . . . . 18
     6.2.  The <session-policy> Element . . . . . . . . . . . . . . . 18
     6.3.  The <media-types-allowed> Element  . . . . . . . . . . . . 19
     6.4.  The <media-types-excluded> Element . . . . . . . . . . . . 19



Hilt, et al.             Expires August 6, 2011                 [Page 2]

Internet-Draft            Media Policy Dataset             February 2011


     6.5.  The <codecs-allowed> Element . . . . . . . . . . . . . . . 20
     6.6.  The <codecs-excluded> Element  . . . . . . . . . . . . . . 20
     6.7.  The <local-ports> Element  . . . . . . . . . . . . . . . . 21
   7.  Common Media Policy Dataset Elements . . . . . . . . . . . . . 21
     7.1.  The <media-type> Element . . . . . . . . . . . . . . . . . 21
     7.2.  The <codec> Element  . . . . . . . . . . . . . . . . . . . 21
       7.2.1.  The <mime-type> Element  . . . . . . . . . . . . . . . 22
       7.2.2.  The <mime-parameter> Element . . . . . . . . . . . . . 22
     7.3.  The <max-bw> Element . . . . . . . . . . . . . . . . . . . 22
     7.4.  The <max-session-bw> Element . . . . . . . . . . . . . . . 23
     7.5.  The <max-stream-bw> Element  . . . . . . . . . . . . . . . 23
     7.6.  The <qos-dscp> Element . . . . . . . . . . . . . . . . . . 24
     7.7.  The <context> Element  . . . . . . . . . . . . . . . . . . 25
       7.7.1.  The <policy-server-URI> Element  . . . . . . . . . . . 25
       7.7.2.  The <contact> Element  . . . . . . . . . . . . . . . . 25
       7.7.3.  The <info> Element . . . . . . . . . . . . . . . . . . 26
       7.7.4.  The <request-URI> Element  . . . . . . . . . . . . . . 26
       7.7.5.  The <token> Element  . . . . . . . . . . . . . . . . . 26
     7.8.  Other Session Properties . . . . . . . . . . . . . . . . . 26
   8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     8.1.  Session Policy Documents . . . . . . . . . . . . . . . . . 27
     8.2.  Session Information Documents  . . . . . . . . . . . . . . 27
       8.2.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . . 27
       8.2.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . . 28
   9.  Relax NG Definition  . . . . . . . . . . . . . . . . . . . . . 30
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 37
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
     11.1. Media Type Registration  . . . . . . . . . . . . . . . . . 37
     11.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 38
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 38
     12.2. Informative References . . . . . . . . . . . . . . . . . . 40
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 40
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40

















Hilt, et al.             Expires August 6, 2011                 [Page 3]

Internet-Draft            Media Policy Dataset             February 2011


1.  Open Revision Items

   This version of this Internet-Draft is largely the same as the
   previous version.  It has been submitted primarily to maintain the
   draft as active.  A number of significant open issues are described
   in this section.

1.1.  Media Types

1.1.1.  Require Registration

   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.

1.1.2.  Terminology

   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.

1.1.3.  Rename the <mime-type> child of <codec>

   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?

1.2.  Remove reference to uaprofile.rng

   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.





Hilt, et al.             Expires August 6, 2011                 [Page 4]

Internet-Draft            Media Policy Dataset             February 2011


1.3.  Remove <property-set>

   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.

1.4.  Specifying Sets

   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.

1.5.  Specifying Bandwidth Limitations

   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?

1.6.  Rejecting a media stream

   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



Hilt, et al.             Expires August 6, 2011                 [Page 5]

Internet-Draft            Media Policy Dataset             February 2011


   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.

1.7.  The implied boolean logic of policy operations

   I am starting work on a messy part of the media policy dataset
   definition: Specifying the logic when a policy is applied to a
   session-info, and also specifying how two policies are combined to
   apply jointly to session-infos.  The goal is to implement one's
   intuitive expectations while introducing as few special cases as
   possible.

   My current analysis is:
   o  The primary operation is applying a session-policy to a session-
      info to produce a possibly more restricted session-info.  This is
      done by applying the session-policy to each stream in turn, which
      may "restrict" the stream (in regard to bandwidth, codecs, etc.).
   o  A stream may be restricted to the point that it permits no media
      whatsoever.  Such "null" streams are all logically equivalent,
      although a null stream can be represented in many different ways.
      When translated back into SDP, a null stream becomes a rejected m=
      line.
   o  The different <stream> elements in a session-policy are
      effectively ORed together, in that the policy intends to permit
      any stream that conforms to *any one* of the <stream> elements.
      This is necessary because e.g. a session-policy can contain one
      <stream> that specifies audio media and restricts the codecs
      permitted for audio, and another <stream> that specifies video
      media and restricts the codecs permitted for video.





Hilt, et al.             Expires August 6, 2011                 [Page 6]

Internet-Draft            Media Policy Dataset             February 2011


   o  Thus, applying a session-policy to a stream involves applying each
      session-policy <stream> to the stream, and then choosing the
      "best" result.  In practice, we expect that the streams admitted
      by the session-policy <stream> elements to be disjoint (e.g., one
      is for audio, one is for video), so the result of applying any but
      one <stream> will be a null stream, and the "best" result will be
      the only non-null result.
   o  The alternative strategy of "unioning" the results of applying
      each <stream> element cannot be used because it can allow the
      resulting session to exceed all of the <stream> element policies.
      Consider the policy

         <streams>
           <stream> codecs: audio/foo, bandwidth: 10 </stream>
           <stream> codecs: audio/foo,audio/bar, bandwidth: 1 </stream>
         </streams>

      applied to the requested stream "codecs: audio/foo,audio/bar,
      bandwidth: 10".  The result of restricting with the first <stream>
      is "codecs: audio/foo, bandwidth: 10" and the result of
      restricting with the second <stream> is "codecs: audio/foo,audio/
      bar, bandwidth: 1".  The union of the two (the "smallest" stream
      that contains them both) is "codecs: audio/foo,audio/bar,
      bandwidth: 10", which is not allowed by either <stream>.
   o  Within this context, combining two policies to form a joint policy
      that enforces both their restrictions simultaneously is simple:
      The resulting policy is made by "intersecting" all possible pairs
      of <stream>s, one from the first policy and one from the second
      policy.  (Intersections that result in null policies can be
      dropped from the result.)
   o  I haven't studied the role of the directional attributes yet, but
      currently I believe that a bidirectional session-info <stream> can
      be treated as an abbreviation for two session-info <stream>s, one
      in each direction, and a bidirectional session-policy <stream> can
      be treated similarly.  Or, directionality can be treated as an
      attribute with two possible values, *with identical results*.


2.  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



Hilt, et al.             Expires August 6, 2011                 [Page 7]

Internet-Draft            Media Policy Dataset             February 2011


   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.



Hilt, et al.             Expires August 6, 2011                 [Page 8]

Internet-Draft            Media Policy Dataset             February 2011


3.  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].


4.  Media Policy Dataset Format

   This section discusses fundamental properties of the Media Policy
   Dataset Format (MPDF).

4.1.  Namespace and Media 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 media type for the Media Policy Dataset Format is:

      application/media-policy-dataset+xml

4.2.  Extensibility

   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.

4.3.  Attributes

   The following attributes can be used with elements of the MPDF
   format.  For each MPDF element it is defined, which of these
   attributes can be used.  Attributes that are not defined for an
   element MUST be ignored.






Hilt, et al.             Expires August 6, 2011                 [Page 9]

Internet-Draft            Media Policy Dataset             February 2011


4.3.1.  The 'visibility' 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:

   o  visible: specifies that display of the property value is not
      restricted.  This is the default value of the attribute if it is
      not specified.
   o  hidden: Specifies that the user agent SHOULD NOT display the
      property value.  Display of the property value may be allowed
      using special administrative interfaces, but is not appropriate to
      the ordinary user.

4.3.2.  The 'direction' Attributes

   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:

   o  recvonly: the property only applies to incoming messages/streams.
   o  sendonly: the property only applies to outgoing messages/streams.
   o  sendrecv: the property applies to messages/streams in both
      directions.  This is the default value that is used if the
      'direction' attribute is omitted.

4.3.3.  The 'q' Attribute

   It should be possible to express a preference for a certain value, if
   multiple values are allowed within a property.  For example, it
   should be possible to express that the codecs G.711 and G.729 are
   allowed, but G.711 is preferred.  Preferences can be expressed by
   adding a 'q' attribute to a property element.  Elements derived from
   the "setting" element for which multiple occurrences and values are
   allowed SHOULD have a "q" attribute if the order is significant.
   Typically these elements are contained in an element derived from the
   "setting_container" element.  The 'q' attribute is only meaningful if
   the 'policy' attribute set to 'allowed'.  It must be ignored in all
   other cases.

   An element with a higher 'q' value is preferred over one with a lower
   'q' value. 'q' attribute values range from 0 to 1.  The default value
   is 0.5.



Hilt, et al.             Expires August 6, 2011                [Page 10]

Internet-Draft            Media Policy Dataset             February 2011


4.3.4.  The 'label' Attribute

   Some properties only apply to a specific media stream.  The stream to
   which a property applies MUST be identifiable through a label
   [RFC4574].  Per-stream properties can be expressed by adding a
   'label' attribute to the respective element.  Such a property only
   applies to the identified stream.  If there is no stream with this
   label, the element must be ignored.

   Per-stream properties require that the labels of media streams are
   known to the creator of a document (i.e., the profile delivery/policy
   server).  These labels are part of the session description.


5.  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 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:



Hilt, et al.             Expires August 6, 2011                [Page 11]

Internet-Draft            Media Policy Dataset             February 2011


      <session-info><\session-info>

5.1.  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 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 mapping from a session info document to a SDP description follows
   the same rules in the reverse direction.

5.2.  The <session-info> Element

   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.

5.3.  The <streams> Element

   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.



Hilt, et al.             Expires August 6, 2011                [Page 12]

Internet-Draft            Media Policy Dataset             February 2011


5.3.1.  The <stream> Element

   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.
   The token can be chosen freely, however, it MUST be unique among all
   <stream> element 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.

5.3.1.1.  The <local-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.

5.3.1.2.  The <remote-host-port> 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.




Hilt, et al.             Expires August 6, 2011                [Page 13]

Internet-Draft            Media Policy Dataset             February 2011


5.4.  The <media-intermediaries> Element

   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>.

      Note: it is not intended that the <media-intermediaries> 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 <media-
      intermediaries> element and the ones discovered through ICE may
      overlap but don't have to.

5.4.1.  The <fixed-intermediary> 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



Hilt, et al.             Expires August 6, 2011                [Page 14]

Internet-Draft            Media Policy Dataset             February 2011


   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.

5.4.1.1.  The <int-host-port> Element

   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.

5.4.1.2.  The <int-addl-port> Element

   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.

5.4.2.  The <turn-intermediary> Element

   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.






Hilt, et al.             Expires August 6, 2011                [Page 15]

Internet-Draft            Media Policy Dataset             February 2011


5.4.2.1.  The <shared-secret> Element

   The <shared-secret> element contains the shared secret needed to
   authenticate at the media intermediary.

5.4.2.2.  The <user> element

   The <user> element contains the user ID needed to authenticate to the
   media intermediary.

5.4.2.3.  The <transport> Element

   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.

5.4.3.  The <msrp-intermediary> Element

   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.

5.4.3.1.  The <msrp-uri> Element

   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.


6.  Session Policy Documents

   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



Hilt, et al.             Expires August 6, 2011                [Page 16]

Internet-Draft            Media Policy Dataset             February 2011


   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.

6.1.  Merging Session Policies

   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.

6.1.1.  Single Value Selection

   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).

6.1.2.  Merging Sets

   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



Hilt, et al.             Expires August 6, 2011                [Page 17]

Internet-Draft            Media Policy Dataset             February 2011


   policy, the set of codecs allowed is: G729.


   Session Policy Document 1:
   <codecs-excluded>
     <codec><mime-type>audio/PCMA</mime-type></codec>
   </codecs>

   Session Policy Document 2:
   <codecs-allowed>
     <codec><mime-type>audio/PCMA</mime-type></codec>
     <codec><mime-type>audio/G729</mime-type></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.

6.1.3.  Local Policy Server Selection

   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.

6.2.  The <session-policy> Element

   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)



Hilt, et al.             Expires August 6, 2011                [Page 18]

Internet-Draft            Media Policy Dataset             February 2011


   <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.

6.3.  The <media-types-allowed> Element

   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
   one or more <media-type> elements.

   A <media-types-allowed> element MUST NOT be used in a container that
   contains a <media-types-excluded> element.

      Merging of session-policy documents: <media-types-allowed>
      containers are merged as described in "Merging Sets"
      Section 6.1.2.

6.4.  The <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
   one or more <media-type> elements.

   A <media-types-excluded> element MUST NOT be used in a container that



Hilt, et al.             Expires August 6, 2011                [Page 19]

Internet-Draft            Media Policy Dataset             February 2011


   contains a <media-types-allowed> element.

      Merging of session-policy documents: <media-types-excluded>
      containers are merged as described in "Merging Sets"
      Section 6.1.2.

6.5.  The <codecs-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 one or more <codec>
   elements.

   A <codecs-allowed> element MUST NOT be used in a container that
   contains a <codecs-excluded> element.

      Merging of session-policy documents: <codecs-allowed> containers
      are merged as described in "Merging Sets" Section 6.1.2.

6.6.  The <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 one or
   more <codec> elements.

   A <codecs-excluded> element MUST NOT be used in a container that



Hilt, et al.             Expires August 6, 2011                [Page 20]

Internet-Draft            Media Policy Dataset             February 2011


   contains a <codecs-allowed> element.

      Merging of session-policy documents: <codecs-excluded> containers
      are merged as described in "Merging Sets" Section 6.1.2.

6.7.  The <local-ports> 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 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 4.3):
   visibility.

      Merging of session-policy documents: the local domain of the user
      agent has precedence over other domains and its local ports value
      is used.  During the merging process, <local-ports> element values
      from local policy server selected as described in "Local Policy
      Server Selection" Section 6.1.3 are used.


7.  Common Media Policy Dataset Elements

   This section describes common XML elements that are used in session
   info and session policy documents to encode the media properties of
   SIP sessions.

7.1.  The <media-type> Element

   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.

7.2.  The <codec> Element

   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.




Hilt, et al.             Expires August 6, 2011                [Page 21]

Internet-Draft            Media Policy Dataset             February 2011


   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 <mime-type> element and MAY
   contain multiple optional <mime-parameter> elements.

7.2.1.  The <mime-type> Element

   The <mime-type> 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]).

7.2.2.  The <mime-parameter> Element

   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].

7.3.  The <max-bw> Element

   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,



Hilt, et al.             Expires August 6, 2011                [Page 22]

Internet-Draft            Media Policy Dataset             February 2011


   each instance MUST apply to a different set of media streams (i.e.,
   one <max-bw> element for outgoing and one for incoming streams).

      Merging of session-policy documents: the lowest max-bw value is
      used.

7.4.  The <max-session-bw> Element

   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 value of the <max-session-bw> element is equivalent to the CT
   bandwidth in the b= line of an SDP [RFC4566] announcement.

   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).

      Merging of session-policy documents: the lowest max-session-bw
      value is used.

7.5.  The <max-stream-bw> Element

   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 for lower-layer transport and network protocols
   (e.g., UDP and IP).

   The value of the <max-stream-bw> element is equivalent to the AS
   bandwidth in the b= line of an SDP [RFC4566] announcement.



Hilt, et al.             Expires August 6, 2011                [Page 23]

Internet-Draft            Media Policy Dataset             February 2011


   The <max-stream-bw> element MAY have the following attribute (see
   Section 4.3): direction, media-type.

   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).

      Merging of session-policy documents: the lowest max-stream-bw
      value is used.

7.6.  The <qos-dscp> Element

   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 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 4.3):
   direction, media-type.

   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 define that <qos-dscp> element



Hilt, et al.             Expires August 6, 2011                [Page 24]

Internet-Draft            Media Policy Dataset             February 2011


   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).

      Merging of session-policy documents: the local domain of the user
      agent has precedence over other domains and its DSCP value is
      used.  During the merging process, <qos-dscp> element values from
      local policy server selected as described in "Local Policy Server
      Selection" Section 6.1.3 are used.

7.7.  The <context> Element

   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.

      Merging of session-policy documents: the <context> element is not
      subject to merging.

7.7.1.  The <policy-server-URI> 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 defined inside a <session-
   policy> element.

7.7.2.  The <contact> Element

   The <contact> element contains a contact address (e.g., a SIP URI or
   email address) under which the issuer of this document can be
   reached.





Hilt, et al.             Expires August 6, 2011                [Page 25]

Internet-Draft            Media Policy Dataset             February 2011


7.7.3.  The <info> Element

   The <info> element provides a short textual description of the policy
   or session that should be intelligible to the human user.

7.7.4.  The <request-URI> Element

   The <request-URI> element identifies the request-URI the dialog
   initiating request of a session is sent to.

   The <request-URI> element is only defined inside a <session-info>
   element.

7.7.5.  The <token> Element

   The <token> 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 <token> element is only defined inside a <session-info> element.

7.8.  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
   o  body format
   o  body encryption


8.  Examples






Hilt, et al.             Expires August 6, 2011                [Page 26]

Internet-Draft            Media Policy Dataset             February 2011


8.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.


   <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><mime-type>audio/G729</mime-type></codec>
       <codec><mime-type>audio/G723</mime-type></codec>
     </codecs>
   </session-policy>

8.2.  Session Information Documents

   The following examples contain session descriptions and the session
   information documents that represent these sessions.

8.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:

   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



Hilt, et al.             Expires August 6, 2011                [Page 27]

Internet-Draft            Media Policy Dataset             February 2011


   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><mime-type>audio/PCMU</mime-type></codec>
         <codec><mime-type>audio/1016</mime-type></codec>
         <codec><mime-type>audio/GSM</mime-type></codec>
         <local-host-port>host.somewhere.example:49562</local-host-port>
       </stream>
       <stream>
         <media-type>video</media-type>
         <codec><mime-type>video/H261</mime-type></codec>
         <codec><mime-type>video/H263</mime-type></codec>
         <local-host-port>host.somewhere.example:51234</local-host-port>
       </stream>
     </streams>
   </session-info>

8.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:

   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



Hilt, et al.             Expires August 6, 2011                [Page 28]

Internet-Draft            Media Policy Dataset             February 2011


   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><mime-type>audio/PCMU</mime-type></codec>
        <codec><mime-type>audio/GSM</mime-type></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><mime-type>video/H261</mime-type></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.









Hilt, et al.             Expires August 6, 2011                [Page 29]

Internet-Draft            Media Policy Dataset             February 2011


  <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><mime-type>audio/PCMU</mime-type></codec>
        <codec><mime-type>audio/GSM</mime-type></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><mime-type>video/H261</mime-type></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>


9.  Relax NG Definition

   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>



Hilt, et al.             Expires August 6, 2011                [Page 30]

Internet-Draft            Media Policy Dataset             February 2011


                    <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>



Hilt, et al.             Expires August 6, 2011                [Page 31]

Internet-Draft            Media Policy Dataset             February 2011


                   <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="mime-type">
                  <data type="string" />



Hilt, et al.             Expires August 6, 2011                [Page 32]

Internet-Draft            Media Policy Dataset             February 2011


                </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">



Hilt, et al.             Expires August 6, 2011                [Page 33]

Internet-Draft            Media Policy Dataset             February 2011


                <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" />



Hilt, et al.             Expires August 6, 2011                [Page 34]

Internet-Draft            Media Policy Dataset             February 2011


                        </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" />



Hilt, et al.             Expires August 6, 2011                [Page 35]

Internet-Draft            Media Policy Dataset             February 2011


                  </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>





Hilt, et al.             Expires August 6, 2011                [Page 36]

Internet-Draft            Media Policy Dataset             February 2011


10.  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.


11.  IANA Considerations

   This document registers a new media type, application/
   media-policy-dataset+xml, and a new XML namespace.

11.1.  Media Type Registration

   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,



Hilt, et al.             Expires August 6, 2011                [Page 37]

Internet-Draft            Media Policy Dataset             February 2011


   <volkerh@bell-labs.com>

   Intended usage: COMMON

   Author/Change controller: The IETF.

11.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, <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


12.  References

12.1.  Normative References

   [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.




Hilt, et al.             Expires August 6, 2011                [Page 38]

Internet-Draft            Media Policy Dataset             February 2011


   [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.

   [RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.

   [RFC4976]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
              for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
              September 2007.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

   [W3C.REC-xml-20040204]
              Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J.,
              and T. Bray, "Extensible Markup Language (XML) 1.0 (Third
              Edition)", World Wide Web Consortium FirstEdition REC-xml-
              20040204, February 2004,
              <http://www.w3.org/TR/2004/REC-xml-20040204>.

   [W3C.REC-xml-names-19990114]
              Hollander, D., Layman, A., and T. Bray, "Namespaces in
              XML", World Wide Web Consortium FirstEdition REC-xml-
              names-19990114, January 1999,
              <http://www.w3.org/TR/1999/REC-xml-names-19990114>.




Hilt, et al.             Expires August 6, 2011                [Page 39]

Internet-Draft            Media Policy Dataset             February 2011


12.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-08 (work in
              progress), December 2010.

   [I-D.ietf-sipping-config-framework]
              Channabasappa, S., "A Framework for Session Initiation
              Protocol User Agent Profile Delivery",
              draft-ietf-sipping-config-framework-18 (work in progress),
              October 2010.

   [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, 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.














Hilt, et al.             Expires August 6, 2011                [Page 40]

Internet-Draft            Media Policy Dataset             February 2011


Authors' Addresses

   Volker Hilt
   Bell Labs/Alcatel-Lucent
   791 Holmdel-Keyport Rd
   Holmdel, NJ  07733
   USA

   Email: volkerh@bell-labs.com


   Dale R. Worley
   Avaya Inc.
   600 Technology Park Dr.
   Billerica, MA  01821
   US

   Email: dworley@avaya.com


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   Jonathan Rosenberg
   jdrosen.net
   Monmouth, NJ
   USA

   Email: jdrosen@jdrosen.net
















Hilt, et al.             Expires August 6, 2011                [Page 41]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/