idnits 2.17.1 draft-ietf-sipping-media-policy-dataset-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2, 2011) is 4825 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-10) exists of draft-ietf-sip-session-policy-framework-08 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Alcatel-Lucent 4 Intended status: Standards Track D. Worley 5 Expires: August 6, 2011 Avaya Inc. 6 G. Camarillo 7 Ericsson 8 J. Rosenberg 9 jdrosen.net 10 February 2, 2011 12 A User Agent Profile Data Set for Media Policy 13 draft-ietf-sipping-media-policy-dataset-11 15 Abstract 17 This specification defines a document format for the media properties 18 of Session Initiation Protocol (SIP) sessions. Examples for media 19 properties are the codecs or media types used in a session. This 20 document format is based on XML and can be used to describe the 21 properties of a specific SIP session or to define policies that are 22 then applied to SIP sessions. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 6, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Open Revision Items . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1.1. Require Registration . . . . . . . . . . . . . . . . . 4 61 1.1.2. Terminology . . . . . . . . . . . . . . . . . . . . . 4 62 1.1.3. Rename the child of . . . . . . . 4 63 1.2. Remove reference to uaprofile.rng . . . . . . . . . . . . 4 64 1.3. Remove . . . . . . . . . . . . . . . . . . 5 65 1.4. Specifying Sets . . . . . . . . . . . . . . . . . . . . . 5 66 1.5. Specifying Bandwidth Limitations . . . . . . . . . . . . . 5 67 1.6. Rejecting a media stream . . . . . . . . . . . . . . . . . 5 68 1.7. The implied boolean logic of policy operations . . . . . . 6 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4. Media Policy Dataset Format . . . . . . . . . . . . . . . . . 9 72 4.1. Namespace and Media Type . . . . . . . . . . . . . . . . . 9 73 4.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 74 4.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.3.1. The 'visibility' Attribute . . . . . . . . . . . . . . 10 76 4.3.2. The 'direction' Attributes . . . . . . . . . . . . . . 10 77 4.3.3. The 'q' Attribute . . . . . . . . . . . . . . . . . . 10 78 4.3.4. The 'label' Attribute . . . . . . . . . . . . . . . . 11 79 5. Session Info Documents . . . . . . . . . . . . . . . . . . . . 11 80 5.1. Mapping SDP to Session Info Documents . . . . . . . . . . 12 81 5.2. The Element . . . . . . . . . . . . . . . . 12 82 5.3. The Element . . . . . . . . . . . . . . . . . . 12 83 5.3.1. The Element . . . . . . . . . . . . . . . . . 13 84 5.4. The Element . . . . . . . . . . . . 14 85 5.4.1. The Element . . . . . . . . . . . 14 86 5.4.2. The Element . . . . . . . . . . . 15 87 5.4.3. The Element . . . . . . . . . . . 16 88 6. Session Policy Documents . . . . . . . . . . . . . . . . . . . 16 89 6.1. Merging Session Policies . . . . . . . . . . . . . . . . . 17 90 6.1.1. Single Value Selection . . . . . . . . . . . . . . . . 17 91 6.1.2. Merging Sets . . . . . . . . . . . . . . . . . . . . . 17 92 6.1.3. Local Policy Server Selection . . . . . . . . . . . . 18 93 6.2. The Element . . . . . . . . . . . . . . . 18 94 6.3. The Element . . . . . . . . . . . . 19 95 6.4. The Element . . . . . . . . . . . . 19 96 6.5. The Element . . . . . . . . . . . . . . . 20 97 6.6. The Element . . . . . . . . . . . . . . 20 98 6.7. The Element . . . . . . . . . . . . . . . . 21 99 7. Common Media Policy Dataset Elements . . . . . . . . . . . . . 21 100 7.1. The Element . . . . . . . . . . . . . . . . . 21 101 7.2. The Element . . . . . . . . . . . . . . . . . . . 21 102 7.2.1. The Element . . . . . . . . . . . . . . . 22 103 7.2.2. The Element . . . . . . . . . . . . . 22 104 7.3. The Element . . . . . . . . . . . . . . . . . . . 22 105 7.4. The Element . . . . . . . . . . . . . . . 23 106 7.5. The Element . . . . . . . . . . . . . . . 23 107 7.6. The Element . . . . . . . . . . . . . . . . . . 24 108 7.7. The Element . . . . . . . . . . . . . . . . . . 25 109 7.7.1. The Element . . . . . . . . . . . 25 110 7.7.2. The Element . . . . . . . . . . . . . . . . 25 111 7.7.3. The Element . . . . . . . . . . . . . . . . . . 26 112 7.7.4. The Element . . . . . . . . . . . . . . 26 113 7.7.5. The Element . . . . . . . . . . . . . . . . . 26 114 7.8. Other Session Properties . . . . . . . . . . . . . . . . . 26 115 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 116 8.1. Session Policy Documents . . . . . . . . . . . . . . . . . 27 117 8.2. Session Information Documents . . . . . . . . . . . . . . 27 118 8.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 27 119 8.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 28 120 9. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 30 121 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 122 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 123 11.1. Media Type Registration . . . . . . . . . . . . . . . . . 37 124 11.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 38 125 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 126 12.1. Normative References . . . . . . . . . . . . . . . . . . . 38 127 12.2. Informative References . . . . . . . . . . . . . . . . . . 40 128 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 131 1. Open Revision Items 133 This version of this Internet-Draft is largely the same as the 134 previous version. It has been submitted primarily to maintain the 135 draft as active. A number of significant open issues are described 136 in this section. 138 1.1. Media Types 140 1.1.1. Require Registration 142 In -10, all media type names that are mentioned in a MPDF are 143 explicitly required to be IANA-registered. Technically, this means 144 that experimental or private-use types can not be used, even in 145 situations where all participants are aware of non-registered media 146 types. In practice, people will go ahead and use them anyway. I am 147 proposing to remove the "registered" requirement. 149 1.1.2. Terminology 151 In a number of places, media types are called "MIME types". The 152 latter is common usage, but it is not official, and as RFC 4288 makes 153 clear, media types are independent of their use within MIME. I've 154 fixed the wording of the draft in a number of places to correct this. 156 1.1.3. Rename the child of 158 There is an element that is a child of the 159 element that carries a media type and subtype. The natural fix would 160 be to change this to , but there is already an element of 161 that name that is a child of that carries a media type 162 (without subtype). I would like a name that means "media type and 163 subtype", but I can't think of a short one. Suggestions? 165 1.2. Remove reference to uaprofile.rng 167 The Relax NG schema given in draft-ietf-sipping-media-policy-dataset 168 includes "uaprofile.rng". As far as I can figure out, uaprofile.rng 169 is the schema defined in draft-ietf-sipping-profile-datasets, which 170 has been abandoned. So we need to remove the reference to 171 uaprofile.rng. It's possible that there are things defined in that 172 schema that need to be either deleted from 173 draft-ietf-sipping-media-policy-dataset, or copied from the abandoned 174 draft into the schema in draft-ietf-sipping-media-policy-dataset. 176 If anyone has further information about this, please tell me. 178 1.3. Remove 180 I have updated the text of draft-ietf-sipping-media-policy-dataset-11 181 to consistently use "property-set" rather than sometimes using 182 "property_set". However, it seems to me that the 183 element serves no use (now that sipping-profile-datasets has been 184 abandoned). The draft says that each and appears in a , and can contain 186 more than one of each. But there seems to be no practical use for 187 this grouping; the semantics of and 188 is completely standalone. 190 So I am proposing eliminating the element entirely, 191 making and into top-level elements. 193 1.4. Specifying Sets 195 There are many properties for which the values are sets of primitive 196 values. The current syntax for specifying sets is awkward. In 197 addition, it is not permitted to specify a set containing zero 198 elements. Sessions containing empty sets are not useful to write, 199 but it is easy to generate them when applying a policy to a . So the syntax for set values needs to be updated. 202 1.5. Specifying Bandwidth Limitations 204 Looking at the XML of draft-ietf-sipping-media-policy-dataset, I see 205 this paragraph: 207 212 SDP provides "b=" lines for specifying bandwidth limitations. 213 Similarly, MPD provides , , and 214 elements, and the draft states that they are 215 equivalent to various forms of the b= line. Should we require that 216 when SDP is translated into MPD that the bandwidth limitations be 217 translated? 219 1.6. Rejecting a media stream 221 In draft-ietf-sipping-media-policy-dataset-10 there is no explicit 222 way to indicate that a stream has been rejected (which is needed to 223 correspond to an m= line in SDP where the port number is 0). 224 Implicitly, this can be done by setting the port number in the 225 or to 0. But that is pretty 226 ugly. I propose that we introduce an attribute of the 227 element to indicate that a stream has been rejected/disabled: 229 231 The default value of "enabled" would be "yes". 233 This resolves the problem of how a policy server would modify a 234 to make it conform to a policy if one of the s 235 contradicted the policy: The policy server would put enabled="no" 236 onto the . 238 For consistency, a policy server could effectively reject a proposed 239 session by rejecting all of the streams within it. This would be 240 slightly different than rejecting the session as a whole by returning 241 an empty session-info document, . This distinction 242 corresponds to the difference between an SDP offer/answer negotiation 243 failing, and the negotiation succeeding but the answer rejecting all 244 the m= lines in the SDP. 246 1.7. The implied boolean logic of policy operations 248 I am starting work on a messy part of the media policy dataset 249 definition: Specifying the logic when a policy is applied to a 250 session-info, and also specifying how two policies are combined to 251 apply jointly to session-infos. The goal is to implement one's 252 intuitive expectations while introducing as few special cases as 253 possible. 255 My current analysis is: 256 o The primary operation is applying a session-policy to a session- 257 info to produce a possibly more restricted session-info. This is 258 done by applying the session-policy to each stream in turn, which 259 may "restrict" the stream (in regard to bandwidth, codecs, etc.). 260 o A stream may be restricted to the point that it permits no media 261 whatsoever. Such "null" streams are all logically equivalent, 262 although a null stream can be represented in many different ways. 263 When translated back into SDP, a null stream becomes a rejected m= 264 line. 265 o The different elements in a session-policy are 266 effectively ORed together, in that the policy intends to permit 267 any stream that conforms to *any one* of the elements. 268 This is necessary because e.g. a session-policy can contain one 269 that specifies audio media and restricts the codecs 270 permitted for audio, and another that specifies video 271 media and restricts the codecs permitted for video. 273 o Thus, applying a session-policy to a stream involves applying each 274 session-policy to the stream, and then choosing the 275 "best" result. In practice, we expect that the streams admitted 276 by the session-policy elements to be disjoint (e.g., one 277 is for audio, one is for video), so the result of applying any but 278 one will be a null stream, and the "best" result will be 279 the only non-null result. 280 o The alternative strategy of "unioning" the results of applying 281 each element cannot be used because it can allow the 282 resulting session to exceed all of the element policies. 283 Consider the policy 285 286 codecs: audio/foo, bandwidth: 10 287 codecs: audio/foo,audio/bar, bandwidth: 1 288 290 applied to the requested stream "codecs: audio/foo,audio/bar, 291 bandwidth: 10". The result of restricting with the first 292 is "codecs: audio/foo, bandwidth: 10" and the result of 293 restricting with the second is "codecs: audio/foo,audio/ 294 bar, bandwidth: 1". The union of the two (the "smallest" stream 295 that contains them both) is "codecs: audio/foo,audio/bar, 296 bandwidth: 10", which is not allowed by either . 297 o Within this context, combining two policies to form a joint policy 298 that enforces both their restrictions simultaneously is simple: 299 The resulting policy is made by "intersecting" all possible pairs 300 of s, one from the first policy and one from the second 301 policy. (Intersections that result in null policies can be 302 dropped from the result.) 303 o I haven't studied the role of the directional attributes yet, but 304 currently I believe that a bidirectional session-info can 305 be treated as an abbreviation for two session-info s, one 306 in each direction, and a bidirectional session-policy can 307 be treated similarly. Or, directionality can be treated as an 308 attribute with two possible values, *with identical results*. 310 2. Introduction 312 The Framework for Session Initiation Protocol (SIP) [RFC3261] User 313 Agent Profile Delivery [I-D.ietf-sipping-config-framework] and the 314 Framework for SIP Session Policies 315 [I-D.ietf-sip-session-policy-framework] define mechanisms to convey 316 session policies and configuration information from a network server 317 to a user agent. An important piece of the information conveyed to 318 the user agent relates to the media properties of the SIP sessions 319 set up by the user agent. Examples for these media properties are 320 the codecs and media types used, the media-intermediaries to be 321 traversed or the maximum bandwidth available for media streams. 323 This specification defines a document format for media properties of 324 SIP sessions, the Media Policy Dataset Format (MPDF). This format 325 can be used in two ways: first, it can be used to describe the 326 properties of a given SIP session (e.g., the media types and codecs 327 used). These MPDF documents are called session info documents and 328 they are usually created based on the session description of a 329 session. Second, the MPDF format can be used to define policies for 330 SIP sessions in a session policy document. A session policy document 331 defines properties for a session (e.g., the media types allowed in a 332 session), independent of a specific session description. 334 If used with the Framework for SIP Session Policies 335 [I-D.ietf-sip-session-policy-framework], session info documents are 336 used in conjunction with session-specific policies. A session info 337 document is created by a UA based on the current session description 338 and submitted to the policy server. The policy server examines the 339 session info document, modifies it if necessary (e.g., by removing 340 video streams if video is not permitted) and returns the possibly 341 modified session info document to the UA. Session policy documents 342 on the other hand are used to describe session-independent policies 343 that can be submitted to the UA independent of a specific session. 345 The two types of MPDF documents, session information and session 346 policy documents, share the same set of XML elements to describe 347 session properties. Since these elements are used in different 348 contexts for session info and session policy documents, two different 349 root elements exist for the two document types: is the 350 root element for session information documents and 351 is the root element for session policy documents. 353 A user agent can receive multiple session policy documents from 354 different sources. This can lead to a situation in which the user 355 agent needs to apply multiple session policy documents to the same 356 session. This standard specifies merging rules for those XML 357 elements that can be present in session policy documents. It should 358 be noted that these merging rules are part of the semantics of a 359 session policy XML element. User agents implement the merging rules 360 as part of implementing the element semantics. As a consequence, it 361 is not possible to build an entity that can mechanically merge two 362 session policy documents without understanding the semantics of all 363 elements in the input documents. 365 Merging rules are not needed for elements of session information 366 documents since they are created by one source and describe a 367 specific session. 369 3. Terminology 371 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 372 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 373 document are to be interpreted as described in RFC 2119 [RFC2119]. 375 4. Media Policy Dataset Format 377 This section discusses fundamental properties of the Media Policy 378 Dataset Format (MPDF). 380 4.1. Namespace and Media Type 382 The MPDF format is based on XML [W3C.REC-xml-20040204]. A MPDF 383 document MUST be well-formed and MUST be valid according to schemas, 384 including extension schemas, available to the validator and 385 applicable to the XML document. MPDF documents MUST be based on XML 386 1.0 and MUST be encoded using UTF-8. 388 MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The 389 namespace URIs for schemas defined in this specification are URNs 390 [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] 391 and extended by [RFC3688]. The namespace URN for the MPDF schema is: 393 urn:ietf:params:xml:ns:mediadataset 395 The media type for the Media Policy Dataset Format is: 397 application/media-policy-dataset+xml 399 4.2. Extensibility 401 The MPDF format can be extended using XML extension mechanisms if 402 additional media properties are needed. In particular, elements from 403 different XML namespaces MAY be present within a MPDF document for 404 the purposes of extensibility; elements or attributes from unknown 405 namespaces MUST be ignored. 407 4.3. Attributes 409 The following attributes can be used with elements of the MPDF 410 format. For each MPDF element it is defined, which of these 411 attributes can be used. Attributes that are not defined for an 412 element MUST be ignored. 414 4.3.1. The 'visibility' Attribute 416 The attribute "visibility" specifies whether or not the user agent is 417 permitted to display the property value to the user. This is used to 418 hide setting values that the administrator may not want the user to 419 see or know. The "visibility" attribute has two possible values: 421 o visible: specifies that display of the property value is not 422 restricted. This is the default value of the attribute if it is 423 not specified. 424 o hidden: Specifies that the user agent SHOULD NOT display the 425 property value. Display of the property value may be allowed 426 using special administrative interfaces, but is not appropriate to 427 the ordinary user. 429 4.3.2. The 'direction' Attributes 431 Some properties are unidirectional and only apply to messages or data 432 streams transmitted into one direction. For example, a property for 433 media streams can be restricted to outgoing media streams only. 434 Unidirectional properties can be expressed by adding a 'direction' 435 attribute to the respective element. 437 The 'direction' attribute can have the following values: 439 o recvonly: the property only applies to incoming messages/streams. 440 o sendonly: the property only applies to outgoing messages/streams. 441 o sendrecv: the property applies to messages/streams in both 442 directions. This is the default value that is used if the 443 'direction' attribute is omitted. 445 4.3.3. The 'q' Attribute 447 It should be possible to express a preference for a certain value, if 448 multiple values are allowed within a property. For example, it 449 should be possible to express that the codecs G.711 and G.729 are 450 allowed, but G.711 is preferred. Preferences can be expressed by 451 adding a 'q' attribute to a property element. Elements derived from 452 the "setting" element for which multiple occurrences and values are 453 allowed SHOULD have a "q" attribute if the order is significant. 454 Typically these elements are contained in an element derived from the 455 "setting_container" element. The 'q' attribute is only meaningful if 456 the 'policy' attribute set to 'allowed'. It must be ignored in all 457 other cases. 459 An element with a higher 'q' value is preferred over one with a lower 460 'q' value. 'q' attribute values range from 0 to 1. The default value 461 is 0.5. 463 4.3.4. The 'label' Attribute 465 Some properties only apply to a specific media stream. The stream to 466 which a property applies MUST be identifiable through a label 467 [RFC4574]. Per-stream properties can be expressed by adding a 468 'label' attribute to the respective element. Such a property only 469 applies to the identified stream. If there is no stream with this 470 label, the element must be ignored. 472 Per-stream properties require that the labels of media streams are 473 known to the creator of a document (i.e., the profile delivery/policy 474 server). These labels are part of the session description. 476 5. Session Info Documents 478 Session info documents describe key properties of a SIP session such 479 as the media streams used in the session. Session info documents are 480 typically created based on an SDP [RFC4566] session description or an 481 SDP offer/answer pair [RFC3264]. 483 Session info documents can be used for session-specific policies 484 [I-D.ietf-sip-session-policy-framework]. In this usage, a UA creates 485 a session info document based on its SDP description(s) and sends 486 this document to the policy server. The policy server modifies this 487 document according to the policies that apply to the described 488 session and returns a version of the session info document that is 489 compliant to the policies. For example, if video streams are not 490 permissible under current policies and the UA submits a session info 491 document that contains a video stream, the policy server will disable 492 the video stream in the session info document that it returns to the 493 UA. 495 Session info documents use the root element. They use 496 elements described in this section and common elements described in 497 Section 7. 499 Elements that are only present in session info document do not 500 require merging rules. If used in the context of session-specific 501 policies, session info documents are sent to one policy server at a 502 time only, therefore a UA does not need to merge multiple session 503 info documents into one. A policy server needs to modify a session 504 info document it has received according to its policies. The 505 modification of session info documents is determined by the local 506 policies of the policy server and outside the scope of this standard. 508 A policy server can completely reject a session by returning an 509 session info document with an empty element: 511 <\session-info> 513 5.1. Mapping SDP to Session Info Documents 515 If a UA has an SDP offer as well as an answer [RFC3264] and wants to 516 create a session info document, the UA MUST use the answer to fill in 517 the elements of the session info document except for the remote-host- 518 port and local-host-port elements, which are taken from the remote 519 and local session description respectively. (The local session 520 description is the one sent by the UA; the remote session description 521 is the one received from the remote UA.) 523 The following rules describe the creation of session info documents 524 based on SDP description(s) for a few exemplary elements. Other 525 elements are created following the same principles. 527 A UA MUST create a separate element for each m= line in an 528 SDP description; the order of the elements corresponds to 529 the order of the m= lines. The UA MUST insert the media type from 530 the m= line into a element and MUST create a 531 element for each codec listed in the m= line. 533 The UA MUST create a element for each stream using 534 the port taken from the m= line and the address from the 535 corresponding c= line of the local session description. The UA MUST 536 create a element using the port and address from 537 the m= and c= lines for the same stream taken from the remote session 538 description if this session description is available. 540 The mapping from a session info document to a SDP description follows 541 the same rules in the reverse direction. 543 5.2. The Element 545 The element describes the properties of a specific SIP 546 session. The element MAY contain one optional 547 , and multiple (including zero) , , , and 549 elements as well as elements from other namespaces. The MPDF 550 elements are defined in Section 7. 552 5.3. The Element 554 The element is a container that is used to describe the 555 media streams used in a session. A element contains zero 556 or more elements. Each element describes the 557 properties (e.g., media type, codecs and IP addresses and ports) of a 558 single media stream. 560 5.3.1. The Element 562 The element describes a specific media stream. It contains 563 the media type, codecs and the hostname(s) or IP address(es) and 564 port(s) of this stream. 566 The hostname(s) or IP address(es) and port number(s) of a stream 567 correspond to the ones listed in the session description(s). A UA 568 that generates a element MUST insert the hostname/port found 569 in the local session description for this media stream into the 570 local-host-port element. The UA MUST insert the hostname/port of the 571 remote session description into the remote-host-port element, if the 572 remote session description is available to the UA. If not, the UA 573 generates a stream element that only contains the local-host-port 574 element. 576 This element MAY have the following attributes (see Section 4.3): 577 direction, label. 579 The label attribute is used to identify a specific media stream in a 580 session description. The value of the label attribute is a token. 581 The token can be chosen freely, however, it MUST be unique among all 582 element in a session-info document. If a label attribute 583 [RFC4574] is present in the SDP description, its value MUST be used 584 as the label attribute value of the corresponding element. 586 The element MUST contain one element, one or 587 more elements and one element. The 588 element MAY contain one element. 590 5.3.1.1. The Element 592 The element contains the hostname or IP address and 593 the receiving port number of the media stream in the local session 594 description. The hostname or IP address is separated from the port 595 by a ":". An example is: "host.example.com:49562". 597 The hostname or IP address of element is found in the c= element for 598 the stream in the local SDP description. The port number is found in 599 the m= element. 601 5.3.1.2. The Element 603 The element is structured exactly as the element. However, it identifies the hostname or IP 605 address and receiving port number of the media stream in the remote 606 session description. 608 5.4. The Element 610 The element expresses a policy for routing a 611 media stream through a media intermediary. The purpose of the 612 element is to tell the UA to send a media 613 stream through one (or a chain of) media intermediaries. Instead of 614 sending the media directly to its final destination, the UA specifies 615 a source route, which touches each intermediary and then reaches the 616 final recipient. If there are N hops, including the final recipient, 617 there needs to be a way for the media stream to specify N 618 destinations. 620 The element is a container that lists all 621 media intermediaries to be traversed. Media intermediaries should be 622 traversed in the order in which they appear in this list. The 623 topmost entry should be traversed first, the last entry should be 624 traversed last. 626 Different types of intermediaries exist. These intermediaries are 627 not necessarily interoperable and it may not be possible to chain 628 them in an arbitrary order. A element SHOULD 629 therefore only contain intermediary elements of the same type. 631 This element MAY have the following attributes (see Section 4.3): 632 direction. 634 Multiple elements MAY only be present in a 635 container if each applies to a different set of streams (e.g., one 636 element for incoming and one for outgoing 637 streams). The element MUST contain one or 638 more elements defining a specific media intermediary, such as or . 641 Note: it is not intended that the element 642 replaces connectivity discovery mechanisms such as ICE. Instead 643 of finding media relays that provide connectivity, this element 644 defines a policy for media intermediaries that should be 645 traversed. The set of intermediaries defined in the element and the ones discovered through ICE may 647 overlap but don't have to. 649 5.4.1. The Element 651 A fixed intermediary relies on pre-configured forwarding rules. The 652 user agent simply sends media to the first media intermediary listed. 653 It can assume that this media intermediary has been pre-configured 654 with a forwarding rule for the media stream and knows where to 655 forward the packets to. The configuration of forwarding rules in the 656 intermediary must be done through other means. 658 The contents of a element MUST be echoed to all 659 policy servers that provide policies for a session. I.e., if 660 multiple policy servers provide policies for the same session, this 661 element needs to be forwarded to all of them, possibly in a second 662 round of session-specific policy subscriptions as described in 663 [I-D.ietf-sip-session-policy-framework] in section Contacting the 664 Policy Server. 666 The element MUST contain one 667 element and MAY contain multiple optional elements. 669 5.4.1.1. The Element 671 The element contains the hostname or IP address and 672 port number of a media intermediary. The UA uses this hostname/IP 673 address and port to send its media streams to the intermediary. The 674 hostname or IP address is separated from the port by a ":". 676 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 677 port number SHOULD be included in the element. All 678 additional port numbers SHOULD be identified in 679 elements. 681 5.4.1.2. The Element 683 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 684 port number SHOULD be included in the element. All 685 additional port numbers SHOULD be identified in 686 elements. 688 5.4.2. The Element 690 The TURN [RFC5766] protocol provides a mechanism for inserting a 691 relay into the media path. Although the main purpose of TURN is NAT 692 traversal, it is possible for a TURN relay to perform other media 693 intermediary functionalities. The user agent establishes a binding 694 on the TURN server and uses this binding to transmit and receive 695 media. 697 The element MUST contain one 698 element and MAY contain multiple optional elements 699 and zero or one each of the , , and 700 elements. If no element is present, UDP is assumed. 702 5.4.2.1. The Element 704 The element contains the shared secret needed to 705 authenticate at the media intermediary. 707 5.4.2.2. The element 709 The element contains the user ID needed to authenticate to the 710 media intermediary. 712 5.4.2.3. The Element 714 The element contains the name of the transport to be used 715 for communicating with the TURN server. This document defines the 716 values "tcp" and "udp" for use in the element. Other 717 specifications may define additional values. 719 5.4.3. The Element 721 The MSRP Relay Extensions [RFC4976] define a means for incorporating 722 relays into the media path of an MSRP [RFC4975] session. MSRP is 723 explicitly designed for a variety of purposes, including policy 724 enforcement. 726 The element MUST contain one element, 727 and may contain zero or one each of the and 728 elements. 730 5.4.3.1. The Element 732 The element contains a URI that indicates the MSRP server 733 to use for an intermediary. The UA uses this URI to authenticate 734 with the MSRP relay, and then uses the URI it learns through that 735 authentication process for any MSRP media it sends or receives. Only 736 URIs with a scheme of "msrps:" are valid in the element. 738 6. Session Policy Documents 740 Session policy documents describe policies for SIP sessions. Session 741 policy documents are independent of any specific session description 742 and express general policies for SIP sessions. A session policy 743 document is used to determine if a SIP session is policy conformant 744 and can be used to modify the session, if needed, to conform to the 745 described policies. 747 Session policy documents can be used to encode session-independent 748 policies [I-D.ietf-sip-session-policy-framework]. In this usage, a 749 policy server creates a session policy document and passes this 750 document to a UA. The UA applies the policies defined to the SIP 751 sessions it is establishing. For example, a session policy document 752 can contain an element that prohibits the use of video. To set up a 753 session that is compliant to this policy, a UA does not include the 754 media type video in its SDP offer or answer. 756 Session policy documents use the root element. They 757 use elements described in this section and common elements described 758 in Section 7. 760 6.1. Merging Session Policies 762 A UA may receive session policy documents from multiple sources; 763 multiple session policy documents can be merged into a single session 764 policy document which expresses the logical AND of the policies. 766 6.1.1. Single Value Selection 768 Properties that have a single value (e.g., the maximum bandwidth 769 allowed) require that a common value is determined for this property 770 during the merging process. The merging rules for determining this 771 value need to be defined individually for each element in the schema 772 definition (e.g., select the lowest maximum bandwidth). 774 6.1.2. Merging Sets 776 The media-types-allowed, media-types-excluded, codecs-allowed and 777 codecs-excluded are containers that contain a set of media-types/ 778 codecs. The values defined in these containers need to be merged to 779 determine the set of media-types/codecs that are permissible in a 780 session. 782 To merge the media-types-* and codecs-* containers a UA needs to 783 apply all containers it has received one after the other the set of 784 media-types/codecs it supports. After applying media-types-*/ 785 codecs-* elements, the UA has the list of media-types/codecs that are 786 allowed in a session. The containers can be applied in any order. 787 However, each time a container is applied to the set of media-types/ 788 codecs allowed, this set MUST stay the same or be reduced. Media- 789 types/codecs cannot be added during this process. 791 The following example illustrates the merging process for two data 792 sets. In this example, the UA supports the following set of audio 793 codecs: PCMA, PCMU and G729. After applying session policy document 794 1, the UA removes PCMA as it is disallowed by this policy. The 795 remaining set of codecs is: PCMU and G729. Session policy document 2 796 disallows all codecs that are not listed. After applying this 797 policy, the set of codecs allowed is: G729. 799 Session Policy Document 1: 800 801 audio/PCMA 802 804 Session Policy Document 2: 805 806 audio/PCMA 807 audio/G729 808 810 It is possible that two session policy documents define non- 811 overlapping sets of allowed media-types or codecs. The resulting 812 merged set would be empty, which is illegal according to the schema 813 definition of the media-types/codecs element. This constitutes a 814 conflict that cannot be resolved automatically. If these properties 815 are enforced by both networks, the UA will not be able to set up a 816 session. 818 The combined set of media-types/codecs MUST again be valid and well- 819 formed according to the schema definitions. A conflict occurs if the 820 combined property set is not a well-formed document after the merging 821 process is completed. 823 6.1.3. Local Policy Server Selection 825 Some properties require that only values from the local policy server 826 are used. The local policy server is the policy server that is in 827 the local domain of the user agent. 829 If policy documents are delivered through the configuration framework 830 [I-D.ietf-sipping-config-framework], the value received through a 831 subscription using the "local-network" profile-type is used. Values 832 received through other profile-type subscriptions are discarded. 834 If policy documents are delivered through the session-specific policy 835 mechanism [I-D.ietf-sip-session-policy-framework] the value received 836 from the policy server identified by the Local Policy Server URI are 837 used. Values received from other policy servers are discarded. 839 6.2. The Element 841 The element describes a policy that applies to SIP 842 sessions. The element MAY contain one optional 843 and element and multiple (including zero) 844 , , , 845 , , , and 846 elements as well as elements from other namespaces. The 847 MPDF elements are defined in Section 7. 849 6.3. The Element 851 The element is a container that is used to 852 define the set of media types (e.g., audio, video) that are allowed 853 in a session. All media types that are not listed in this container 854 are not permitted in a session. A specific media type is allowed by 855 adding the corresponding element to this container. 857 This element MAY have the following attributes (see Section 4.3): 858 direction, visibility. 860 Multiple elements MAY only be present in a 861 container element if each applies to a different set of streams 862 (e.g., one element for incoming and one for 863 outgoing streams). The element MUST contain 864 one or more elements. 866 A element MUST NOT be used in a container that 867 contains a element. 869 Merging of session-policy documents: 870 containers are merged as described in "Merging Sets" 871 Section 6.1.2. 873 6.4. The Element 875 The element is a container that is used to 876 define the set of media types (e.g., audio, video) that are not 877 permitted in a session. All media types that are not listed in this 878 container are allowed and can be used in a session. A specific media 879 type is excluded from a session by adding the corresponding element to this container. 882 This element MAY have the following attributes (see Section 4.3): 883 direction, visibility. 885 Multiple elements MAY only be present in a 886 container element if each applies to a different set of streams 887 (e.g., one element for incoming and one for 888 outgoing streams). The element MUST contain 889 one or more elements. 891 A element MUST NOT be used in a container that 892 contains a element. 894 Merging of session-policy documents: 895 containers are merged as described in "Merging Sets" 896 Section 6.1.2. 898 6.5. The Element 900 The element is a container that is used to define 901 the set of codecs that may be used in a session. All codes not 902 listed in the element are disallowed and MUST NOT be 903 used in a session. A policy MUST allow the use of at least one codec 904 per media type. A specific codec is allowed by adding the 905 corresponding element to this container. 907 The element MAY have the following attributes (see 908 Section 4.3): direction, visibility. 910 Multiple elements MAY only be present in a container 911 element if each applies to a different set of streams (e.g., one 912 element for incoming and one for outgoing streams). 913 The element MUST contain one or more 914 elements. 916 A element MUST NOT be used in a container that 917 contains a element. 919 Merging of session-policy documents: containers 920 are merged as described in "Merging Sets" Section 6.1.2. 922 6.6. The Element 924 The element is a container that is used to define 925 the set of codecs that are disallowed in a session. All codes not 926 listed in the element are permitted and MAY be used 927 in a session. A specific codec is disallowed by adding the 928 corresponding element to this container. 930 The element MAY have the following attributes (see 931 Section 4.3): direction, visibility. 933 Multiple elements MAY only be present in a 934 container element if each applies to a different set of streams 935 (e.g., one element for incoming and one for 936 outgoing streams). The element MUST contain one or 937 more elements. 939 A element MUST NOT be used in a container that 940 contains a element. 942 Merging of session-policy documents: containers 943 are merged as described in "Merging Sets" Section 6.1.2. 945 6.7. The Element 947 Domains often require that a user agent only uses ports in a certain 948 range for media streams. The element defines a policy 949 for the ports a user agent can use for media. The value of this 950 element consists of a start port and an end port separated by a "-". 951 The start/end port is the first/last port that can be used. 953 This element MAY have the following attributes (see Section 4.3): 954 visibility. 956 Merging of session-policy documents: the local domain of the user 957 agent has precedence over other domains and its local ports value 958 is used. During the merging process, element values 959 from local policy server selected as described in "Local Policy 960 Server Selection" Section 6.1.3 are used. 962 7. Common Media Policy Dataset Elements 964 This section describes common XML elements that are used in session 965 info and session policy documents to encode the media properties of 966 SIP sessions. 968 7.1. The Element 970 The element identifies a specific media type. The value 971 of this element MUST be the name of a media type, such as 'audio', 972 'video', 'text', or 'application'. 974 This element MAY have the following attribute (see Section 4.3): q. 976 If used in a session policy document inside a 977 element, the media types defined MAY be used in a session. If used 978 in a session policy document inside a element, 979 the media types defined MUST NOT be used in a session. 981 7.2. The Element 983 The element identifies a specific codec. The content of this 984 element MUST be a media type and subtype (e.g., audio/PCMA [RFC4856] 985 or video/H263 [RFC4629]), possibly with parameters. 987 The element MAY have the following attribute (see 988 Section 4.3): q. 990 If used in a session policy document inside a 991 element, the codec defined MAY be used in a session. If used in a 992 session policy document inside a element, the codec 993 defined MUST NOT be used in a session. 995 The element MUST contain one element and MAY 996 contain multiple optional elements. 998 7.2.1. The Element 1000 The element contains a media type and subtype that 1001 identifies a codec. The value of this element MUST be a media type 1002 and subtype [RFC4855] separated by a "/" (e.g., audio/PCMA, audio/ 1003 G726-16 [RFC4856] or video/H263 [RFC4629]). 1005 7.2.2. The Element 1007 The element may be needed for some codecs to 1008 identify a particular encoding or profile. The value of this element 1009 MUST be a name-value pair containing the name and the value of a 1010 media type parameter for the codec [RFC4855]. The name and value are 1011 separated by a "=". For example, the parameter "profile=0" can be 1012 used to specify a specific profile for the codec "video/H263-2000" 1013 [RFC4629]. 1015 7.3. The Element 1017 The element defines the overall maximum bandwidth in 1018 kilobits per second an entity can/will use for media streams at any 1019 point in time. It defines an upper limit for the total bandwidth an 1020 entity can/will use for the transmission of media streams. The limit 1021 corresponds to the sum of the maximum session bandwidth of all 1022 sessions a UA may set up in parallel. 1024 The bandwidth limit given in the element includes the 1025 bandwidth needed for lower-layer transport and network protocols 1026 (e.g., UDP and IP). 1028 The element MAY have the following attribute (see 1029 Section 4.3): direction. 1031 If used in a element, the element MAY have 1032 the following additional attribute (see Section 4.3): visibility. 1034 If the element occurs multiple times in a container element, 1035 each instance MUST apply to a different set of media streams (i.e., 1036 one element for outgoing and one for incoming streams). 1038 Merging of session-policy documents: the lowest max-bw value is 1039 used. 1041 7.4. The Element 1043 The element defines the maximum bandwidth in 1044 kilobits per second an entity can/will use for media streams in the 1045 described session. It defines an upper limit for the total bandwidth 1046 of a single session. This limit corresponds to the sum of the 1047 maximum stream bandwidth of all media streams in a session. 1049 The bandwidth limit given in the element includes 1050 the bandwidth needed for lower-layer transport and network protocols 1051 (e.g., UDP and IP). 1053 The value of the element is equivalent to the CT 1054 bandwidth in the b= line of an SDP [RFC4566] announcement. 1056 The element MAY have the following attribute (see 1057 Section 4.3): direction. 1059 If used in a element, the element 1060 MAY have the following additional attribute (see Section 4.3): 1061 visibility. 1063 If the element occurs multiple times in a container 1064 element, each instance MUST apply to a different set of media streams 1065 (i.e., one element for outgoing and one for incoming 1066 streams). 1068 Merging of session-policy documents: the lowest max-session-bw 1069 value is used. 1071 7.5. The Element 1073 The element defines the maximum bandwidth in kilobits 1074 per second an entity can/will use for each media stream in the 1075 described session. 1077 The bandwidth limit given in the element includes the 1078 bandwidth needed for lower-layer transport and network protocols 1079 (e.g., UDP and IP). 1081 The value of the element is equivalent to the AS 1082 bandwidth in the b= line of an SDP [RFC4566] announcement. 1084 The element MAY have the following attribute (see 1085 Section 4.3): direction, media-type. 1087 If used in a element, the element 1088 MAY have the following additional attribute (see Section 4.3): 1089 visibility. 1091 If used in a element, the element MAY 1092 have the following additional attribute: label. 1094 The media-type attribute is used to define that the 1095 element only applies to streams of a certain media type. For 1096 example, it may only apply to audio streams. The value of the 1097 'media-type' attribute MUST be the media type, such as 'audio', 1098 'video', 'text', or 'application'. 1100 The label attribute is used to define a bandwidth limit for a 1101 specific media stream. The use of this attribute requires that the 1102 element that represents the media stream to which this 1103 bandwidth limit applies also has a label attribute. A 1104 element with a label attribute applies only to the 1105 stream element that has a label attribute with the same value. If no 1106 matching element exists, then the element 1107 MUST be ignored. 1109 If the element occurs multiple times in a container 1110 element, each instance MUST apply to a different set of media streams 1111 (i.e., one element for outgoing and one for incoming 1112 streams). 1114 Merging of session-policy documents: the lowest max-stream-bw 1115 value is used. 1117 7.6. The Element 1119 The element contains an Differentiated Services Codepoint 1120 (DSCP) [RFC2474] value that should be used to populate the IP DS 1121 field of media packets. The contains an integer value 1122 that represents a 6 bit field and therefore ranges from 0 to 63. 1124 This element MAY have the following attributes (see Section 4.3): 1125 direction, media-type. 1127 If used in a element, the element MAY 1128 have the following additional attribute (see Section 4.3): 1129 visibility. 1131 The media-type attribute is used to define that element 1132 only applies to streams of a certain media type. For example, it may 1133 only apply to audio streams. The value of the 'media-type' attribute 1134 MUST be the name of a media type, such as 'audio', 'video', 'text', 1135 or 'application'. 1137 The element is optional and MAY occur multiple times 1138 inside a container. If the element occurs multiple times, 1139 each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). 1142 Merging of session-policy documents: the local domain of the user 1143 agent has precedence over other domains and its DSCP value is 1144 used. During the merging process, element values from 1145 local policy server selected as described in "Local Policy Server 1146 Selection" Section 6.1.3 are used. 1148 7.7. The Element 1150 The element provides context information about a session 1151 policy or session information document. 1153 The element MAY contain multiple and one 1154 element. 1156 If used in a element, the element MAY also 1157 contain a element. 1159 If used in a element, the element MAY also 1160 contain a and a element. 1162 Merging of session-policy documents: the element is not 1163 subject to merging. 1165 7.7.1. The Element 1167 The element contains the URI of the policy server 1168 that has issued this policy. 1170 The element is only defined inside a element. 1173 7.7.2. The Element 1175 The element contains a contact address (e.g., a SIP URI or 1176 email address) under which the issuer of this document can be 1177 reached. 1179 7.7.3. The Element 1181 The element provides a short textual description of the policy 1182 or session that should be intelligible to the human user. 1184 7.7.4. The Element 1186 The element identifies the request-URI the dialog 1187 initiating request of a session is sent to. 1189 The element is only defined inside a 1190 element. 1192 7.7.5. The Element 1194 The element provides a mechanism for a policy server to 1195 return an opaque token to a UA. This is sometimes needed to ensure 1196 that all requests for a session are routed to the same policy server. 1197 The use of this token is described in the Framework for SIP Session 1198 Policies [I-D.ietf-sip-session-policy-framework]. 1200 The element is only defined inside a element. 1202 7.8. Other Session Properties 1204 A number of additional elements have been proposed for a media 1205 property language. These elements are deemed to be outside the scope 1206 of this format. However, they may be defined in extensions of MPDF 1207 or other profile data sets. 1209 o maximum number of streams 1210 o maximum number of sessions 1211 o maximum number of streams per session 1212 o external address and port 1213 o media transport protocol 1214 o outbound proxy 1215 o SIP methods 1216 o SIP option tags 1217 o SIP transport protocol 1218 o body disposition 1219 o body format 1220 o body encryption 1222 8. Examples 1223 8.1. Session Policy Documents 1225 The following example describes a session policy document that allows 1226 the use of audio and video and prohibits the use of other media 1227 types. It allows the use of any codec except G.723 and G.729. 1229 1230 1231 policy@biloxi.example.com 1232 sip:policy_manager@example.com 1233 Access network policies 1234 1235 1236 audio 1237 video 1238 1239 1240 audio/G729 1241 audio/G723 1242 1243 1245 8.2. Session Information Documents 1247 The following examples contain session descriptions and the session 1248 information documents that represent these sessions. 1250 8.2.1. Example 1 1252 In this example, a session info document is created based on one 1253 session description. This session info document would be created, 1254 for example, by a UA that has composed an offer and is now contacting 1255 a policy server. 1257 Local SDP session description: 1259 v=0 1260 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1261 s= 1262 c=IN IP4 host.somewhere.example 1263 t=0 0 1264 m=audio 49562 RTP/AVP 0 1 3 1265 a=rtpmap:0 PCMU/8000 1266 a=rtpmap:1 1016/8000 1267 a=rtpmap:3 GSM/8000 1268 m=video 51234 RTP/AVP 31 34 1269 a=rtpmap:31 H261/90000 1270 a=rtpmap:34 H263/90000 1272 MPDF document: 1274 1275 1276 sip:alice@somewhere.example 1277 session information 1278 1279 1280 1281 audio 1282 audio/PCMU 1283 audio/1016 1284 audio/GSM 1285 host.somewhere.example:49562 1286 1287 1288 video 1289 video/H261 1290 video/H263 1291 host.somewhere.example:51234 1292 1293 1294 1296 8.2.2. Example 2 1298 In this example, a session info document is created that represents 1299 two session descriptions (i.e., an offer and answer). This session 1300 info document would be created, for example, by a UA that has 1301 received an answer from another UA and is now contacting a policy 1302 server. 1304 Local SDP session description: 1306 v=0 1307 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1308 s= 1309 c=IN IP4 host.somewhere.example 1310 t=0 0 1311 m=audio 49562 RTP/AVP 0 1 3 1312 a=rtpmap:0 PCMU/8000 1313 a=rtpmap:1 1016/8000 1314 a=rtpmap:3 GSM/8000 1315 m=video 51234 RTP/AVP 31 34 1316 a=rtpmap:31 H261/90000 1317 a=rtpmap:34 H263/90000 1318 Remote SDP session description: 1320 v=0 1321 o=bob 2890844730 2890844730 IN IP4 host.anywhere.example 1322 s= 1323 c=IN IP4 host.anywhere.example 1324 t=0 0 1325 m=audio 52124 RTP/AVP 0 3 1326 a=rtpmap:0 PCMU/8000 1327 a=rtpmap:3 GSM/8000 1328 m=video 50286 RTP/AVP 31 1329 a=rtpmap:31 H261/90000 1331 MPDF document that represents the local and the remote session 1332 description: 1334 1335 1336 sip:alice@somewhere.example 1337 session information 1338 1339 1340 1341 audio 1342 audio/PCMU 1343 audio/GSM 1344 host.somewhere.example:49562 1345 host.anywhere.example:52124 1346 1347 1348 video 1349 video/H261 1350 host.somewhere.example:51234 1351 host.anywhere.example:50286 1352 1353 1354 1356 The following MPDF document is a modified version of the above 1357 document, which can be returned by a policy server. This document 1358 reflects a policy that defines a maximum session bandwidth of 192 1359 kbit and a maximum bandwidth for the H261 video stream of 128 kbit. 1361 1362 1363 sip:alice@somewhere.example 1364 modified session information 1365 1366 1367 1368 audio 1369 audio/PCMU 1370 audio/GSM 1371 host.somewhere.example:49562 1372 host.anywhere.example:52124 1373 1374 1375 video 1376 video/H261 1377 host.somewhere.example:51234 1378 host.anywhere.example:50286 1379 1380 1381 128 1382 192 1383 1385 9. Relax NG Definition 1387 This section needs to be updated. 1389 1390 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1504 1505 1506 1507 1508 1509 1510 1511 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1550 1551 1552 1553 1554 1555 1557 1558 1559 1560 1561 1562 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1593 1594 1595 1596 1597 1598 1599 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1614 1615 1616 1617 1618 1619 1620 1621 1622 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1683 1684 1685 1686 1687 1689 1690 1691 1692 1693 1695 1697 10. Security Considerations 1699 Session policy information can be sensitive information. The 1700 protocol used to distribute session policy information SHOULD ensure 1701 privacy, message integrity and authentication. Furthermore, the 1702 protocol SHOULD provide access controls which restrict who can see 1703 who else's session policy information. 1705 11. IANA Considerations 1707 This document registers a new media type, application/ 1708 media-policy-dataset+xml, and a new XML namespace. 1710 11.1. Media Type Registration 1712 Media type name: application 1714 Media subtype name: media-policy-dataset+xml 1716 Mandatory parameters: none 1718 Optional parameters: Same as charset parameter application/xml as 1719 specified in RFC 3023 [RFC3023]. 1721 Encoding considerations: Same as encoding considerations of 1722 application/xml as specified in RFC 3023 [RFC3023]. 1724 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1725 Section 10 of this specification. 1727 Interoperability considerations: none. 1729 Published specification: This document. 1731 Applications which use this media type: This document type has been 1732 used to convey media policy information between SIP user agents and a 1733 domain. 1735 Additional Information: 1737 Magic Number: None 1739 File Extension: .mpf or .xml 1741 Macintosh file type code: "TEXT" 1743 Personal and email address for further information: Volker Hilt, 1744 1746 Intended usage: COMMON 1748 Author/Change controller: The IETF. 1750 11.2. URN Sub-Namespace Registration 1752 This section registers a new XML namespace, as per the guidelines in 1753 [RFC3688] 1755 URI: The URI for this namespace is 1756 urn:ietf:params:xml:ns:mediadataset. 1758 Registrant Contact: IETF, SIPPING working group, , 1759 Volker Hilt, 1761 XML: 1763 BEGIN 1764 1765 1767 1768 1769 1771 Media Policy Dataset Namespace 1772 1773 1774

