idnits 2.17.1 draft-ietf-sipping-media-policy-dataset-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 2010) is 5064 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-10) exists of draft-ietf-sip-session-policy-framework-07 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-17 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Alcatel-Lucent 4 Intended status: Standards Track D. Worley 5 Expires: December 14, 2010 Nortel Networks Corp. 6 G. Camarillo 7 Ericsson 8 J. Rosenberg 9 jdrosen.net 10 June 12, 2010 12 A User Agent Profile Data Set for Media Policy 13 draft-ietf-sipping-media-policy-dataset-10 15 Abstract 17 This specification defines a document format for the media properties 18 of Session Initiation Protocol (SIP) sessions. Examples for media 19 properties are the codecs or media types used in a session. This 20 document format is based on XML and can be used to describe the 21 properties of a specific SIP session or to define policies that are 22 then applied to SIP sessions. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 14, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Media Policy Dataset Format . . . . . . . . . . . . . . . . . 5 61 3.1. Namespace and MIME Type . . . . . . . . . . . . . . . . . 5 62 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3.1. The 'visibility' Attribute . . . . . . . . . . . . . . 6 65 3.3.2. The 'direction' Attributes . . . . . . . . . . . . . . 6 66 3.3.3. The 'q' Attribute . . . . . . . . . . . . . . . . . . 6 67 3.3.4. The 'label' Attribute . . . . . . . . . . . . . . . . 7 68 3.4. The Element . . . . . . . . . . . . . . . . 7 69 4. Session Info Documents . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Mapping SDP to Session Info Documents . . . . . . . . . . 8 71 4.2. The Element . . . . . . . . . . . . . . . . 9 72 4.3. The Element . . . . . . . . . . . . . . . . . . 9 73 4.3.1. The Element . . . . . . . . . . . . . . . . . 9 74 4.4. The Element . . . . . . . . . . . . 10 75 4.4.1. The Element . . . . . . . . . . . 11 76 4.4.2. The Element . . . . . . . . . . . 12 77 4.4.3. The Element . . . . . . . . . . . 12 78 5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 13 79 5.1. Merging Session Policies . . . . . . . . . . . . . . . . . 13 80 5.1.1. Single Value Selection . . . . . . . . . . . . . . . . 13 81 5.1.2. Merging Sets . . . . . . . . . . . . . . . . . . . . . 14 82 5.1.3. Local Policy Server Selection . . . . . . . . . . . . 15 83 5.2. The Element . . . . . . . . . . . . . . . 15 84 5.3. The Element . . . . . . . . . . . . 15 85 5.4. The Element . . . . . . . . . . . . 16 86 5.5. The Element . . . . . . . . . . . . . . . 16 87 5.6. The Element . . . . . . . . . . . . . . 17 88 5.7. The Element . . . . . . . . . . . . . . . . 17 89 6. Common Media Policy Dataset Elements . . . . . . . . . . . . . 18 90 6.1. The Element . . . . . . . . . . . . . . . . . 18 91 6.2. The Element . . . . . . . . . . . . . . . . . . . 18 92 6.2.1. The Element . . . . . . . . . . . . . . . 18 93 6.2.2. The Element . . . . . . . . . . . . . 19 94 6.3. The Element . . . . . . . . . . . . . . . . . . . 19 95 6.4. The Element . . . . . . . . . . . . . . . 19 96 6.5. The Element . . . . . . . . . . . . . . . 20 97 6.6. The Element . . . . . . . . . . . . . . . . . . 21 98 6.7. The Element . . . . . . . . . . . . . . . . . . 22 99 6.7.1. The Element . . . . . . . . . . . 22 100 6.7.2. The Element . . . . . . . . . . . . . . . . 22 101 6.7.3. The Element . . . . . . . . . . . . . . . . . . 22 102 6.7.4. The Element . . . . . . . . . . . . . . 22 103 6.7.5. The Element . . . . . . . . . . . . . . . . . 22 104 6.8. Other Session Properties . . . . . . . . . . . . . . . . . 23 105 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 106 7.1. Session Policy Documents . . . . . . . . . . . . . . . . . 23 107 7.2. Session Information Documents . . . . . . . . . . . . . . 24 108 7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 24 109 7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 25 110 8. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 27 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 112 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 113 10.1. MIME Registration . . . . . . . . . . . . . . . . . . . . 34 114 10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 35 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 116 11.1. Normative References . . . . . . . . . . . . . . . . . . . 35 117 11.2. Informative References . . . . . . . . . . . . . . . . . . 37 118 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 121 1. Introduction 123 The Framework for Session Initiation Protocol (SIP) [RFC3261] User 124 Agent Profile Delivery [I-D.ietf-sipping-config-framework] and the 125 Framework for SIP Session Policies 126 [I-D.ietf-sip-session-policy-framework] define mechanisms to convey 127 session policies and configuration information from a network server 128 to a user agent. An important piece of the information conveyed to 129 the user agent relates to the media properties of the SIP sessions 130 set up by the user agent. Examples for these media properties are 131 the codecs and media types used, the media-intermediaries to be 132 traversed or the maximum bandwidth available for media streams. 134 This specification defines a document format for media properties of 135 SIP sessions, the Media Policy Dataset Format (MPDF). This format 136 can be used in two ways: first, it can be used to describe the 137 properties of a given SIP session (e.g., the media types and codecs 138 used). These MPDF documents are called session info documents and 139 they are usually created based on the session description of a 140 session. Second, the MPDF format can be used to define policies for 141 SIP sessions in a session policy document. A session policy document 142 defines properties for a session (e.g., the media types allowed in a 143 session), independent of a specific session description. 145 If used with the Framework for SIP Session Policies 146 [I-D.ietf-sip-session-policy-framework], session info documents are 147 used in conjunction with session-specific policies. A session info 148 document is created by a UA based on the current session description 149 and submitted to the policy server. The policy server examines the 150 session info document, modifies it if necessary (e.g., by removing 151 video streams if video is not permitted) and returns the possibly 152 modified session info document to the UA. Session policy documents 153 on the other hand are used to describe session-independent policies 154 that can be submitted to the UA independent of a specific session. 156 The two types of MPDF documents, session information and session 157 policy documents, share the same set of XML elements to describe 158 session properties. Since these elements are used in different 159 contexts for session info and session policy documents, two different 160 root elements exist for the two document types: is the 161 root element for session information documents and 162 is the root element for session policy documents. 164 A user agent can receive multiple session policy documents from 165 different sources. This can lead to a situation in which the user 166 agent needs to apply multiple session policy documents to the same 167 session. This standard specifies merging rules for those XML 168 elements that can be present in session policy documents. It should 169 be noted that these merging rules are part of the semantics of a 170 session policy XML element. User agents implement the merging rules 171 as part of implementing the element semantics. As a consequence, it 172 is not possible to build an entity that can mechanically merge two 173 session policy documents without understanding the semantics of all 174 elements in the input documents. 176 Merging rules are not needed for elements of session information 177 documents since they are created by one source and describe a 178 specific session. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 3. Media Policy Dataset Format 188 This section discusses fundamental properties of the Media Policy 189 Dataset Format (MPDF). 191 3.1. Namespace and MIME Type 193 The MPDF format is based on XML [W3C.REC-xml-20040204]. A MPDF 194 document MUST be well-formed and MUST be valid according to schemas, 195 including extension schemas, available to the validator and 196 applicable to the XML document. MPDF documents MUST be based on XML 197 1.0 and MUST be encoded using UTF-8. 199 MPDF makes use of XML namespaces [W3C.REC-xml-names-19990114]. The 200 namespace URIs for schemas defined in this specification are URNs 201 [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] 202 and extended by [RFC3688]. The namespace URN for the MPDF schema is: 204 urn:ietf:params:xml:ns:mediadataset 206 The MIME type for the Media Policy Dataset Format is: 208 application/media-policy-dataset+xml 210 3.2. Extensibility 212 The MPDF format can be extended using XML extension mechanisms if 213 additional media properties are needed. In particular, elements from 214 different XML namespaces MAY be present within a MPDF document for 215 the purposes of extensibility; elements or attributes from unknown 216 namespaces MUST be ignored. 218 3.3. Attributes 220 The following attributes can be used with elements of the MPDF 221 format. For each MPDF element it is defined, which of these 222 attributes can be used. Attributes that are not defined for an 223 element MUST be ignored. 225 3.3.1. The 'visibility' Attribute 227 The attribute "visibility" specifies whether or not the user agent is 228 permitted to display the property value to the user. This is used to 229 hide setting values that the administrator may not want the user to 230 see or know. The "visibility" attribute has two possible values: 232 o visible: specifies that display of the property value is not 233 restricted. This is the default value of the attribute if it is 234 not specified. 235 o hidden: Specifies that the user agent SHOULD NOT display the 236 property value. Display of the property value may be allowed 237 using special administrative interfaces, but is not appropriate to 238 the ordinary user. 240 3.3.2. The 'direction' Attributes 242 Some properties are unidirectional and only apply to messages or data 243 streams transmitted into one direction. For example, a property for 244 media streams can be restricted to outgoing media streams only. 245 Unidirectional properties can be expressed by adding a 'direction' 246 attribute to the respective element. 248 The 'direction' attribute can have the following values: 250 o recvonly: the property only applies to incoming messages/streams. 251 o sendonly: the property only applies to outgoing messages/streams. 252 o sendrecv: the property applies to messages/streams in both 253 directions. This is the default value that is used if the 254 'direction' attribute is omitted. 256 3.3.3. The 'q' Attribute 258 It should be possible to express a preference for a certain value, if 259 multiple values are allowed within a property. For example, it 260 should be possible to express that the codecs G.711 and G.729 are 261 allowed, but G.711 is preferred. Preferences can be expressed by 262 adding a 'q' attribute to a property element. Elements derived from 263 the "setting" element for which multiple occurrences and values are 264 allowed SHOULD have a "q" attribute if the order is significant. 265 Typically these elements are contained in an element derived from the 266 "setting_container" element. The 'q' attribute is only meaningful if 267 the 'policy' attribute set to 'allowed'. It must be ignored in all 268 other cases. 270 An element with a higher 'q' value is preferred over one with a lower 271 'q' value. 'q' attribute values range from 0 to 1. The default value 272 is 0.5. 274 3.3.4. The 'label' Attribute 276 Some properties only apply to a specific media stream. The stream to 277 which a property applies MUST be identifiable through a label 278 [RFC4574]. Per-stream properties can be expressed by adding a 279 'label' attribute to the respective element. Such a property only 280 applies to the identified stream. If there is no stream with this 281 label, the element must be ignored. 283 Per-stream properties require that the labels of media streams are 284 known to the creator of a document (i.e., the profile delivery/policy 285 server). These labels are part of the session description. 287 3.4. The Element 289 The root element of a property set is it is the 290 container that is provided to the user agent. The elements contained 291 within a contain the specific properties which are to 292 be applied to the user agent. 294 The element is the root element for Session Info and 295 Session Policy documents. 297 4. Session Info Documents 299 Session info documents describe key properties of a SIP session such 300 as the media streams used in the session. Session info documents are 301 typically created based on an SDP [RFC4566] session description or an 302 SDP offer/answer pair [RFC3264]. 304 Session info documents can be used for session-specific policies 305 [I-D.ietf-sip-session-policy-framework]. In this usage, a UA creates 306 a session info document based on its SDP description(s) and sends 307 this document to the policy server. The policy server modifies this 308 document according to the policies that apply to the described 309 session and returns a version of the session info document that is 310 compliant to all policies. For example, if video streams are not 311 permissible under current policies and the UA submits a session info 312 document that contains a video stream, the policy server will remove 313 the video stream from the XML markup and return the modified session 314 info document to the UA. 316 Session info documents use the container. They use 317 elements described in this section and common elements described in 318 Section 6. 320 Elements that are only present in session info document do not 321 require merging rules. If used in the context of session-specific 322 policies, session info documents are sent to one policy server at a 323 time only, therefore a UA does not need to merge multiple session 324 info documents into one. A policy server needs to modify a session 325 info document it has received according to its policies. The 326 modification of session info documents is determined by the local 327 policies of the policy server and outside the scope of this standard. 329 A policy server can completely reject a session by returning an 330 session info document with an empty element: 332 <\session-info> 334 4.1. Mapping SDP to Session Info Documents 336 If a UA has an SDP offer as well as an answer [RFC3264] and wants to 337 create a session info document, the UA MUST use the answer to fill in 338 the elements of the session info document except for the remote-host- 339 port and local-host-port elements, which are taken from the remote 340 and local session description respectively. The local session 341 description is the one created locally by the UA (i.e., the offer if 342 the UA has initiated the offer/answer exchange). The remote session 343 description is the one received from the remote UA. 345 The following rules describe the creation of session info documents 346 based on SDP description(s) for a few exemplary elements. Other 347 elements are created following the same principles. 349 A UA MUST create a separate element for each m= line in an 350 SDP description. The UA MUST insert the media type from the m= line 351 into a element and MUST create a element for 352 each codec listed in the m= line. 354 The UA MUST create a element for each stream using 355 the port taken from the m= line and the address from the 356 corresponding c= line of the local session description. The UA MUST 357 create a element using the port and address from 358 the m= and c= lines for the same stream taken from the remote session 359 description if this session description is available. 361 The mapping from a session info document to a SDP description follows 362 the same rules in the reverse direction. 364 4.2. The Element 366 The element describes the properties of a specific SIP 367 session. The element MAY occur multiple times inside 368 a element. 370 The element MAY contain one optional , 371 and multiple (including zero) , , 372 , and elements as 373 well as elements from other namespaces. The MPDF elements are 374 defined in Section 6. 376 4.3. The Element 378 The element is a container that is used to describe the 379 media streams used in a session. A element can contain 380 multiple elements. Each element describes the 381 properties (e.g., media type, codecs and IP addresses and ports) of a 382 single media stream. 384 The element MUST contain one or more elements. 386 4.3.1. The Element 388 The element describes a specific media stream. It contains 389 the media type, codecs and the hostname(s) or IP address(es) and 390 port(s) of this stream. 392 The hostname(s) or IP address(es) and port number(s) of a stream 393 correspond to the ones listed in the session description(s). A UA 394 that generates a element MUST insert the hostname/port found 395 in the local session description for this media stream into the 396 local-host-port element. The UA MUST insert the hostname/port of the 397 remote session description into the remote-host-port element, if the 398 remote session description is available to the UA. If not, the UA 399 generates a stream element that only contains the local-host-port 400 element. 402 This element MAY have the following attributes (see Section 3.3): 403 direction, label. 405 The label attribute is used to identify a specific media stream in a 406 session description. The value of the label attribute is a token. 407 The token can be chosen freely, however, it MUST be unique among all 408 element in a session-info document. If a label attribute 409 [RFC4574] is present in the SDP description, its value MUST be 410 carried over to the label attribute of the corresponding 411 element. 413 The element MUST contain one element, one or 414 more elements and one element. The 415 element MAY contain one element. 417 4.3.1.1. The Element 419 The element contains the hostname or IP address and 420 the port number of the media stream in the local session description. 421 The hostname or IP address is separated from the port by a ":". An 422 example is: "host.example.com:49562". 424 The hostname or IP address of element is found in the c= element for 425 the stream in the local SDP description. The port number is found in 426 the m= element. 428 4.3.1.2. The Element 430 The element is structured exactly as the element. However, it identifies the hostname or IP 432 address and port number of the media stream in the remote session 433 description. 435 4.4. The Element 437 The element expresses a policy for routing a 438 media stream through a media intermediary. The purpose of the 439 element is to tell the UA to send a media 440 stream through one (or a chain of) media intermediaries. Instead of 441 sending the media directly to its final destination, the UA specifies 442 a source route, which touches each intermediary and then reaches the 443 final recipient. If there are N hops, including the final recipient, 444 there needs to be a way for the media stream to specify N 445 destinations. 447 The element is a container that lists all 448 media intermediaries to be traversed. Media intermediaries should be 449 traversed in the order in which they appear in this list. The 450 topmost entry should be traversed first, the last entry should be 451 traversed last. 453 Different types of intermediaries exist. These intermediaries are 454 not necessarily interoperable and it may not be possible to chain 455 them in an arbitrary order. A element SHOULD 456 therefore only contain intermediary elements of the same type. 458 This element MAY have the following attributes (see Section 3.3): 459 direction. 461 Multiple elements MAY only be present in a 462 container if each applies to a different set of streams (e.g., one 463 element for incoming and one for outgoing 464 streams). The element MUST contain one or 465 more elements defining a specific media intermediary, such as or . 468 Note: it is not intended that the element 469 replaces connectivity discovery mechanisms such as ICE. Instead 470 of finding media relays that provide connectivity, this element 471 defines a policy for media intermediaries that should be 472 traversed. The set of intermediaries defined in the element and the ones discovered through ICE may 474 overlap but don't have to. 476 4.4.1. The Element 478 A fixed intermediary relies on pre-configured forwarding rules. The 479 user agent simply sends media to the first media intermediary listed. 480 It can assume that this media intermediary has been pre-configured 481 with a forwarding rule for the media stream and knows where to 482 forward the packets to. The configuration of forwarding rules in the 483 intermediary must be done through other means. 485 The contents of a element MUST be echoed to all 486 policy servers that provide policies for a session. I.e., if 487 multiple policy servers provide policies for the same session, this 488 element needs to be forwarded to all of them, possibly in a second 489 round of session-specific policy subscriptions as described in 490 [I-D.ietf-sip-session-policy-framework] in section Contacting the 491 Policy Server. 493 The element MUST contain one 494 element and MAY contain multiple optional elements. 496 4.4.1.1. The Element 498 The element contains the hostname or IP address and 499 port number of a media intermediary. The UA uses this hostname/IP 500 address and port to send its media streams to the intermediary. The 501 hostname or IP address is separated from the port by a ":". 503 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 504 port number SHOULD be included in the element. All 505 additional port numbers SHOULD be identified in 506 elements. 508 4.4.1.2. The Element 510 If a protocol uses multiple subsequent ports (e.g., RTP), the lowest 511 port number SHOULD be included in the element. All 512 additional port numbers SHOULD be identified in 513 elements. 515 4.4.2. The Element 517 The TURN [RFC5766] protocol provides a mechanism for inserting a 518 relay into the media path. Although the main purpose of TURN is NAT 519 traversal, it is possible for a TURN relay to perform other media 520 intermediary functionalities. The user agent establishes a binding 521 on the TURN server and uses this binding to transmit and receive 522 media. 524 The element MUST contain one 525 element and MAY contain multiple optional elements 526 and zero or one each of the , , and 527 elements. If no element is present, UDP is assumed. 529 4.4.2.1. The Element 531 The element contains the shared secret needed to 532 authenticate at the media intermediary. 534 4.4.2.2. The element 536 The element contains the user ID needed to authenticate to the 537 media intermediary. 539 4.4.2.3. The Element 541 The element contains the name of the transport to be used 542 for communicating with the TURN server. This document defines the 543 values "tcp" and "udp" for use in the element. Other 544 specifications may define additional values. 546 4.4.3. The Element 548 The MSRP Relay Extensions [RFC4976] define a means for incorporating 549 relays into the media path of an MSRP [RFC4975] session. MSRP is 550 explicitly designed for a variety of purposes, including policy 551 enforcement. 553 The element MUST contain one element, 554 and may contain zero or one each of the and 555 elements. 557 4.4.3.1. The Element 559 The element contains a URI that indicates the MSRP server 560 to use for an intermediary. The UA uses this URI to authenticate 561 with the MSRP relay, and then uses the URI it learns through that 562 authentication process for any MSRP media it sends or receives. Only 563 URIs with a scheme of "msrps:" are valid in the element. 565 5. Session Policy Documents 567 Session policy documents describe a policy for SIP sessions. Session 568 policy documents are independent of a specific session description 569 and express general policies for SIP sessions. A session policy 570 document is used to determine if a SIP session is policy conformant 571 and to modify this session, if needed, according to the described 572 policies. 574 Session policy documents can be used to encode session-independent 575 policies [I-D.ietf-sip-session-policy-framework]. In this usage, a 576 policy server creates a session policy document and passes this 577 document to a UA. The UA applies the policies defined to the SIP 578 sessions it is establishing. For example, a session policy document 579 can contain an element that prohibits the use of video. To set up a 580 session that is compliant to this policy, a UA does not include the 581 media type video in its SDP offer or answer. 583 Session policy documents use the container. They 584 use elements described in this section and common elements described 585 in Section 6. 587 5.1. Merging Session Policies 589 A UA may receive session policy documents from multiple sources, 590 which need to be merged into a single session policy document the UA 591 can work with. 593 5.1.1. Single Value Selection 595 Properties that have a single value (e.g., the maximum bandwidth 596 allowed) require that a common value is determined for this property 597 during the merging process. The merging rules for determining this 598 value need to be defined individually for each element in the schema 599 definition (e.g., select the lowest maximum bandwidth). 601 5.1.2. Merging Sets 603 The media-types-allowed, media-types-excluded, codecs-allowed and 604 codecs-excluded are containers that contain a set of media-types/ 605 codecs. The values defined in these containers need to be merged to 606 determine the set of media-types/codecs that are permissible in a 607 session. 609 To merge the media-types-* and codecs-* containers a UA needs to 610 apply all containers it has received one after the other the set of 611 media-types/codecs it supports. After applying media-types-*/ 612 codecs-* elements, the UA has the list of media-types/codecs that are 613 allowed in a session. The containers can be applied in any order. 614 However, each time a container is applied to the set of media-types/ 615 codecs allowed, this set MUST stay the same or be reduced. Media- 616 types/codecs cannot be added during this process. 618 The following example illustrates the merging process for two data 619 sets. In this example, the UA supports the following set of audio 620 codecs: PCMA, PCMU and G729. After applying session policy document 621 1, the UA removes PCMA as it is disallowed by this policy. The 622 remaining set of codecs is: PCMU and G729. Session policy document 2 623 disallows all codecs that are not listed. After applying this 624 policy, the set of codecs allowed is: G729. 626 Session Policy Document 1: 627 628 audio/PCMA 629 631 Session Policy Document 2: 632 633 audio/PCMA 634 audio/G729 635 637 It is possible that two session policy documents define non- 638 overlapping sets of allowed media-types or codecs. The resulting 639 merged set would be empty, which is illegal according to the schema 640 definition of the media-types/codecs element. This constitutes a 641 conflict that cannot be resolved automatically. If these properties 642 are enforced by both networks, the UA will not be able to set up a 643 session. 645 The combined set of media-types/codecs MUST again be valid and well- 646 formed according to the schema definitions. A conflict occurs if the 647 combined property set is not a well-formed document after the merging 648 process is completed. 650 5.1.3. Local Policy Server Selection 652 Some properties require that only values from the local policy server 653 are used. The local policy server is the policy server that is in 654 the local domain of the user agent. 656 If policy documents are delivered through the configuration framework 657 [I-D.ietf-sipping-config-framework], the value received through a 658 subscription using the "local-network" profile-type is used. Values 659 received through other profile-type subscriptions are discarded. 661 If policy documents are delivered through the session-specific policy 662 mechanism [I-D.ietf-sip-session-policy-framework] the value received 663 from the policy server identified by the Local Policy Server URI are 664 used. Values received from other policy servers are discarded. 666 5.2. The Element 668 The element describes a policy that applies to SIP 669 sessions. The element MAY occur multiple times 670 inside a element. 672 The element MAY contain one optional and 673 element and multiple (including zero) , , , , , , and 676 elements as well as elements from other namespaces. The MPDF 677 elements are defined in Section 6. 679 5.3. The Element 681 The element is a container that is used to 682 define the set of media types (e.g., audio, video) that are allowed 683 in a session. All media types that are not listed in this container 684 are not permitted in a session. A specific media type is allowed by 685 adding the corresponding element to this container. 687 This element MAY have the following attributes (see Section 3.3): 688 direction, visibility. 690 Multiple elements MAY only be present in a 691 container element if each applies to a different set of streams 692 (e.g., one element for incoming and one for 693 outgoing streams). The element MUST contain 694 one or more elements. 696 A element MUST NOT be used in a container that 697 contains a element. 699 Merging of session-policy documents: 700 containers are merged as described in "Merging Sets" 701 Section 5.1.2. 703 5.4. The Element 705 The element is a container that is used to 706 define the set of media types (e.g., audio, video) that are not 707 permitted in a session. All media types that are not listed in this 708 container are allowed and can be used in a session. A specific media 709 type is excluded from a session by adding the corresponding element to this container. 712 This element MAY have the following attributes (see Section 3.3): 713 direction, visibility. 715 Multiple elements MAY only be present in a 716 container element if each applies to a different set of streams 717 (e.g., one element for incoming and one for 718 outgoing streams). The element MUST contain 719 one or more elements. 721 A element MUST NOT be used in a container that 722 contains a element. 724 Merging of session-policy documents: 725 containers are merged as described in "Merging Sets" 726 Section 5.1.2. 728 5.5. The Element 730 The element is a container that is used to define 731 the set of codecs that may be used in a session. All codes not 732 listed in the element are disallowed and MUST NOT be 733 used in a session. A policy MUST allow the use of at least one codec 734 per media type. A specific codec is allowed by adding the 735 corresponding element to this container. 737 The element MAY have the following attributes (see 738 Section 3.3): direction, visibility. 740 Multiple elements MAY only be present in a container 741 element if each applies to a different set of streams (e.g., one 742 element for incoming and one for outgoing streams). 743 The element MUST contain one or more 744 elements. 746 A element MUST NOT be used in a container that 747 contains a element. 749 Merging of session-policy documents: containers 750 are merged as described in "Merging Sets" Section 5.1.2. 752 5.6. The Element 754 The element is a container that is used to define 755 the set of codecs that are disallowed in a session. All codes not 756 listed in the element are permitted and MAY be used 757 in a session. A specific codec is disallowed by adding the 758 corresponding element to this container. 760 The element MAY have the following attributes (see 761 Section 3.3): direction, visibility. 763 Multiple elements MAY only be present in a 764 container element if each applies to a different set of streams 765 (e.g., one element for incoming and one for 766 outgoing streams). The element MUST contain one or 767 more elements. 769 A element MUST NOT be used in a container that 770 contains a element. 772 Merging of session-policy documents: containers 773 are merged as described in "Merging Sets" Section 5.1.2. 775 5.7. The Element 777 Domains often require that a user agent only uses ports in a certain 778 range for media streams. The element defines a policy 779 for the ports a user agent can use for media. The value of this 780 element consists of a start port and an end port separated by a "-". 781 The start/end port is the first/last port that can be used. 783 This element MAY have the following attributes (see Section 3.3): 784 visibility. 786 Merging of session-policy documents: the local domain of the user 787 agent has precedence over other domains and its local ports value 788 is used. During the merging process, element values 789 from local policy server selected as described in "Local Policy 790 Server Selection" Section 5.1.3 are used. 792 6. Common Media Policy Dataset Elements 794 This section describes common XML elements that are used in session 795 info and session policy documents to encode the media properties of 796 SIP sessions. 798 6.1. The Element 800 The element identifies a specific media type. The value 801 of this element MUST be the name of a IANA registered media type (see 802 RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 803 'application'. 805 This element MAY have the following attribute (see Section 3.3): q. 807 If used in a session policy document inside a 808 element, the media types defined MAY be used in a session. If used 809 in a session policy document inside a element, 810 the media types defined MUST NOT be used in a session. 812 6.2. The Element 814 The element identifies a specific codec. The content of this 815 element MUST be a registered MIME type [RFC4855] using media type and 816 subtype (e.g., audio/PCMA [RFC4856] or video/H263 [RFC4629]) and 817 possibly additional registered MIME type parameters. 819 The element MAY have the following attribute (see 820 Section 3.3): q. 822 If used in a session policy document inside a 823 element, the codec defined MAY be used in a session. If used in a 824 session policy document inside a element, the codec 825 defined MUST NOT be used in a session. 827 The element MUST contain one element and MAY 828 contain multiple optional elements. 830 6.2.1. The Element 832 The element contains a MIME type that identifies a codec. 833 The value of this element MUST be a combination of a registered MIME 834 media type and subtype [RFC4855] separated by a "/" (e.g., audio/ 835 PCMA, audio/G726-16 [RFC4856] or video/H263 [RFC4629]). 837 6.2.2. The Element 839 The element may be needed for some codecs to 840 identify a particular encoding or profile. The value of this element 841 MUST be a name-value pair containing the name and the value of a 842 registered MIME type parameter for the codec [RFC4855]. The name and 843 value are separated by a "=". For example, the parameter "profile=0" 844 can be used to specify a specific profile for the codec "video/ 845 H263-2000" [RFC4629]. 847 6.3. The Element 849 The element defines the overall maximum bandwidth in 850 kilobits per second an entity can/will use for media streams at any 851 point in time. It defines an upper limit for the total bandwidth an 852 entity can/will use for the transmission of media streams. The limit 853 corresponds to the sum of the maximum session bandwidth of all 854 sessions a UA may set up in parallel. 856 The bandwidth limit given in the element includes the 857 bandwidth needed for lower-layer transport and network protocols 858 (e.g., UDP and IP). 860 The element MAY have the following attribute (see 861 Section 3.3): direction. 863 If used in a element, the element MAY have 864 the following additional attribute (see Section 3.3): visibility. 866 If the element occurs multiple times in a container element, 867 each instance MUST apply to a different set of media streams (i.e., 868 one element for outgoing and one for incoming streams). 870 Merging of session-policy documents: the lowest max-bw value is 871 used. 873 6.4. The Element 875 The element defines the maximum bandwidth in 876 kilobits per second an entity can/will use for media streams in the 877 described session. It defines an upper limit for the total bandwidth 878 of a single session. This limit corresponds to the sum of the 879 maximum stream bandwidth of all media streams in a session. 881 The bandwidth limit given in the element includes 882 the bandwidth needed for lower-layer transport and network protocols 883 (e.g., UDP and IP). 885 The value of the element is equivalent to the CT 886 bandwidth in the b= line of an SDP [RFC4566] announcement. 888 The element MAY have the following attribute (see 889 Section 3.3): direction. 891 If used in a element, the element 892 MAY have the following additional attribute (see Section 3.3): 893 visibility. 895 If the element occurs multiple times in a container 896 element, each instance MUST apply to a different set of media streams 897 (i.e., one element for outgoing and one for incoming 898 streams). 900 Merging of session-policy documents: the lowest max-session-bw 901 value is used. 903 6.5. The Element 905 The element defines the maximum bandwidth in kilobits 906 per second an entity can/will use for each media stream in the 907 described session. 909 The bandwidth limit given in the element includes the 910 bandwidth needed for lower-layer transport and network protocols 911 (e.g., UDP and IP). 913 The value of the element is equivalent to the AS 914 bandwidth in the b= line of an SDP [RFC4566] announcement. 916 The element MAY have the following attribute (see 917 Section 3.3): direction, media-type. 919 If used in a element, the element 920 MAY have the following additional attribute (see Section 3.3): 921 visibility. 923 If used in a element, the element MAY 924 have the following additional attribute: label. 926 The media-type attribute is used to define that the 927 element only applies to streams of a certain media type. For 928 example, it may only apply to audio streams. The value of the 929 'media-type' attribute MUST be the name of a IANA registered media 930 type (see RFC4566 [RFC4566]), such as 'audio', 'video', 'text', or 931 'application'. 933 The label attribute is used to define a bandwidth limit for a 934 specific media stream. The use of this attribute requires that the 935 element that represents the media stream to which this 936 bandwidth limit applies also has a label attribute. A 937 element with a label attribute applies only to the 938 stream element that has a label attribute with the same value. If no 939 matching element exists, then the element 940 MUST be ignored. 942 If the element occurs multiple times in a container 943 element, each instance MUST apply to a different set of media streams 944 (i.e., one element for outgoing and one for incoming 945 streams). 947 Merging of session-policy documents: the lowest max-stream-bw 948 value is used. 950 6.6. The Element 952 The element contains an Differentiated Services Codepoint 953 (DSCP) [RFC2474] value that should be used to populate the IP DS 954 field of media packets. The contains an integer value 955 that represents a 6 bit field and therefore ranges from 0 to 63. 957 This element MAY have the following attributes (see Section 3.3): 958 direction, media-type. 960 If used in a element, the element MAY 961 have the following additional attribute (see Section 3.3): 962 visibility. 964 The media-type attribute is used to define that element 965 only applies to streams of a certain media type. For example, it may 966 only apply to audio streams. The value of the 'media-type' attribute 967 MUST be the name of a IANA registered media type (see RFC4566 968 [RFC4566]), such as 'audio', 'video', 'text', or 'application'. 970 The element is optional and MAY occur multiple times 971 inside a container. If the element occurs multiple times, 972 each instance MUST apply to a different media stream (i.e., one element for audio and one for video streams). 975 Merging of session-policy documents: the local domain of the user 976 agent has precedence over other domains and its DSCP value is 977 used. During the merging process, element values from 978 local policy server selected as described in "Local Policy Server 979 Selection" Section 5.1.3 are used. 981 6.7. The Element 983 The element provides context information about a session 984 policy or session information document. 986 The element MAY contain multiple and one 987 element. 989 If used in a element, the element MAY also 990 contain a element. 992 If used in a element, the element MAY also 993 contain a and a element. 995 Merging of session-policy documents: the element is not 996 subject to merging. 998 6.7.1. The Element 1000 The element contains the URI of the policy server 1001 that has issued this policy. 1003 The element is only defined inside a element. 1006 6.7.2. The Element 1008 The element contains a contact address (e.g., a SIP URI or 1009 email address) under which the issuer of this document can be 1010 reached. 1012 6.7.3. The Element 1014 The element provides a short textual description of the policy 1015 or session that should be intelligible to the human user. 1017 6.7.4. The Element 1019 The element identifies the request-URI the dialog 1020 initiating request of a session is sent to. 1022 The element is only defined inside a 1023 element. 1025 6.7.5. The Element 1027 The element provides a mechanism for a policy server to 1028 return an opaque token to a UA. This is sometimes needed to ensure 1029 that all requests for a session are routed to the same policy server. 1030 The use of this token is described in the Framework for SIP Session 1031 Policies [I-D.ietf-sip-session-policy-framework]. 1033 The element is only defined inside a element. 1035 6.8. Other Session Properties 1037 A number of additional elements have been proposed for a media 1038 property language. These elements are deemed to be outside the scope 1039 of this format. However, they may be defined in extensions of MPDF 1040 or other profile data sets. 1042 o maximum number of streams 1043 o maximum number of sessions 1044 o maximum number of streams per session 1045 o external address and port 1046 o media transport protocol 1047 o outbound proxy 1048 o SIP methods 1049 o SIP option tags 1050 o SIP transport protocol 1051 o body disposition 1052 o body format 1053 o body encryption 1055 7. Examples 1057 7.1. Session Policy Documents 1059 The following example describes a session policy document that allows 1060 the use of audio and video and prohibits the use of other media 1061 types. It allows the use of any codec except G.723 and G.729. 1063 1064 1065 1066 policy@biloxi.example.com 1067 sip:policy_manager@example.com 1068 Access network policies 1069 1070 1071 audio 1072 video 1073 1074 1075 audio/G729 1076 audio/G723 1077 1078 1079 1081 7.2. Session Information Documents 1083 The following examples contain session descriptions and the session 1084 information documents that represent these sessions. 1086 7.2.1. Example 1 1088 In this example, a session info document is created based on one 1089 session description. This session info document would be created, 1090 for example, by a UA that has composed an offer and is now contacting 1091 a policy server. 1093 Local SDP session description: 1095 v=0 1096 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1097 s= 1098 c=IN IP4 host.somewhere.example 1099 t=0 0 1100 m=audio 49562 RTP/AVP 0 1 3 1101 a=rtpmap:0 PCMU/8000 1102 a=rtpmap:1 1016/8000 1103 a=rtpmap:3 GSM/8000 1104 m=video 51234 RTP/AVP 31 34 1105 a=rtpmap:31 H261/90000 1106 a=rtpmap:34 H263/90000 1108 MPDF document: 1110 1111 1112 1113 sip:alice@somewhere.example 1114 session information 1115 1116 1117 1118 audio 1119 audio/PCMU 1120 audio/1016 1121 audio/GSM 1122 host.somewhere.example:49562 1123 1124 1125 video 1126 video/H261 1127 video/H263 1128 host.somewhere.example:51234 1129 1130 1131 1132 1134 7.2.2. Example 2 1136 In this example, a session info document is created that represents 1137 two session descriptions (i.e., an offer and answer). This session 1138 info document would be created, for example, by a UA that has 1139 received an answer from another UA and is now contacting a policy 1140 server. 1142 Local SDP session description: 1144 v=0 1145 o=alice 2890844526 2890844526 IN IP4 host.somewhere.example 1146 s= 1147 c=IN IP4 host.somewhere.example 1148 t=0 0 1149 m=audio 49562 RTP/AVP 0 1 3 1150 a=rtpmap:0 PCMU/8000 1151 a=rtpmap:1 1016/8000 1152 a=rtpmap:3 GSM/8000 1153 m=video 51234 RTP/AVP 31 34 1154 a=rtpmap:31 H261/90000 1155 a=rtpmap:34 H263/90000 1157 Remote SDP session description: 1159 v=0 1160 o=bob 2890844730 2890844730 IN IP4 host.anywhere.example 1161 s= 1162 c=IN IP4 host.anywhere.example 1163 t=0 0 1164 m=audio 52124 RTP/AVP 0 3 1165 a=rtpmap:0 PCMU/8000 1166 a=rtpmap:3 GSM/8000 1167 m=video 50286 RTP/AVP 31 1168 a=rtpmap:31 H261/90000 1170 MPDF document that represents the local and the remote session 1171 description: 1173 1174 1175 1176 sip:alice@somewhere.example 1177 session information 1178 1179 1180 1181 audio 1182 audio/PCMU 1183 audio/GSM 1184 host.somewhere.example:49562 1185 host.anywhere.example:52124 1186 1187 1188 video 1189 video/H261 1190 host.somewhere.example:51234 1191 host.anywhere.example:50286 1192 1193 1194 1195 1197 The following MPDF document is a modified version of the above 1198 document, which can be returned by a policy server. This document 1199 reflects a policy that defines a maximum session bandwidth of 192 1200 kbit and a maximum bandwidth for the H261 video stream of 128 kbit. 1202 1203 1204 1205 sip:alice@somewhere.example 1206 modified session information 1207 1208 1209 1210 audio 1211 audio/PCMU 1212 audio/GSM 1213 host.somewhere.example:49562 1214 host.anywhere.example:52124 1215 1216 1217 video 1218 video/H261 1219 host.somewhere.example:51234 1220 host.anywhere.example:50286 1221 1222 1223 128 1224 192 1225 1226 1228 8. Relax NG Definition 1230 This section needs to be updated. 1232 ?xml version="1.0"?> 1233 1237 1239 1240 1241 1242 1243 1244 1245 1246 1247 1249 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 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1393 1395 1396 1397 1398 1399 1400 1402 1403 1404 1405 1406 1407 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1438 1439 1440 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1459 1460 1461 1462 1463 1464 1465 1466 1467 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1483 1484 1485 1486 1487 1488 1489 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1528 1529 1530 1531 1532 1534 1535 1536 1537 1538 1540 1542 9. Security Considerations 1544 Session policy information can be sensitive information. The 1545 protocol used to distribute session policy information SHOULD ensure 1546 privacy, message integrity and authentication. Furthermore, the 1547 protocol SHOULD provide access controls which restrict who can see 1548 who else's session policy information. 1550 10. IANA Considerations 1552 This document registers a new MIME type, application/ 1553 media-policy-dataset+xml, and a new XML namespace. 1555 10.1. MIME Registration 1557 MIME media type name: application 1559 MIME subtype name: media-policy-dataset+xml 1561 Mandatory parameters: none 1563 Optional parameters: Same as charset parameter application/xml as 1564 specified in RFC 3023 [RFC3023]. 1566 Encoding considerations: Same as encoding considerations of 1567 application/xml as specified in RFC 3023 [RFC3023]. 1569 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 1570 Section 9 of this specification. 1572 Interoperability considerations: none. 1574 Published specification: This document. 1576 Applications which use this media type: This document type has been 1577 used to convey media policy information between SIP user agents and a 1578 domain. 1580 Additional Information: 1582 Magic Number: None 1584 File Extension: .mpf or .xml 1585 Macintosh file type code: "TEXT" 1587 Personal and email address for further information: Volker Hilt, 1588 1590 Intended usage: COMMON 1592 Author/Change controller: The IETF. 1594 10.2. URN Sub-Namespace Registration 1596 This section registers a new XML namespace, as per the guidelines in 1597 [RFC3688] 1599 URI: The URI for this namespace is 1600 urn:ietf:params:xml:ns:mediadataset. 1602 Registrant Contact: IETF, SIPPING working group, , 1603 Volker Hilt, 1605 XML: 1607 BEGIN 1608 1609 1611 1612 1613 1615 Media Policy Dataset Namespace 1616 1617 1618

