idnits 2.17.1 draft-ietf-sipping-media-policy-dataset-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1541. 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 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 (July 12, 2008) is 5768 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-08 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-profile-datasets-01 ** 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-03 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-15 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: January 13, 2009 Ericsson 6 J. Rosenberg 7 Cisco 8 July 12, 2008 10 A User Agent Profile Data Set for Media Policy 11 draft-ietf-sipping-media-policy-dataset-06 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 13, 2009. 38 Abstract 40 This specification defines a document format for the media properties 41 of Session Initiation Protocol (SIP) sessions. Examples for media 42 properties are the codecs or media types used in a session. This 43 document format is based on XML and extends the Schema for SIP User 44 Agent Profile Data Sets. It can be used to describe the properties 45 of a specific SIP session or to define policies that are then applied 46 to different SIP sessions. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Namespace and MIME Type . . . . . . . . . . . . . . . . . 5 54 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 55 3.3. Inheritance from the Profile Data Set . . . . . . . . . . 6 56 4. Session Info Documents . . . . . . . . . . . . . . . . . . . . 6 57 4.1. The Element . . . . . . . . . . . . . . . . 7 58 4.2. Mapping SDP to Session Info Documents . . . . . . . . . . 7 59 5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 8 60 5.1. The Element . . . . . . . . . . . . . . . 8 61 6. Media Property Elements . . . . . . . . . . . . . . . . . . . 8 62 6.1. The Element . . . . . . . . . . . . . . . . 8 63 6.1.1. The Element . . . . . . . . . . . . . . . 9 64 6.2. The Element . . . . . . . . . . . . . . . . . . . 9 65 6.2.1. The Element . . . . . . . . . . . . . . . . . 10 66 6.3. The Element . . . . . . . . . . . . . . . . . . 10 67 6.3.1. The Element . . . . . . . . . . . . . . . . . 11 68 6.4. The Element . . . . . . . . . . . . . . . . . . . 12 69 6.5. The Element . . . . . . . . . . . . . . . 12 70 6.6. The Element . . . . . . . . . . . . . . . 13 71 6.7. The Element . . . . . . . . . . . . 14 72 6.7.1. The Element . . . . . . . . . . . 15 73 6.7.2. The Element . . . . . . . . . . . 16 74 6.8. The Element . . . . . . . . . . . . . . . . . . 16 75 6.9. The Element . . . . . . . . . . . . . . . . 17 76 6.10. The Element . . . . . . . . . . . . . . . . . . 17 77 6.10.1. The Element . . . . . . . . . . . . . . . . . 17 78 6.10.2. The Element . . . . . . . . . . . . . . . . 18 79 6.10.3. The Element . . . . . . . . . . . . . . . . . . 18 80 6.10.4. The Element . . . . . . . . . . . . . . 18 81 6.10.5. The Element . . . . . . . . . . . . . . . . . 18 82 6.11. Other Session Properties . . . . . . . . . . . . . . . . . 18 83 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 7.1. Session Policy Documents . . . . . . . . . . . . . . . . . 19 85 7.2. Session Information Documents . . . . . . . . . . . . . . 19 86 7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 87 7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 20 88 8. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 23 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 91 10.1. MIME Registration . . . . . . . . . . . . . . . . . . . . 30 92 10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 31 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 33 97 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 99 Intellectual Property and Copyright Statements . . . . . . . . . . 35 101 1. Introduction 103 The Framework for Session Initiation Protocol (SIP) [RFC3261] User 104 Agent Profile Delivery [I-D.ietf-sipping-config-framework] and the 105 Framework for SIP Session Policies 106 [I-D.ietf-sip-session-policy-framework] define mechanisms to convey 107 session policies and configuration information from a network server 108 to a user agent. An important piece of the information conveyed to 109 the user agent relates to the media properties of the SIP sessions 110 set up by the user agent. Examples for these media properties are 111 the codecs and media types used, the media-intermediaries to be 112 traversed or the maximum bandwidth available for media streams. 114 This specification defines a document format for media properties of 115 SIP sessions, the Media Policy Dataset Format (MPDF). This format 116 can be used in two ways: first, it can be used to describe the 117 properties of a given SIP session (e.g., the media types and codecs 118 used). These MPDF documents are called session info documents and 119 they are usually created based on the session description of a 120 session. Second, the MPDF format can be used to define policies for 121 SIP sessions in a session policy document. A session policy document 122 defines properties (e.g., the media types) that can or can not be 123 used in a session, independent of a specific session description. 125 If used with the Framework for SIP Session Policies 126 [I-D.ietf-sip-session-policy-framework], session info documents are 127 used in conjunction with session-specific policies. A session info 128 document is created by a UA based on the current session description 129 and submitted to the policy server. The policy server examines the 130 session info document, modifies it if necessary (e.g., by removing 131 video streams if video is not permitted) and returns the possibly 132 modified session info document to the UA. Session policy documents 133 on the other hand are used to describe session-independent policies 134 that can be submitted to the UA independent of a specific session. 136 The two types of MPDF documents, session information and session 137 policy documents, share the same set of XML elements to describe 138 session properties. Since the usage of these elements differs 139 between the two document types, they both use different root 140 elements: is the root element for session information 141 documents and is the root element for session policy 142 documents. This enables the recipient of a document to determine the 143 document type and to correctly interpret the media properties 144 defined. 146 A user agent can receive multiple session policy documents from 147 different sources. These documents need to be merged into a single 148 document the user agent can work with. This document specifies rules 149 for merging each of the XML elements defined. It should be noted 150 that these merging rules are part of the semantics of the XML 151 element. User agents implement the merging rules as part of 152 implementing the element semantics. As a consequence, it is not 153 possible to build an entity that can mechanically merge two session 154 policy documents without understanding the semantics of all elements 155 in the input documents. The Schema for SIP User Agent Profile Data 156 Sets [I-D.ietf-sipping-profile-datasets] describes common merging 157 rules that are referred to in this specification. 159 Merging is not needed for session information documents since they 160 are created by one source and describe a specific session. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 3. Design Considerations 170 This section discusses design considerations for the Media Policy 171 Dataset Format. 173 3.1. Namespace and MIME Type 175 The MPDF format is based on XML [W3C.REC-xml-20040204]. A MPDF 176 document MUST be well-formed and MUST be valid according to schemas, 177 including extension schemas, available to the validator and 178 applicable to the XML document. MPDF documents MUST be based on XML 179 1.0 and MUST be encoded using UTF-8. 181 MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The 182 namespace URIs for schemas defined in this specification are URNs 183 [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] 184 and extended by [RFC3688]. The namespace URN for the MPDF schema is: 186 urn:ietf:params:xml:ns:mediadataset 188 The MIME type for the Media Policy Dataset Format is: 190 application/media-policy-dataset+xml 192 3.2. Extensibility 194 The MPDF format extends the Schema for SIP User Agent Profile Data 195 Sets [I-D.ietf-sipping-profile-datasets] by specifying a data set for 196 media properties. Elements from the MPDF namespace can be used in 197 conjunction with elements from other extensions of this schema. 199 The MPDF format itself can also be extended using XML extension 200 mechanisms if additional media properties are needed. In particular, 201 elements from different XML namespaces MAY be present within a MPDF 202 document for the purposes of extensibility; elements or attributes 203 from unknown namespaces MUST be ignored. 205 3.3. Inheritance from the Profile Data Set 207 The MPDF format inherits the following attributes from the Profile 208 Data Set Schema [I-D.ietf-sipping-profile-datasets]: 210 o Property Access Control: 'visibility' attribute 211 o Policies: 'policy' and 'excluded-policy' attribute 212 o Unidirectional Properties: 'direction' attribute 213 o Preferences: 'q' attribute 215 The use of these attributes is defined individually for each element 216 in the XML format below. 218 The MPDF format also uses merging algorithms that are defined in the 219 Profile Data Set Schema. The use of these algorithms is defined 220 individually for each element in the XML format below. 222 4. Session Info Documents 224 Session info documents describe key properties of a SIP session such 225 as the media streams used in the session. Session info documents are 226 typically created based on an SDP [RFC4566] session description or an 227 SDP offer/answer pair [RFC3264]. 229 Session info documents can be used for session-specific policies 230 [I-D.ietf-sip-session-policy-framework]. In this usage, a UA creates 231 a session info document based on its SDP description(s) and sends 232 this document to the policy server. The policy server modifies this 233 document according to the policies that apply to the described 234 session and returns a version of the session info document that is 235 compliant to all policies. For example, if video streams are not 236 permissible under current policies and the UA submits a session info 237 document that contains a video stream, the policy server will remove 238 the video stream from the XML markup and return the modified session 239 info document to the UA. 241 Session info documents use the element. 243 A policy server can completely reject a session by returning an 244 session info document with an empty element: 246 <\session-info> 248 4.1. The Element 250 The element describes the properties of a specific SIP 251 session. The element MAY occur multiple times inside 252 a [I-D.ietf-sipping-profile-datasets] element. 254 The element MAY contain one optional , 255 and multiple (including zero) , , 256 , and elements as 257 well as elements from other namespaces. The MPDF elements are 258 defined in Section 6. 260 4.2. Mapping SDP to Session Info Documents 262 If a UA has an SDP offer as well as an answer [RFC3264] and wants to 263 create a session info document, the UA MUST use the answer to fill in 264 the elements of the session info document except for the remote-host- 265 port and local-host-port elements, which are taken from the remote 266 and local session description respectively. The local session 267 description is the one created locally by the UA (i.e., the offer if 268 the UA has initiated the offer/answer exchange). The remote session 269 description is the one received from the remote UA. 271 The following rules describe the creation of session info documents 272 based on SDP description(s) for a few exemplary elements. Other 273 elements are created following the same principles. 275 A UA MUST create a separate element for each m= line in an 276 SDP description. The UA MUST insert the media type from the m= line 277 into a element and MUST create a element for 278 each codec listed in the m= line. 280 The UA MUST create a element for each stream using 281 the port taken from the m= line and the address from the 282 corresponding c= line of the local session description. The UA MUST 283 create a element using the port and address from 284 the m= and c= lines for the same stream taken from the remote session 285 description if this session description is available. 287 The mapping from a session info document to a SDP description follows 288 the same rules in the reverse direction. 290 5. Session Policy Documents 292 Session policy documents describe a policy for SIP sessions. Session 293 policy documents are independent of a specific session description 294 and express general policies for SIP sessions. A session policy 295 document is used to determine if a SIP session is policy conformant 296 and to modify this session, if needed, according to the described 297 policies. 299 Session policy documents can be used to encode session-independent 300 policies [I-D.ietf-sip-session-policy-framework]. In this usage, a 301 policy server creates a session policy document and passes this 302 document to a UA. The UA applies the policies defined to the SIP 303 sessions it is establishing. For example, a session policy document 304 can contain an element that prohibits the use of video. To set up a 305 session that is compliant to this policy, a UA does not include the 306 media type video in its SDP offer or answer. 308 Session policy documents use the element. 310 5.1. The Element 312 The element describes a policy that applies to SIP 313 sessions. The element MAY occur multiple times 314 inside a [I-D.ietf-sipping-profile-datasets] element. 316 The element MAY contain one optional and 317 element and multiple (including zero) , 318 , , , and 319 elements as well as elements from other namespaces. The MPDF 320 elements are defined in Section 6. 322 6. Media Property Elements 324 This section describes XML elements that are used in session info and 325 session policy documents to encode the media properties of SIP 326 sessions. 328 6.1. The Element 330 The element is a container that is used to define the 331 set of media types (e.g., audio, video) that can or cannot be used in 332 a session. A specific media type is included in the set by adding 333 the corresponding element to this container. 335 The element can only be used in session policy document 336 (i.e., inside the container). 338 This element MAY have the following attributes (see Section 3.3): 339 direction, visibility, excluded-policy. 341 Multiple elements MAY only be present in a container 342 element if each applies to a different set of streams (e.g., one 343 element for incoming and one for outgoing streams). 344 The element MUST contain one or more 345 elements. 347 Merging of session-policy documents: containers are 348 merged using the "Multiple Enumerated Value Merging Algorithm" 349 [I-D.ietf-sipping-profile-datasets]. 351 6.1.1. The Element 353 The element identifies a specific media type. The value 354 of this element MUST be the name of a IANA registered media type (see 355 RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 356 'application'. 358 This element MAY have the following attribute (see Section 3.3): q. 360 If used inside a element, this element MAY have the 361 following additional attribute (see Section 3.3): policy. Media 362 types that have the policy 'allowed' MAY be used and media types with 363 the policy 'disallowed' MUST NOT be used. 365 6.2. The Element 367 The element is a container that is used to define the set of 368 codecs that may or may not be used in a session. A policy MUST allow 369 the use of at least one codec per media type. A specific codec is 370 included in the set by adding the corresponding element to 371 this container. 373 The element can only be used in a session policy document 374 (i.e., inside the container). 376 The element MAY have the following attributes (see 377 Section 3.3): direction, visibility, excluded-policy. 379 Multiple elements MAY only be present in a container element 380 if each applies to a different set of streams (e.g., one 381 element for incoming and one for outgoing streams). The 382 element MUST contain one or more elements. 384 Merging of session-policy documents: containers are 385 merged using the "Multiple Enumerated Value Merging Algorithm" 386 [I-D.ietf-sipping-profile-datasets]. 388 6.2.1. The Element 390 The element identifies a specific codec. The content of this 391 element MUST be a registered MIME type [RFC4855] using media type and 392 subtype (e.g., audio/PCMA [RFC4856] or video/H263 [RFC4629]) and 393 possibly additional registered MIME type parameters. 395 The element MAY have the following attribute (see 396 Section 3.3): q. 398 If used inside a element, the element MAY 399 have the following additional attribute (see Section 3.3): policy. 400 Codecs that have the policy 'allowed' MAY be used and codecs with the 401 policy 'disallowed' MUST NOT be used. 403 The element MUST contain one element and MAY 404 contain multiple optional elements. 406 6.2.1.1. The Element 408 The element contains a MIME type that identifies a codec. 409 The value of this element MUST be a combination of a registered MIME 410 media type and subtype [RFC4855] separated by a "/" (e.g., audio/ 411 PCMA, audio/G726-16 [RFC4856] or video/H263 [RFC4629]). 413 6.2.1.2. The Element 415 The element may be needed for some codecs to 416 identify a particular encoding or profile. The value of this element 417 MUST be a name-value pair containing the name and the value of a 418 registered MIME type parameter for the codec [RFC4855]. The name and 419 value are separated by a "=". For example, the parameter "profile=0" 420 can be used to specify a specific profile for the codec "video/ 421 H263-2000" [RFC4629]. 423 6.3. The Element 425 The element is a container that is used to describe the 426 media streams used in a session. A element can contain 427 multiple elements. Each element describes the 428 properties (e.g., media type, codecs and IP addresses and ports) of a 429 single media stream. 431 The element is only defined for session information 432 documents (i.e., in a container). 434 The element MUST contain one or more elements. 436 6.3.1. The Element 438 The element describes a specific media stream. It contains 439 the media type, codecs and the hostname(s) or IP address(es) and 440 port(s) of this stream. 442 The hostname(s) or IP address(es) and port number(s) of a stream 443 correspond to the ones listed in the session description(s). A UA 444 that generates element MUST insert the hostname/port found 445 in the local session description for this media stream into the 446 local-host-port element. The UA MUST insert the hostname/port of the 447 remote session description into the remote-host-port element, if the 448 remote session description is available to the UA. If not, the UA 449 generates a stream element that only contains the local-host-port 450 element. 452 This element MAY have the following attributes (see Section 3.3): 453 direction, label. 455 The label attribute is used to identify a specific media stream in a 456 session description. The value of the label attribute is a token. 457 The token can be chosen freely, however, it MUST be unique among all 458 element in a session-info document. If a label attribute 459 [RFC4574] is present in the SDP description, its value MUST be 460 carried over to the label attribute of the corresponding 461 element. 463 The element MUST contain one element, one or 464 more elements and one element. The 465 element MAY contain one element. 467 6.3.1.1. The Element 469 The element contains the hostname or IP address and 470 the port number of the media stream in the local session description. 471 The hostname or IP address is separated from the port by a ":". An 472 example is: "host.example.com:49562". 474 The hostname or IP address of element is found in the c= element for 475 the stream in the local SDP description. The port number is found in 476 the m= element. 478 6.3.1.2. The Element 480 The element is structured exactly as the element. However, it identifies the hostname or IP 482 address and port number of the media stream in the remote session 483 description. 485 6.4. The Element 487 The element defines the overall maximum bandwidth in 488 kilobits per second an entity can/will use for media streams at any 489 point in time. It defines an upper limit for the total bandwidth an 490 entity can/will use for the transmission of media streams. The limit 491 corresponds to the sum of the maximum session bandwidth of all 492 sessions a UA may set up in parallel. 494 The bandwidth limit given in the element includes the 495 bandwidth needed for lower-layer transport and network protocols 496 (e.g., UDP and IP). 498 The element MAY have the following attribute (see 499 Section 3.3): direction. 501 If used in a element, the element MAY have 502 the following additional attribute (see Section 3.3): visibility. 504 If the element occurs multiple times in a container element, 505 each instance MUST apply to a different set of media streams (i.e., 506 one element for outgoing and one for incoming streams). 508 Merging of session-policy documents: the lowest max-bw value is 509 used. 511 6.5. The Element 513 The element defines the maximum bandwidth in 514 kilobits per second an entity can/will use for media streams in the 515 described session. It defines an upper limit for the total bandwidth 516 of a single session. This limit corresponds to the sum of the 517 maximum stream bandwidth of all media streams in a session. 519 The bandwidth limit given in the element includes 520 the bandwidth needed for lower-layer transport and network protocols 521 (e.g., UDP and IP). 523 The value of the element is equivalent to the CT 524 bandwidth in the b= line of an SDP [RFC4566] annoncement. 526 The element MAY have the following attribute (see 527 Section 3.3): direction. 529 If used in a element, the element 530 MAY have the following additional attribute (see Section 3.3): 531 visibility. 533 If the element occurs multiple times in a container 534 element, each instance MUST apply to a different set of media streams 535 (i.e., one element for outgoing and one for incoming 536 streams). 538 Merging of session-policy documents: the lowest max-session-bw 539 value is used. 541 6.6. The Element 543 The element defines the maximum bandwidth in kilobits 544 per second an entity can/will use for each media stream in the 545 described session. 547 The bandwidth limit given in the element includes the 548 bandwidth needed for lower-layer transport and network protocols 549 (e.g., UDP and IP). 551 The value of the element is equivalent to the AS 552 bandwidth in the b= line of an SDP [RFC4566] annoncement. 554 The element MAY have the following attribute (see 555 Section 3.3): direction, media-type. 557 If used in a element, the element 558 MAY have the following additional attribute (see Section 3.3): 559 visibility. 561 If used in a element, the element MAY 562 have the following additional attribute: label. 564 The media-type attribute is used to define that the 565 element only applies to streams of a certain media type. For 566 example, it may only apply to audio streams. The value of the 567 'media-type' attribute MUST be the name of a IANA registered media 568 type (see RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 569 'application'. 571 The label attribute is used to define a bandwidth limit for a 572 specific media stream. The use of this attribute requires that the 573 element that respresents the media stream to which this 574 bandwidth limit applies also has a label attribute. A 575 element with a label attribute applies only to the 576 stream element that has a label attribute with the same value. If no 577 matching element exists, then the element 578 MUST be ignored. 580 If the element occurs multiple times in a container 581 element, each instance MUST apply to a different set of media streams 582 (i.e., one element for outgoing and one for incoming 583 streams). 585 Merging of session-policy documents: the lowest max-stream-bw 586 value is used. 588 6.7. The Element 590 The element expresses a policy for routing a 591 media stream through a media intermediary. The purpose of the 592 element is to tell the UA to send a media 593 stream through one (or a chain of) media intermediaries. Instead of 594 sending the media directly to its final destination, the UA specifies 595 a source route, which touches each intermediary and then reaches the 596 final recipient. If there are N hops, including the final recipient, 597 there needs to be a way for the media stream to specify N 598 destinations. 600 The element is a container that lists all 601 media intermediaries to be traversed. Media intermediaries should be 602 traversed in the order in which they appear in this list. The 603 topmost entry should be traversed first, the last entry should be 604 traversed last. 606 Different types of intermediaries exist. These intermediaries are 607 not necessarily interoperable and it may not be possible to chain 608 them in an arbitrary order. A element SHOULD 609 therefore only contain intermediary elements of the same type. 611 This element MAY have the following attributes (see Section 3.3): 612 direction. 614 Multiple elements MAY only be present in a 615 container if each applies to a different set of streams (e.g., one 616 element for incoming and one for outgoing 617 streams). The element MUST contain one or 618 more of the following elements: and . 621 Merging of session-policy documents: the intermediaries defined in 622 all policies are traversed. In general, local intermediaries 623 should be traversed before remote intermediaries. During the 624 merging process, element values from 625 different servers are ordered using the "Closest Value First 626 Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The 627 intermediaries should be traversed in this order. 629 Note: it is not intended that the element 630 replaces connectivity discovery mechanisms such as ICE. Instead 631 of finding media relays that provide connectivity, this element 632 defines a policy for media intermediaries that should be 633 traversed. The set of intermediaries defined in the element and the ones discovered through ICE may 635 overlap but don't have to. 637 6.7.1. The Element 639 A fixed intermediary relies on pre-configured forwarding rules. The 640 user agent simply sends media to the first media intermediary listed. 641 It can assume that this media intermediary has been pre-configured 642 with a forwarding rule for the media stream and knows where to 643 forward the packets to. The configuration of forwarding rules in the 644 intermediary must be done through other means. 646 The element MUST contain one 647 element and MAY contain multiple optional elements. 649 6.7.1.1. The Element 651 The element contains the hostname or IP address and 652 port number of a media intermediary. The UA uses this hostname/IP 653 address and port to send its media streams to the intermediary. The 654 hostname or IP address is separated from the port by a ":". 656 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 657 port number SHOULD be included in the element. All 658 additional port numbers SHOULD be identified in 659 elements. 661 6.7.1.2. The Element 663 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 664 port number SHOULD be included in the element. All 665 additional port numbers SHOULD be identified in 666 elements. 668 6.7.2. The Element 670 The TURN [I-D.ietf-behave-turn] protocol provides a mechanism for 671 inserting a relay into the media path. Although the main purpose of 672 TURN is NAT traversal, it is possible for a TURN relay to perform 673 other media intermediary functionalities. The user agent establishes 674 a binding on the TURN server and uses this binding to transmit and 675 receive media. 677 The element MUST contain one 678 element and MAY contain multiple optional elements 679 and one optional element. 681 6.7.2.1. The Element 683 The element contains the shared secret needed to 684 authenticate at the TURN server. 686 6.8. The Element 688 The element contains an Differentiated Services Codepoint 689 (DSCP) [RFC2474] value that should be used to populate the IP DS 690 field of media packets. The contains an integer value 691 that represents a 6 bit field and therefore ranges from 0 to 63. 693 This element MAY have the following attributes (see Section 3.3): 694 direction, media-type. 696 If used in a element, the element MAY 697 have the following additional attribute (see Section 3.3): 698 visibility. 700 The media-type attribute is used to define that element 701 only applies to streams of a certain media type. For example, it may 702 only apply to audio streams. The value of the 'media-type' attribute 703 MUST be the name of a IANA registered media type (see RFC4566 704 [RFC4566]), such as 'audio', 'video', 'text', or 'application'. 706 The element is optional and MAY occur multiple times 707 inside a container. If the element occurs multiple times, 708 each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). 711 Merging of session-policy documents: the domain that is first 712 traversed by the media stream has precedence and its DSCP value is 713 used. During the merging process, element values from 714 different servers are ordered using the "Closest Value First 715 Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The DSCP 716 value from the closest server is used. 718 6.9. The Element 720 Domains often require that a user agent only uses ports in a certain 721 range for media streams. The element defines a policy 722 for the ports a user agent can use for media. The value of this 723 element consists of a start port and an end port separated by a "-". 724 The start/end port is the first/last port that can be used. 726 This element MAY have the following attributes (see Section 3.3): 727 visibility. 729 The element is only defined for session policy 730 documents (i.e., in a container). 732 Merging of session-policy documents: the domain that is first 733 traversed by the media stream has precedence and its local ports 734 value is used. During the merging process, element 735 values from different servers are ordered using the "Closest Value 736 First Merging Algorithm" [I-D.ietf-sipping-profile-datasets]. The 737 value from the closest server is used. 739 6.10. The Element 741 The element provides context information about a session 742 policy or session information document. 744 The element MAY contain multiple and one 745 element. 747 If used in a element, the element MAY also 748 contain a element. 750 If used in a element, the element MAY also 751 contain a and a element. 753 Merging of session-policy documents: the element is not 754 subject to merging. 756 6.10.1. The Element 758 The element contains a URI that identifies the domain which 759 has issued this policy. 761 The element is only defined inside a 762 element. 764 6.10.2. The Element 766 The element contains a contact address (e.g., a SIP URI or 767 email address) under which the issuer of this document can be 768 reached. 770 6.10.3. The Element 772 The element provides a short textual description of the policy 773 or session that should be intelligible to the human user. 775 6.10.4. The Element 777 The element identifies the request-URI the dialog 778 initiating request of a session is sent to. 780 The element is only defined inside a 781 element. 783 6.10.5. The Element 785 The element provides a mechanism for a policy server to 786 return an opaque token to a UA. This is sometimes needed to ensure 787 that all requests for a session are routed to the same policy server. 788 The use of this token is described in the Framework for SIP Session 789 Policies [I-D.ietf-sip-session-policy-framework]. 791 The element is only defined inside a element. 793 6.11. Other Session Properties 795 A number of additional elements have been proposed for a media 796 property language. These elements are deemed to be outside the scope 797 of this format. However, they may be defined in extensions of MPDF 798 or other profile data sets. 800 o maximum number of streams 801 o maximum number of sessions 802 o maximum number of streams per session 803 o external address and port 804 o media transport protocol 805 o outbound proxy 806 o SIP methods 807 o SIP option tags 808 o SIP transport protocol 809 o body disposition 810 o body format 811 o body encryption 813 7. Examples 815 7.1. Session Policy Documents 817 The following example describes a session policy document that allows 818 the use of audio and video and prohibits the use of other media 819 types. It allows the use of any codec except G.723 and G.729. 821 822 823 824 example.com 825 sip:policy_manager@example.com 826 Access network policies 827 828 829 audio 830 video 831 832 833 834 audio/G729 835 836 837 audio/G723 838 839 840 841 843 7.2. Session Information Documents 845 The following examples contain session descriptions and the session 846 information documents that represent these sessions. 848 7.2.1. Example 1 850 In this example, a session info document is created based on one 851 session description. This session info document would be created, 852 for example, by a UA that has composed an offer and is now contacting 853 a policy server. 855 Local SDP session description: 857 v=0 858 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 859 s= 860 c=IN IP4 host.somewhere.example 861 t=0 0 862 m=audio 49562 RTP/AVP 0 1 3 863 a=rtpmap:0 PCMU/8000 864 a=rtpmap:1 1016/8000 865 a=rtpmap:3 GSM/8000 866 m=video 51234 RTP/AVP 31 34 867 a=rtpmap:31 H261/90000 868 a=rtpmap:34 H263/90000 870 MPDF document: 872 873 874 875 sip:alice@somewhere.example 876 session information 877 878 879 880 audio 881 audio/PCMU 882 audio/1016 883 audio/GSM 884 host.somewhere.example:49562 885 886 887 video 888 video/H261 889 video/H263 890 host.somewhere.example:51234 891 892 893 894 896 7.2.2. Example 2 898 In this example, a session info document is created that represents 899 two session descriptions (i.e., an offer and answer). This session 900 info document would be created, for example, by a UA that has 901 received an answer from another UA and is now contacting a policy 902 server. 904 Local SDP session description: 906 v=0 907 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 908 s= 909 c=IN IP4 host.somewhere.example 910 t=0 0 911 m=audio 49562 RTP/AVP 0 1 3 912 a=rtpmap:0 PCMU/8000 913 a=rtpmap:1 1016/8000 914 a=rtpmap:3 GSM/8000 915 m=video 51234 RTP/AVP 31 34 916 a=rtpmap:31 H261/90000 917 a=rtpmap:34 H263/90000 919 Remote SDP session description: 921 v=0 922 o=bob 2890844730 2890844730 IN IP4 host.anywhere.example 923 s= 924 c=IN IP4 host.anywhere.example 925 t=0 0 926 m=audio 52124 RTP/AVP 0 3 927 a=rtpmap:0 PCMU/8000 928 a=rtpmap:3 GSM/8000 929 m=video 50286 RTP/AVP 31 930 a=rtpmap:31 H261/90000 932 MPDF document that represents the local and the remote session 933 description: 935 936 937 938 sip:alice@somewhere.example 939 session information 940 941 942 943 audio 944 audio/PCMU 945 audio/GSM 946 host.somewhere.example:49562 947 host.anywhere.example:52124 948 949 950 video 951 video/H261 952 host.somewhere.example:51234 953 host.anywhere.example:50286 954 955 956 957 959 The following MPDF document is a modified version of the above 960 document, which can be returned by a policy server. This document 961 reflects a policy that defines a maximum session bandwidth of 192 962 kbit and a maximum bandwidth for the H261 video stream of 128 kbit. 964 965 966 967 sip:alice@somewhere.example 968 modified session information 969 970 971 972 audio 973 audio/PCMU 974 audio/GSM 975 host.somewhere.example:49562 976 host.anywhere.example:52124 977 978 979 video 980 video/H261 981 host.somewhere.example:51234 982 host.anywhere.example:50286 983 984 985 128 986 192 987 988 990 8. Relax NG Definition 992 ?xml version="1.0"?> 993 997 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1160 1161 1162 1163 1164 1165 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1216 1217 1218 1219 1220 1221 1222 1223 1224 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1284 1285 1286 1287 1288 1290 1291 1292 1293 1294 1296 1298 9. Security Considerations 1300 Session policy information can be sensitive information. The 1301 protocol used to distribute session policy information SHOULD ensure 1302 privacy, message integrity and authentication. Furthermore, the 1303 protocol SHOULD provide access controls which restrict who can see 1304 who else's session policy information. 1306 10. IANA Considerations 1308 This document registers a new MIME type, application/ 1309 media-policy-dataset+xml, and a new XML namespace. 1311 10.1. MIME Registration 1313 MIME media type name: application 1315 MIME subtype name: media-policy-dataset+xml 1317 Mandatory parameters: none 1319 Optional parameters: Same as charset parameter application/xml as 1320 specified in RFC 3023 [RFC3023]. 1322 Encoding considerations: Same as encoding considerations of 1323 application/xml as specified in RFC 3023 [RFC3023]. 1325 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1326 Section 9 of this specification. 1328 Interoperability considerations: none. 1330 Published specification: This document. 1332 Applications which use this media type: This document type has been 1333 used to convey media policy information between SIP user agents and a 1334 domain. 1336 Additional Information: 1338 Magic Number: None 1340 File Extension: .mpf or .xml 1342 Macintosh file type code: "TEXT" 1344 Personal and email address for further information: Volker Hilt, 1345 1347 Intended usage: COMMON 1349 Author/Change controller: The IETF. 1351 10.2. URN Sub-Namespace Registration 1353 This section registers a new XML namespace, as per the guidelines in 1354 [RFC3688] 1356 URI: The URI for this namespace is 1357 urn:ietf:params:xml:ns:mediadataset. 1359 Registrant Contact: IETF, SIPPING working group, , 1360 Volker Hilt, 1362 XML: 1364 BEGIN 1365 1366 1368 1369 1370 1372 Media Policy Dataset Namespace 1373 1374 1375

Namespace for Media Policy Datasets

1376

urn:ietf:params:xml:ns:mediadataset

1377

See RFCXXXX.

1378 1379 1380 END 1382 11. References 1384 11.1. Normative References 1386 [I-D.ietf-behave-turn] 1387 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1388 Relays around NAT (TURN): Relay Extensions to Session 1389 Traversal Utilities for NAT (STUN)", 1390 draft-ietf-behave-turn-08 (work in progress), June 2008. 1392 [I-D.ietf-sipping-profile-datasets] 1393 Dolly, M., Channabasappa, S., Ganesan, S., and V. Hilt, "A 1394 Schema and Guidelines for Defining Session Initiation 1395 Protocol User Agent Profile Datasets", 1396 draft-ietf-sipping-profile-datasets-01 (work in progress), 1397 July 2008. 1399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1400 Requirement Levels", BCP 14, RFC 2119, March 1997. 1402 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1404 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1405 "Definition of the Differentiated Services Field (DS 1406 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1407 December 1998. 1409 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1410 Types", RFC 3023, January 2001. 1412 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1413 with Session Description Protocol (SDP)", RFC 3264, 1414 June 2002. 1416 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1417 January 2004. 1419 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1420 Description Protocol", RFC 4566, July 2006. 1422 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1423 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1425 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1426 Formats", RFC 4855, February 2007. 1428 [W3C.REC-xml-20040204] 1429 Maler, E., Bray, T., Sperberg-McQueen, C., Yergeau, F., 1430 and J. Paoli, "Extensible Markup Language (XML) 1.0 (Third 1431 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1432 20040204, February 2004, 1433 . 1435 [W3C.REC-xml-names-19990114] 1436 Layman, A., Hollander, D., and T. Bray, "Namespaces in 1437 XML", World Wide Web Consortium FirstEdition REC-xml- 1438 names-19990114, January 1999, 1439 . 1441 11.2. Informative References 1443 [I-D.ietf-sip-session-policy-framework] 1444 Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework 1445 for Session Initiation Protocol (SIP) Session Policies", 1446 draft-ietf-sip-session-policy-framework-03 (work in 1447 progress), April 2008. 1449 [I-D.ietf-sipping-config-framework] 1450 Channabasappa, S., "A Framework for Session Initiation 1451 Protocol User Agent Profile Delivery", 1452 draft-ietf-sipping-config-framework-15 (work in progress), 1453 February 2008. 1455 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1456 August 1999. 1458 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1459 A., Peterson, J., Sparks, R., Handley, M., and E. 1460 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1461 June 2002. 1463 [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. 1464 Even, "RTP Payload Format for ITU-T Rec", RFC 4629, 1465 January 2007. 1467 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 1468 the RTP Profile for Audio and Video Conferences", 1469 RFC 4856, February 2007. 1471 Appendix A. Acknowledgements 1473 Many thanks to Allison Mankin, Dan Petrie and Martin Dolly for the 1474 discussions and suggestions. Many thanks to Roni Even and Mary 1475 Barnes for reviewing the draft and to Jari Urpalainen for helping 1476 with the Relax NG schema. 1478 Authors' Addresses 1480 Volker Hilt 1481 Bell Labs/Alcatel-Lucent 1482 791 Holmdel-Keyport Rd 1483 Holmdel, NJ 07733 1484 USA 1486 Email: volkerh@bell-labs.com 1488 Gonzalo Camarillo 1489 Ericsson 1490 Hirsalantie 11 1491 Jorvas 02420 1492 Finland 1494 Email: Gonzalo.Camarillo@ericsson.com 1496 Jonathan Rosenberg 1497 Cisco 1498 Edison, NJ 1499 USA 1501 Email: jdrosen@cisco.com 1503 Full Copyright Statement 1505 Copyright (C) The IETF Trust (2008). 1507 This document is subject to the rights, licenses and restrictions 1508 contained in BCP 78, and except as set forth therein, the authors 1509 retain all their rights. 1511 This document and the information contained herein are provided on an 1512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1514 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1515 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1516 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1519 Intellectual Property 1521 The IETF takes no position regarding the validity or scope of any 1522 Intellectual Property Rights or other rights that might be claimed to 1523 pertain to the implementation or use of the technology described in 1524 this document or the extent to which any license under such rights 1525 might or might not be available; nor does it represent that it has 1526 made any independent effort to identify any such rights. Information 1527 on the procedures with respect to rights in RFC documents can be 1528 found in BCP 78 and BCP 79. 1530 Copies of IPR disclosures made to the IETF Secretariat and any 1531 assurances of licenses to be made available, or the result of an 1532 attempt made to obtain a general license or permission for the use of 1533 such proprietary rights by implementers or users of this 1534 specification can be obtained from the IETF on-line IPR repository at 1535 http://www.ietf.org/ipr. 1537 The IETF invites any interested party to bring to its attention any 1538 copyrights, patents or patent applications, or other proprietary 1539 rights that may cover technology that may be required to implement 1540 this standard. Please address the information to the IETF at 1541 ietf-ipr@ietf.org.