Namespace for Media Policy Datasets

1775

urn:ietf:params:xml:ns:mediadataset

1776

See RFCXXXX.

1777 1778 1779 END 1781 12. References 1783 12.1. Normative References 1785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1786 Requirement Levels", BCP 14, RFC 2119, March 1997. 1788 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1790 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1791 "Definition of the Differentiated Services Field (DS 1792 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1793 December 1998. 1795 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1796 Types", RFC 3023, January 2001. 1798 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1799 with Session Description Protocol (SDP)", RFC 3264, 1800 June 2002. 1802 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1803 January 2004. 1805 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1806 Description Protocol", RFC 4566, July 2006. 1808 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1809 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1811 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1812 Formats", RFC 4855, February 2007. 1814 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1815 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1817 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1818 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1819 September 2007. 1821 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1822 Relays around NAT (TURN): Relay Extensions to Session 1823 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1825 [W3C.REC-xml-20040204] 1826 Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., 1827 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 1828 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1829 20040204, February 2004, 1830 . 1832 [W3C.REC-xml-names-19990114] 1833 Hollander, D., Layman, A., and T. Bray, "Namespaces in 1834 XML", World Wide Web Consortium FirstEdition REC-xml- 1835 names-19990114, January 1999, 1836 . 1838 12.2. Informative References 1840 [I-D.ietf-sip-session-policy-framework] 1841 Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework 1842 for Session Initiation Protocol (SIP) Session Policies", 1843 draft-ietf-sip-session-policy-framework-08 (work in 1844 progress), December 2010. 1846 [I-D.ietf-sipping-config-framework] 1847 Channabasappa, S., "A Framework for Session Initiation 1848 Protocol User Agent Profile Delivery", 1849 draft-ietf-sipping-config-framework-18 (work in progress), 1850 October 2010. 1852 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1853 August 1999. 1855 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1856 A., Peterson, J., Sparks, R., Handley, M., and E. 1857 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1858 June 2002. 1860 [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. 1861 Even, "RTP Payload Format for ITU-T Rec", RFC 4629, 1862 January 2007. 1864 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 1865 the RTP Profile for Audio and Video Conferences", 1866 RFC 4856, February 2007. 1868 Appendix A. Acknowledgements 1870 Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach 1871 and Ben Campbell for the discussions and suggestions. Many thanks to 1872 Roni Even and Mary Barnes for reviewing the draft and to Jari 1873 Urpalainen for helping with the Relax NG schema. 1875 Authors' Addresses 1877 Volker Hilt 1878 Bell Labs/Alcatel-Lucent 1879 791 Holmdel-Keyport Rd 1880 Holmdel, NJ 07733 1881 USA 1883 Email: volkerh@bell-labs.com 1885 Dale R. Worley 1886 Avaya Inc. 1887 600 Technology Park Dr. 1888 Billerica, MA 01821 1889 US 1891 Email: dworley@avaya.com 1893 Gonzalo Camarillo 1894 Ericsson 1895 Hirsalantie 11 1896 Jorvas 02420 1897 Finland 1899 Email: Gonzalo.Camarillo@ericsson.com 1901 Jonathan Rosenberg 1902 jdrosen.net 1903 Monmouth, NJ 1904 USA 1906 Email: jdrosen@jdrosen.net