Namespace for Media Policy Datasets

1619

urn:ietf:params:xml:ns:mediadataset

1620

See RFCXXXX.

1621 1622 1623 END 1625 11. References 1627 11.1. Normative References 1629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1630 Requirement Levels", BCP 14, RFC 2119, March 1997. 1632 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1634 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1635 "Definition of the Differentiated Services Field (DS 1636 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1637 December 1998. 1639 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1640 Types", RFC 3023, January 2001. 1642 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1643 with Session Description Protocol (SDP)", RFC 3264, 1644 June 2002. 1646 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1647 January 2004. 1649 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1650 Description Protocol", RFC 4566, July 2006. 1652 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1653 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1655 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1656 Formats", RFC 4855, February 2007. 1658 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1659 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1661 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1662 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1663 September 2007. 1665 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1666 Relays around NAT (TURN): Relay Extensions to Session 1667 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1669 [W3C.REC-xml-20040204] 1670 Yergeau, F., Maler, E., Bray, T., Paoli, J., and C. 1671 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 1672 (Third Edition)", World Wide Web Consortium 1673 FirstEdition REC-xml-20040204, February 2004, 1674 . 1676 [W3C.REC-xml-names-19990114] 1677 Hollander, D., Layman, A., and T. Bray, "Namespaces in 1678 XML", World Wide Web Consortium FirstEdition REC-xml- 1679 names-19990114, January 1999, 1680 . 1682 11.2. Informative References 1684 [I-D.ietf-sip-session-policy-framework] 1685 Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework 1686 for Session Initiation Protocol (SIP) Session Policies", 1687 draft-ietf-sip-session-policy-framework-07 (work in 1688 progress), February 2010. 1690 [I-D.ietf-sipping-config-framework] 1691 Channabasappa, S., "A Framework for Session Initiation 1692 Protocol User Agent Profile Delivery", 1693 draft-ietf-sipping-config-framework-17 (work in progress), 1694 February 2010. 1696 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1697 August 1999. 1699 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1700 A., Peterson, J., Sparks, R., Handley, M., and E. 1701 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1702 June 2002. 1704 [RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. 1705 Even, "RTP Payload Format for ITU-T Rec", RFC 4629, 1706 January 2007. 1708 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 1709 the RTP Profile for Audio and Video Conferences", 1710 RFC 4856, February 2007. 1712 Appendix A. Acknowledgements 1714 Many thanks to Allison Mankin, Dan Petrie, Martin Dolly, Adam Roach 1715 and Ben Campbell for the discussions and suggestions. Many thanks to 1716 Roni Even and Mary Barnes for reviewing the draft and to Jari 1717 Urpalainen for helping with the Relax NG schema. 1719 Authors' Addresses 1721 Volker Hilt 1722 Bell Labs/Alcatel-Lucent 1723 791 Holmdel-Keyport Rd 1724 Holmdel, NJ 07733 1725 USA 1727 Email: volkerh@bell-labs.com 1729 Dale R. Worley 1730 Nortel Networks Corp. 1731 600 Technology Park Dr. 1732 Billerica, MA 01821 1733 US 1735 Email: dworley@nortel.com 1737 Gonzalo Camarillo 1738 Ericsson 1739 Hirsalantie 11 1740 Jorvas 02420 1741 Finland 1743 Email: Gonzalo.Camarillo@ericsson.com 1745 Jonathan Rosenberg 1746 jdrosen.net 1747 Monmouth, NJ 1748 USA 1750 Email: jdrosen@jdrosen.net