idnits 2.17.1 draft-ietf-sipping-media-policy-dataset-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (March 7, 2009) is 5527 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-13 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-profile-datasets-02 ** 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) == Outdated reference: A later version (-10) exists of draft-ietf-sip-session-policy-framework-05 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-15 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 G. Camarillo 5 Expires: September 8, 2009 Ericsson 6 J. Rosenberg 7 Cisco 8 March 7, 2009 10 A User Agent Profile Data Set for Media Policy 11 draft-ietf-sipping-media-policy-dataset-07 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 8, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This specification defines a document format for the media properties 50 of Session Initiation Protocol (SIP) sessions. Examples for media 51 properties are the codecs or media types used in a session. This 52 document format is based on XML and extends the Schema for SIP User 53 Agent Profile Data Sets. It can be used to describe the properties 54 of a specific SIP session or to define policies that are then applied 55 to different SIP sessions. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Namespace and MIME Type . . . . . . . . . . . . . . . . . 5 63 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Inheritance from the Profile Data Set . . . . . . . . . . 6 65 4. Session Info Documents . . . . . . . . . . . . . . . . . . . . 6 66 4.1. The Element . . . . . . . . . . . . . . . . 7 67 4.2. Mapping SDP to Session Info Documents . . . . . . . . . . 7 68 5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 8 69 5.1. The Element . . . . . . . . . . . . . . . 8 70 6. Media Property Elements . . . . . . . . . . . . . . . . . . . 8 71 6.1. The Element . . . . . . . . . . . . . . . . 8 72 6.1.1. The Element . . . . . . . . . . . . . . . 9 73 6.2. The Element . . . . . . . . . . . . . . . . . . . 9 74 6.2.1. The Element . . . . . . . . . . . . . . . . . 10 75 6.3. The Element . . . . . . . . . . . . . . . . . . 10 76 6.3.1. The Element . . . . . . . . . . . . . . . . . 11 77 6.4. The Element . . . . . . . . . . . . . . . . . . . 12 78 6.5. The Element . . . . . . . . . . . . . . . 12 79 6.6. The Element . . . . . . . . . . . . . . . 13 80 6.7. The Element . . . . . . . . . . . . 14 81 6.7.1. The Element . . . . . . . . . . . 15 82 6.7.2. The Element . . . . . . . . . . . 16 83 6.7.3. The Element . . . . . . . . . . . 16 84 6.8. The Element . . . . . . . . . . . . . . . . . . 17 85 6.9. The Element . . . . . . . . . . . . . . . . 17 86 6.10. The Element . . . . . . . . . . . . . . . . . . 18 87 6.10.1. The Element . . . . . . . . . . . 18 88 6.10.2. The Element . . . . . . . . . . . . . . . . 18 89 6.10.3. The Element . . . . . . . . . . . . . . . . . . 18 90 6.10.4. The Element . . . . . . . . . . . . . . 19 91 6.10.5. The Element . . . . . . . . . . . . . . . . . 19 92 6.11. Other Session Properties . . . . . . . . . . . . . . . . . 19 93 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 7.1. Session Policy Documents . . . . . . . . . . . . . . . . . 19 95 7.2. Session Information Documents . . . . . . . . . . . . . . 20 96 7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20 97 7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 98 8. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 23 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 101 10.1. MIME Registration . . . . . . . . . . . . . . . . . . . . 30 102 10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 31 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 33 106 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 109 1. Introduction 111 The Framework for Session Initiation Protocol (SIP) [RFC3261] User 112 Agent Profile Delivery [I-D.ietf-sipping-config-framework] and the 113 Framework for SIP Session Policies 114 [I-D.ietf-sip-session-policy-framework] define mechanisms to convey 115 session policies and configuration information from a network server 116 to a user agent. An important piece of the information conveyed to 117 the user agent relates to the media properties of the SIP sessions 118 set up by the user agent. Examples for these media properties are 119 the codecs and media types used, the media-intermediaries to be 120 traversed or the maximum bandwidth available for media streams. 122 This specification defines a document format for media properties of 123 SIP sessions, the Media Policy Dataset Format (MPDF). This format 124 can be used in two ways: first, it can be used to describe the 125 properties of a given SIP session (e.g., the media types and codecs 126 used). These MPDF documents are called session info documents and 127 they are usually created based on the session description of a 128 session. Second, the MPDF format can be used to define policies for 129 SIP sessions in a session policy document. A session policy document 130 defines properties (e.g., the media types) that can or can not be 131 used in a session, independent of a specific session description. 133 If used with the Framework for SIP Session Policies 134 [I-D.ietf-sip-session-policy-framework], session info documents are 135 used in conjunction with session-specific policies. A session info 136 document is created by a UA based on the current session description 137 and submitted to the policy server. The policy server examines the 138 session info document, modifies it if necessary (e.g., by removing 139 video streams if video is not permitted) and returns the possibly 140 modified session info document to the UA. Session policy documents 141 on the other hand are used to describe session-independent policies 142 that can be submitted to the UA independent of a specific session. 144 The two types of MPDF documents, session information and session 145 policy documents, share the same set of XML elements to describe 146 session properties. Since the usage of these elements differs 147 between the two document types, they both use different root 148 elements: is the root element for session information 149 documents and is the root element for session policy 150 documents. This enables the recipient of a document to determine the 151 document type and to correctly interpret the media properties 152 defined. 154 A user agent can receive multiple session policy documents from 155 different sources. These documents need to be merged into a single 156 document the user agent can work with. This document specifies rules 157 for merging each of the XML elements defined. It should be noted 158 that these merging rules are part of the semantics of the XML 159 element. User agents implement the merging rules as part of 160 implementing the element semantics. As a consequence, it is not 161 possible to build an entity that can mechanically merge two session 162 policy documents without understanding the semantics of all elements 163 in the input documents. The Schema for SIP User Agent Profile Data 164 Sets [I-D.ietf-sipping-profile-datasets] describes common merging 165 rules that are referred to in this specification. 167 Merging is not needed for session information documents since they 168 are created by one source and describe a specific session. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 3. Design Considerations 178 This section discusses design considerations for the Media Policy 179 Dataset Format. 181 3.1. Namespace and MIME Type 183 The MPDF format is based on XML [W3C.REC-xml-20040204]. A MPDF 184 document MUST be well-formed and MUST be valid according to schemas, 185 including extension schemas, available to the validator and 186 applicable to the XML document. MPDF documents MUST be based on XML 187 1.0 and MUST be encoded using UTF-8. 189 MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The 190 namespace URIs for schemas defined in this specification are URNs 191 [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] 192 and extended by [RFC3688]. The namespace URN for the MPDF schema is: 194 urn:ietf:params:xml:ns:mediadataset 196 The MIME type for the Media Policy Dataset Format is: 198 application/media-policy-dataset+xml 200 3.2. Extensibility 202 The MPDF format extends the Schema for SIP User Agent Profile Data 203 Sets [I-D.ietf-sipping-profile-datasets] by specifying a data set for 204 media properties. Elements from the MPDF namespace can be used in 205 conjunction with elements from other extensions of this schema. 207 The MPDF format itself can also be extended using XML extension 208 mechanisms if additional media properties are needed. In particular, 209 elements from different XML namespaces MAY be present within a MPDF 210 document for the purposes of extensibility; elements or attributes 211 from unknown namespaces MUST be ignored. 213 3.3. Inheritance from the Profile Data Set 215 The MPDF format inherits the following attributes from the Profile 216 Data Set Schema [I-D.ietf-sipping-profile-datasets]: 218 o Property Access Control: 'visibility' attribute 219 o Policies: 'policy' and 'excluded-policy' attribute 220 o Unidirectional Properties: 'direction' attribute 221 o Preferences: 'q' attribute 223 The use of these attributes is defined individually for each element 224 in the XML format below. 226 The MPDF format also uses merging algorithms that are defined in the 227 Profile Data Set Schema. The use of these algorithms is defined 228 individually for each element in the XML format below. 230 4. Session Info Documents 232 Session info documents describe key properties of a SIP session such 233 as the media streams used in the session. Session info documents are 234 typically created based on an SDP [RFC4566] session description or an 235 SDP offer/answer pair [RFC3264]. 237 Session info documents can be used for session-specific policies 238 [I-D.ietf-sip-session-policy-framework]. In this usage, a UA creates 239 a session info document based on its SDP description(s) and sends 240 this document to the policy server. The policy server modifies this 241 document according to the policies that apply to the described 242 session and returns a version of the session info document that is 243 compliant to all policies. For example, if video streams are not 244 permissible under current policies and the UA submits a session info 245 document that contains a video stream, the policy server will remove 246 the video stream from the XML markup and return the modified session 247 info document to the UA. 249 Session info documents use the element. 251 A policy server can completely reject a session by returning an 252 session info document with an empty element: 254 <\session-info> 256 4.1. The Element 258 The element describes the properties of a specific SIP 259 session. The element MAY occur multiple times inside 260 a [I-D.ietf-sipping-profile-datasets] element. 262 The element MAY contain one optional , 263 and multiple (including zero) , , 264 , and elements as 265 well as elements from other namespaces. The MPDF elements are 266 defined in Section 6. 268 4.2. Mapping SDP to Session Info Documents 270 If a UA has an SDP offer as well as an answer [RFC3264] and wants to 271 create a session info document, the UA MUST use the answer to fill in 272 the elements of the session info document except for the remote-host- 273 port and local-host-port elements, which are taken from the remote 274 and local session description respectively. The local session 275 description is the one created locally by the UA (i.e., the offer if 276 the UA has initiated the offer/answer exchange). The remote session 277 description is the one received from the remote UA. 279 The following rules describe the creation of session info documents 280 based on SDP description(s) for a few exemplary elements. Other 281 elements are created following the same principles. 283 A UA MUST create a separate element for each m= line in an 284 SDP description. The UA MUST insert the media type from the m= line 285 into a element and MUST create a element for 286 each codec listed in the m= line. 288 The UA MUST create a element for each stream using 289 the port taken from the m= line and the address from the 290 corresponding c= line of the local session description. The UA MUST 291 create a element using the port and address from 292 the m= and c= lines for the same stream taken from the remote session 293 description if this session description is available. 295 The mapping from a session info document to a SDP description follows 296 the same rules in the reverse direction. 298 5. Session Policy Documents 300 Session policy documents describe a policy for SIP sessions. Session 301 policy documents are independent of a specific session description 302 and express general policies for SIP sessions. A session policy 303 document is used to determine if a SIP session is policy conformant 304 and to modify this session, if needed, according to the described 305 policies. 307 Session policy documents can be used to encode session-independent 308 policies [I-D.ietf-sip-session-policy-framework]. In this usage, a 309 policy server creates a session policy document and passes this 310 document to a UA. The UA applies the policies defined to the SIP 311 sessions it is establishing. For example, a session policy document 312 can contain an element that prohibits the use of video. To set up a 313 session that is compliant to this policy, a UA does not include the 314 media type video in its SDP offer or answer. 316 Session policy documents use the element. 318 5.1. The Element 320 The element describes a policy that applies to SIP 321 sessions. The element MAY occur multiple times 322 inside a [I-D.ietf-sipping-profile-datasets] element. 324 The element MAY contain one optional and 325 element and multiple (including zero) , 326 , , , and 327 elements as well as elements from other namespaces. The MPDF 328 elements are defined in Section 6. 330 6. Media Property Elements 332 This section describes XML elements that are used in session info and 333 session policy documents to encode the media properties of SIP 334 sessions. 336 6.1. The Element 338 The element is a container that is used to define the 339 set of media types (e.g., audio, video) that can or cannot be used in 340 a session. A specific media type is included in the set by adding 341 the corresponding element to this container. 343 The element can only be used in session policy document 344 (i.e., inside the container). 346 This element MAY have the following attributes (see Section 3.3): 347 direction, visibility, excluded-policy. 349 Multiple elements MAY only be present in a container 350 element if each applies to a different set of streams (e.g., one 351 element for incoming and one for outgoing streams). 352 The element MUST contain one or more 353 elements. 355 Merging of session-policy documents: containers are 356 merged using the "Multiple Enumerated Value Merging Algorithm" 357 [I-D.ietf-sipping-profile-datasets]. 359 6.1.1. The Element 361 The element identifies a specific media type. The value 362 of this element MUST be the name of a IANA registered media type (see 363 RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 364 'application'. 366 This element MAY have the following attribute (see Section 3.3): q. 368 If used inside a element, this element MAY have the 369 following additional attribute (see Section 3.3): policy. Media 370 types that have the policy 'allowed' MAY be used and media types with 371 the policy 'disallowed' MUST NOT be used. 373 6.2. The Element 375 The element is a container that is used to define the set of 376 codecs that may or may not be used in a session. A policy MUST allow 377 the use of at least one codec per media type. A specific codec is 378 included in the set by adding the corresponding element to 379 this container. 381 The element can only be used in a session policy document 382 (i.e., inside the container). 384 The element MAY have the following attributes (see 385 Section 3.3): direction, visibility, excluded-policy. 387 Multiple elements MAY only be present in a container element 388 if each applies to a different set of streams (e.g., one 389 element for incoming and one for outgoing streams). The 390 element MUST contain one or more elements. 392 Merging of session-policy documents: containers are 393 merged using the "Multiple Enumerated Value Merging Algorithm" 394 [I-D.ietf-sipping-profile-datasets]. 396 6.2.1. The Element 398 The element identifies a specific codec. The content of this 399 element MUST be a registered MIME type [RFC4855] using media type and 400 subtype (e.g., audio/PCMA [RFC4856] or video/H263 [RFC4629]) and 401 possibly additional registered MIME type parameters. 403 The element MAY have the following attribute (see 404 Section 3.3): q. 406 If used inside a element, the element MAY 407 have the following additional attribute (see Section 3.3): policy. 408 Codecs that have the policy 'allowed' MAY be used and codecs with the 409 policy 'disallowed' MUST NOT be used. 411 The element MUST contain one element and MAY 412 contain multiple optional elements. 414 6.2.1.1. The Element 416 The element contains a MIME type that identifies a codec. 417 The value of this element MUST be a combination of a registered MIME 418 media type and subtype [RFC4855] separated by a "/" (e.g., audio/ 419 PCMA, audio/G726-16 [RFC4856] or video/H263 [RFC4629]). 421 6.2.1.2. The Element 423 The element may be needed for some codecs to 424 identify a particular encoding or profile. The value of this element 425 MUST be a name-value pair containing the name and the value of a 426 registered MIME type parameter for the codec [RFC4855]. The name and 427 value are separated by a "=". For example, the parameter "profile=0" 428 can be used to specify a specific profile for the codec "video/ 429 H263-2000" [RFC4629]. 431 6.3. The Element 433 The element is a container that is used to describe the 434 media streams used in a session. A element can contain 435 multiple elements. Each element describes the 436 properties (e.g., media type, codecs and IP addresses and ports) of a 437 single media stream. 439 The element is only defined for session information 440 documents (i.e., in a container). 442 The element MUST contain one or more elements. 444 6.3.1. The Element 446 The element describes a specific media stream. It contains 447 the media type, codecs and the hostname(s) or IP address(es) and 448 port(s) of this stream. 450 The hostname(s) or IP address(es) and port number(s) of a stream 451 correspond to the ones listed in the session description(s). A UA 452 that generates element MUST insert the hostname/port found 453 in the local session description for this media stream into the 454 local-host-port element. The UA MUST insert the hostname/port of the 455 remote session description into the remote-host-port element, if the 456 remote session description is available to the UA. If not, the UA 457 generates a stream element that only contains the local-host-port 458 element. 460 This element MAY have the following attributes (see Section 3.3): 461 direction, label. 463 The label attribute is used to identify a specific media stream in a 464 session description. The value of the label attribute is a token. 465 The token can be chosen freely, however, it MUST be unique among all 466 element in a session-info document. If a label attribute 467 [RFC4574] is present in the SDP description, its value MUST be 468 carried over to the label attribute of the corresponding 469 element. 471 The element MUST contain one element, one or 472 more elements and one element. The 473 element MAY contain one element. 475 6.3.1.1. The Element 477 The element contains the hostname or IP address and 478 the port number of the media stream in the local session description. 479 The hostname or IP address is separated from the port by a ":". An 480 example is: "host.example.com:49562". 482 The hostname or IP address of element is found in the c= element for 483 the stream in the local SDP description. The port number is found in 484 the m= element. 486 6.3.1.2. The Element 488 The element is structured exactly as the element. However, it identifies the hostname or IP 490 address and port number of the media stream in the remote session 491 description. 493 6.4. The Element 495 The element defines the overall maximum bandwidth in 496 kilobits per second an entity can/will use for media streams at any 497 point in time. It defines an upper limit for the total bandwidth an 498 entity can/will use for the transmission of media streams. The limit 499 corresponds to the sum of the maximum session bandwidth of all 500 sessions a UA may set up in parallel. 502 The bandwidth limit given in the element includes the 503 bandwidth needed for lower-layer transport and network protocols 504 (e.g., UDP and IP). 506 The element MAY have the following attribute (see 507 Section 3.3): direction. 509 If used in a element, the element MAY have 510 the following additional attribute (see Section 3.3): visibility. 512 If the element occurs multiple times in a container element, 513 each instance MUST apply to a different set of media streams (i.e., 514 one element for outgoing and one for incoming streams). 516 Merging of session-policy documents: the lowest max-bw value is 517 used. 519 6.5. The Element 521 The element defines the maximum bandwidth in 522 kilobits per second an entity can/will use for media streams in the 523 described session. It defines an upper limit for the total bandwidth 524 of a single session. This limit corresponds to the sum of the 525 maximum stream bandwidth of all media streams in a session. 527 The bandwidth limit given in the element includes 528 the bandwidth needed for lower-layer transport and network protocols 529 (e.g., UDP and IP). 531 The value of the element is equivalent to the CT 532 bandwidth in the b= line of an SDP [RFC4566] announcement. 534 The element MAY have the following attribute (see 535 Section 3.3): direction. 537 If used in a element, the element 538 MAY have the following additional attribute (see Section 3.3): 539 visibility. 541 If the element occurs multiple times in a container 542 element, each instance MUST apply to a different set of media streams 543 (i.e., one element for outgoing and one for incoming 544 streams). 546 Merging of session-policy documents: the lowest max-session-bw 547 value is used. 549 6.6. The Element 551 The element defines the maximum bandwidth in kilobits 552 per second an entity can/will use for each media stream in the 553 described session. 555 The bandwidth limit given in the element includes the 556 bandwidth needed for lower-layer transport and network protocols 557 (e.g., UDP and IP). 559 The value of the element is equivalent to the AS 560 bandwidth in the b= line of an SDP [RFC4566] announcement. 562 The element MAY have the following attribute (see 563 Section 3.3): direction, media-type. 565 If used in a element, the element 566 MAY have the following additional attribute (see Section 3.3): 567 visibility. 569 If used in a element, the element MAY 570 have the following additional attribute: label. 572 The media-type attribute is used to define that the 573 element only applies to streams of a certain media type. For 574 example, it may only apply to audio streams. The value of the 575 'media-type' attribute MUST be the name of a IANA registered media 576 type (see RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 577 'application'. 579 The label attribute is used to define a bandwidth limit for a 580 specific media stream. The use of this attribute requires that the 581 element that represents the media stream to which this 582 bandwidth limit applies also has a label attribute. A 583 element with a label attribute applies only to the 584 stream element that has a label attribute with the same value. If no 585 matching element exists, then the element 586 MUST be ignored. 588 If the element occurs multiple times in a container 589 element, each instance MUST apply to a different set of media streams 590 (i.e., one element for outgoing and one for incoming 591 streams). 593 Merging of session-policy documents: the lowest max-stream-bw 594 value is used. 596 6.7. The Element 598 The element expresses a policy for routing a 599 media stream through a media intermediary. The purpose of the 600 element is to tell the UA to send a media 601 stream through one (or a chain of) media intermediaries. Instead of 602 sending the media directly to its final destination, the UA specifies 603 a source route, which touches each intermediary and then reaches the 604 final recipient. If there are N hops, including the final recipient, 605 there needs to be a way for the media stream to specify N 606 destinations. 608 The element is a container that lists all 609 media intermediaries to be traversed. Media intermediaries should be 610 traversed in the order in which they appear in this list. The 611 topmost entry should be traversed first, the last entry should be 612 traversed last. 614 Different types of intermediaries exist. These intermediaries are 615 not necessarily interoperable and it may not be possible to chain 616 them in an arbitrary order. A element SHOULD 617 therefore only contain intermediary elements of the same type. 619 This element MAY have the following attributes (see Section 3.3): 620 direction. 622 Multiple elements MAY only be present in a 623 container if each applies to a different set of streams (e.g., one 624 element for incoming and one for outgoing 625 streams). The element MUST contain one or 626 more elements defining a specific media intermediary, such as or . 629 Merging of session-policy documents: the intermediaries defined in 630 all policies are traversed. In general, local intermediaries 631 should be traversed before remote intermediaries. During the 632 merging process, element values from 633 different servers are ordered using the "Closest Value First 634 Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The 635 intermediaries should be traversed in this order. 637 Note: it is not intended that the element 638 replaces connectivity discovery mechanisms such as ICE. Instead 639 of finding media relays that provide connectivity, this element 640 defines a policy for media intermediaries that should be 641 traversed. The set of intermediaries defined in the element and the ones discovered through ICE may 643 overlap but don't have to. 645 6.7.1. The Element 647 A fixed intermediary relies on pre-configured forwarding rules. The 648 user agent simply sends media to the first media intermediary listed. 649 It can assume that this media intermediary has been pre-configured 650 with a forwarding rule for the media stream and knows where to 651 forward the packets to. The configuration of forwarding rules in the 652 intermediary must be done through other means. 654 The contents of a element MUST be echoed to all 655 policy servers that provide policies for a session. I.e., if 656 multiple policy servers provide policies for the same session, this 657 element needs to be forwarded to all of them, possibly in a second 658 round of session-specific policy subscriptions as described in 659 [I-D.ietf-sip-session-policy-framework] in section Contacting the 660 Policy Server. 662 The element MUST contain one 663 element and MAY contain multiple optional elements. 665 6.7.1.1. The Element 667 The element contains the hostname or IP address and 668 port number of a media intermediary. The UA uses this hostname/IP 669 address and port to send its media streams to the intermediary. The 670 hostname or IP address is separated from the port by a ":". 672 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 673 port number SHOULD be included in the element. All 674 additional port numbers SHOULD be identified in 675 elements. 677 6.7.1.2. The Element 679 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 680 port number SHOULD be included in the element. All 681 additional port numbers SHOULD be identified in 682 elements. 684 6.7.2. The Element 686 The TURN [I-D.ietf-behave-turn] protocol provides a mechanism for 687 inserting a relay into the media path. Although the main purpose of 688 TURN is NAT traversal, it is possible for a TURN relay to perform 689 other media intermediary functionalities. The user agent establishes 690 a binding on the TURN server and uses this binding to transmit and 691 receive media. 693 The element MUST contain one 694 element and MAY contain multiple optional elements 695 and zero or one each of the , , and 696 elements. If no element is present, UDP is assumed. 698 6.7.2.1. The Element 700 The element contains the shared secret needed to 701 authenticate at the media intermediary. 703 6.7.2.2. The element 705 The element contains the user ID needed to authenticate to the 706 media intermediary. 708 6.7.2.3. The Element 710 The element contains the name of the transport to be used 711 for communicating with the TURN server. This document defines the 712 values "tcp" and "udp" for use in the element. Other 713 specifications may define additional values. 715 6.7.3. The Element 717 The MSRP Relay Extensions [RFC4976] define a means for incorporating 718 relays into the media path of an MSRP [RFC4975] session. MSRP is 719 explicitly designed for a variety of purposes, including policy 720 enforcement. 722 The element MUST contain one element, 723 and may contain zero or one each of the and 724 elements. 726 6.7.3.1. The Element 728 The element contains a URI that indicates the MSRP server 729 to use for an intermediary. The UA uses this URI to authenticate 730 with the MSRP relay, and then uses the URI it learns through that 731 authentication process for any MSRP media it sends or receives. Only 732 URIs with a scheme of "msrps:" are valid in the element. 734 6.8. The Element 736 The element contains an Differentiated Services Codepoint 737 (DSCP) [RFC2474] value that should be used to populate the IP DS 738 field of media packets. The contains an integer value 739 that represents a 6 bit field and therefore ranges from 0 to 63. 741 This element MAY have the following attributes (see Section 3.3): 742 direction, media-type. 744 If used in a element, the element MAY 745 have the following additional attribute (see Section 3.3): 746 visibility. 748 The media-type attribute is used to define that element 749 only applies to streams of a certain media type. For example, it may 750 only apply to audio streams. The value of the 'media-type' attribute 751 MUST be the name of a IANA registered media type (see RFC4566 752 [RFC4566]), such as 'audio', 'video', 'text', or 'application'. 754 The element is optional and MAY occur multiple times 755 inside a container. If the element occurs multiple times, 756 each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). 759 Merging of session-policy documents: the domain that is first 760 traversed by the media stream has precedence and its DSCP value is 761 used. During the merging process, element values from 762 different servers are ordered using the "Closest Value First 763 Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The DSCP 764 value from the closest server is used. 766 6.9. The Element 768 Domains often require that a user agent only uses ports in a certain 769 range for media streams. The element defines a policy 770 for the ports a user agent can use for media. The value of this 771 element consists of a start port and an end port separated by a "-". 772 The start/end port is the first/last port that can be used. 774 This element MAY have the following attributes (see Section 3.3): 775 visibility. 777 The element is only defined for session policy 778 documents (i.e., in a container). 780 Merging of session-policy documents: the domain that is first 781 traversed by the media stream has precedence and its local ports 782 value is used. During the merging process, element 783 values from different servers are ordered using the "Closest Value 784 First Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The 785 value from the closest server is used. 787 6.10. The Element 789 The element provides context information about a session 790 policy or session information document. 792 The element MAY contain multiple and one 793 element. 795 If used in a element, the element MAY also 796 contain a element. 798 If used in a element, the element MAY also 799 contain a and a element. 801 Merging of session-policy documents: the element is not 802 subject to merging. 804 6.10.1. The Element 806 The element contains the URI of the policy server 807 that has issued this policy. 809 The element is only defined inside a element. 812 6.10.2. The Element 814 The element contains a contact address (e.g., a SIP URI or 815 email address) under which the issuer of this document can be 816 reached. 818 6.10.3. The Element 820 The element provides a short textual description of the policy 821 or session that should be intelligible to the human user. 823 6.10.4. The Element 825 The element identifies the request-URI the dialog 826 initiating request of a session is sent to. 828 The element is only defined inside a 829 element. 831 6.10.5. The Element 833 The element provides a mechanism for a policy server to 834 return an opaque token to a UA. This is sometimes needed to ensure 835 that all requests for a session are routed to the same policy server. 836 The use of this token is described in the Framework for SIP Session 837 Policies [I-D.ietf-sip-session-policy-framework]. 839 The element is only defined inside a element. 841 6.11. Other Session Properties 843 A number of additional elements have been proposed for a media 844 property language. These elements are deemed to be outside the scope 845 of this format. However, they may be defined in extensions of MPDF 846 or other profile data sets. 848 o maximum number of streams 849 o maximum number of sessions 850 o maximum number of streams per session 851 o external address and port 852 o media transport protocol 853 o outbound proxy 854 o SIP methods 855 o SIP option tags 856 o SIP transport protocol 857 o body disposition 858 o body format 859 o body encryption 861 7. Examples 863 7.1. Session Policy Documents 865 The following example describes a session policy document that allows 866 the use of audio and video and prohibits the use of other media 867 types. It allows the use of any codec except G.723 and G.729. 869 870 871 872 policy@biloxi.example.com 873 sip:policy_manager@example.com 874 Access network policies 875 876 877 audio 878 video 879 880 881 882 audio/G729 883 884 885 audio/G723 886 887 888 889 891 7.2. Session Information Documents 893 The following examples contain session descriptions and the session 894 information documents that represent these sessions. 896 7.2.1. Example 1 898 In this example, a session info document is created based on one 899 session description. This session info document would be created, 900 for example, by a UA that has composed an offer and is now contacting 901 a policy server. 903 Local SDP session description: 905 v=0 906 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 907 s= 908 c=IN IP4 host.somewhere.example 909 t=0 0 910 m=audio 49562 RTP/AVP 0 1 3 911 a=rtpmap:0 PCMU/8000 912 a=rtpmap:1 1016/8000 913 a=rtpmap:3 GSM/8000 914 m=video 51234 RTP/AVP 31 34 915 a=rtpmap:31 H261/90000 916 a=rtpmap:34 H263/90000 917 MPDF document: 919 920 921 922 sip:alice@somewhere.example 923 session information 924 925 926 927 audio 928 audio/PCMU 929 audio/1016 930 audio/GSM 931 host.somewhere.example:49562 932 933 934 video 935 video/H261 936 video/H263 937 host.somewhere.example:51234 938 939 940 941 943 7.2.2. Example 2 945 In this example, a session info document is created that represents 946 two session descriptions (i.e., an offer and answer). This session 947 info document would be created, for example, by a UA that has 948 received an answer from another UA and is now contacting a policy 949 server. 951 Local SDP session description: 953 v=0 954 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 955 s= 956 c=IN IP4 host.somewhere.example 957 t=0 0 958 m=audio 49562 RTP/AVP 0 1 3 959 a=rtpmap:0 PCMU/8000 960 a=rtpmap:1 1016/8000 961 a=rtpmap:3 GSM/8000 962 m=video 51234 RTP/AVP 31 34 963 a=rtpmap:31 H261/90000 964 a=rtpmap:34 H263/90000 965 Remote SDP session description: 967 v=0 968 o=bob 2890844730 2890844730 IN IP4 host.anywhere.example 969 s= 970 c=IN IP4 host.anywhere.example 971 t=0 0 972 m=audio 52124 RTP/AVP 0 3 973 a=rtpmap:0 PCMU/8000 974 a=rtpmap:3 GSM/8000 975 m=video 50286 RTP/AVP 31 976 a=rtpmap:31 H261/90000 978 MPDF document that represents the local and the remote session 979 description: 981 982 983 984 sip:alice@somewhere.example 985 session information 986 987 988 989 audio 990 audio/PCMU 991 audio/GSM 992 host.somewhere.example:49562 993 host.anywhere.example:52124 994 995 996 video 997 video/H261 998 host.somewhere.example:51234 999 host.anywhere.example:50286 1000 1001 1002 1003 1005 The following MPDF document is a modified version of the above 1006 document, which can be returned by a policy server. This document 1007 reflects a policy that defines a maximum session bandwidth of 192 1008 kbit and a maximum bandwidth for the H261 video stream of 128 kbit. 1010 1011 1012 1013 sip:alice@somewhere.example 1014 modified session information 1015 1016 1017 1018 audio 1019 audio/PCMU 1020 audio/GSM 1021 host.somewhere.example:49562 1022 host.anywhere.example:52124 1023 1024 1025 video 1026 video/H261 1027 host.somewhere.example:51234 1028 host.anywhere.example:50286 1029 1030 1031 128 1032 192 1033 1034 1036 8. Relax NG Definition 1038 TBD: This relax NG definition needs to be updated and aligned with 1039 [I-D.ietf-sipping-profile-datasets]. 1041 ?xml version="1.0"?> 1042 1046 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1201 1203 1204 1205 1206 1207 1208 1210 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1246 1247 1248 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1267 1268 1269 1270 1271 1272 1273 1274 1275 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1291 1292 1293 1294 1295 1296 1297 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1336 1337 1338 1339 1340 1342 1343 1344 1345 1346 1348 1350 9. Security Considerations 1352 Session policy information can be sensitive information. The 1353 protocol used to distribute session policy information SHOULD ensure 1354 privacy, message integrity and authentication. Furthermore, the 1355 protocol SHOULD provide access controls which restrict who can see 1356 who else's session policy information. 1358 10. IANA Considerations 1360 This document registers a new MIME type, application/ 1361 media-policy-dataset+xml, and a new XML namespace. 1363 10.1. MIME Registration 1365 MIME media type name: application 1367 MIME subtype name: media-policy-dataset+xml 1369 Mandatory parameters: none 1371 Optional parameters: Same as charset parameter application/xml as 1372 specified in RFC 3023 [RFC3023]. 1374 Encoding considerations: Same as encoding considerations of 1375 application/xml as specified in RFC 3023 [RFC3023]. 1377 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1378 Section 9 of this specification. 1380 Interoperability considerations: none. 1382 Published specification: This document. 1384 Applications which use this media type: This document type has been 1385 used to convey media policy information between SIP user agents and a 1386 domain. 1388 Additional Information: 1390 Magic Number: None 1392 File Extension: .mpf or .xml 1393 Macintosh file type code: "TEXT" 1395 Personal and email address for further information: Volker Hilt, 1396 1398 Intended usage: COMMON 1400 Author/Change controller: The IETF. 1402 10.2. URN Sub-Namespace Registration 1404 This section registers a new XML namespace, as per the guidelines in 1405 [RFC3688] 1407 URI: The URI for this namespace is 1408 urn:ietf:params:xml:ns:mediadataset. 1410 Registrant Contact: IETF, SIPPING working group, , 1411 Volker Hilt, 1413 XML: 1415 BEGIN 1416 1417 1419 1420 1421 1423 Media Policy Dataset Namespace 1424 1425 1426

Namespace for Media Policy Datasets

1427

urn:ietf:params:xml:ns:mediadataset

1428

See RFCXXXX.

1429 1430 1431 END 1433 11. References 1435 11.1. Normative References 1437 [I-D.ietf-behave-turn] 1438 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1439 Relays around NAT (TURN): Relay Extensions to Session 1440 Traversal Utilities for NAT (STUN)", 1441 draft-ietf-behave-turn-13 (work in progress), 1442 February 2009. 1444 [I-D.ietf-sipping-profile-datasets] 1445 Dolly, M., Channabasappa, S., Ganesan, S., and V. Hilt, "A 1446 Schema and Guidelines for Defining Session Initiation 1447 Protocol User Agent Profile Datasets", 1448 draft-ietf-sipping-profile-datasets-02 (work in progress), 1449 October 2008. 1451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1452 Requirement Levels", BCP 14, RFC 2119, March 1997. 1454 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1456 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1457 "Definition of the Differentiated Services Field (DS 1458 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1459 December 1998. 1461 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1462 Types", RFC 3023, January 2001. 1464 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1465 with Session Description Protocol (SDP)", RFC 3264, 1466 June 2002. 1468 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1469 January 2004. 1471 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1472 Description Protocol", RFC 4566, July 2006. 1474 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1475 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1477 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1478 Formats", RFC 4855, February 2007. 1480 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1481 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1483 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1484 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1485 September 2007. 1487 [W3C.REC-xml-20040204] 1488 Paoli, J., Maler, E., Bray, T., Sperberg-McQueen, C., and 1489 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1490 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1491 20040204, February 2004, 1492 . 1494 [W3C.REC-xml-names-19990114] 1495 Layman, A., Hollander, D., and T. Bray, "Namespaces in 1496 XML", World Wide Web Consortium FirstEdition REC-xml- 1497 names-19990114, January 1999, 1498 . 1500 11.2. Informative References 1502 [I-D.ietf-sip-session-policy-framework] 1503 Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework 1504 for Session Initiation Protocol (SIP) Session Policies", 1505 draft-ietf-sip-session-policy-framework-05 (work in 1506 progress), November 2008. 1508 [I-D.ietf-sipping-config-framework] 1509 Channabasappa, S., "A Framework for Session Initiation 1510 Protocol User Agent Profile Delivery", 1511 draft-ietf-sipping-config-framework-15 (work in progress), 1512 February 2008. 1514 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1515 August 1999. 1517 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1518 A., Peterson, J., Sparks, R., Handley, M., and E. 1519 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1520 June 2002. 1522 [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. 1523 Even, "RTP Payload Format for ITU-T Rec", RFC 4629, 1524 January 2007. 1526 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 1527 the RTP Profile for Audio and Video Conferences", 1528 RFC 4856, February 2007. 1530 Appendix A. Acknowledgements 1532 Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach 1533 and Ben Campbell for the discussions and suggestions. Many thanks to 1534 Roni Even and Mary Barnes for reviewing the draft and to Jari 1535 Urpalainen for helping with the Relax NG schema. 1537 Authors' Addresses 1539 Volker Hilt 1540 Bell Labs/Alcatel-Lucent 1541 791 Holmdel-Keyport Rd 1542 Holmdel, NJ 07733 1543 USA 1545 Email: volkerh@bell-labs.com 1547 Gonzalo Camarillo 1548 Ericsson 1549 Hirsalantie 11 1550 Jorvas 02420 1551 Finland 1553 Email: Gonzalo.Camarillo@ericsson.com 1555 Jonathan Rosenberg 1556 Cisco 1557 Edison, NJ 1558 USA 1560 Email: jdrosen@cisco.com