idnits 2.17.1 draft-burger-mscl-thoughts-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1146. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1123. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1136. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 5, 2006) is 6535 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) -- Obsolete informational reference (is this intentional?): RFC 3525 (ref. '1') (Obsoleted by RFC 5125) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3720 (ref. '7') (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '9') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3530 (ref. '10') (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '11') (Obsoleted by RFC 5321) == Outdated reference: A later version (-28) exists of draft-ietf-speechsc-mrcpv2-09 == Outdated reference: A later version (-09) exists of draft-vandyke-mscml-08 == Outdated reference: A later version (-07) exists of draft-melanchuk-sipping-msml-05 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-kpml-07 == Outdated reference: A later version (-01) exists of draft-even-media-server-req-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Burger 3 Internet-Draft Cantata Technology, Inc. 4 Expires: December 7, 2006 June 5, 2006 6 Media Server Control Language and Protocol Thoughts 7 draft-burger-mscl-thoughts-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 7, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 IP mutli-function Media Server control is a problem that has slowly 41 bubbled up in importance over the past four years. A driver in the 42 IETF is the requirements generated by the XCON framework. Many 43 approaches have been proposed. Some of these proposals are device- 44 controlled-oriented, such as H.248. Others are server-oriented, 45 using SIP and application-oriented markup. Before rushing headlong 46 into a framework for a solution, it is time to step back and try to 47 understand just what the scope of the problem is. Once consensus is 48 reached, we can then move forward with a framework for a solution. 50 This document describes a number of existing approaches and proposals 51 to solve the Application Server - Media Server protocol problem, 52 their characteristics and benefits and drawbacks. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Media Resource Model . . . . . . . . . . . . . . . . . . . 4 59 2.2. Number of Protocol Messages for a Given Operation . . . . 5 60 2.3. Network Topology . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. Protocol Layer Integrity . . . . . . . . . . . . . . . . . 6 62 2.5. Computer Science Issues . . . . . . . . . . . . . . . . . 7 63 2.6. Deployment Scale . . . . . . . . . . . . . . . . . . . . . 9 64 2.7. Compatibility with SIP Model . . . . . . . . . . . . . . . 10 65 2.8. Security Issues . . . . . . . . . . . . . . . . . . . . . 10 66 3. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 11 67 3.1. Pure Device Control . . . . . . . . . . . . . . . . . . . 11 68 3.2. Pure SIP . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.3. SIP With TCP Side Channel . . . . . . . . . . . . . . . . 12 70 3.4. SIP With INFO . . . . . . . . . . . . . . . . . . . . . . 13 71 3.5. SIP With SUBSCRIBE/NOTIFY . . . . . . . . . . . . . . . . 14 72 3.6. SIP With MEDIA . . . . . . . . . . . . . . . . . . . . . . 14 73 4. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.1. H.248 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 4.2. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.3. MOML/MSML . . . . . . . . . . . . . . . . . . . . . . . . 18 77 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 20 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 8. Informative References . . . . . . . . . . . . . . . . . . . . 22 81 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 24 82 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 Intellectual Property and Copyright Statements . . . . . . . . . . 26 86 1. Introduction 88 An IP multi-function Media Server is a network server that provides 89 media processing services to the network. 91 There are two models for media resource servers. One models the 92 media resource server as a box of low-level resources, such as RTP 93 mixers, transcoders, audio play and record resources, video play and 94 record resources, tone detection and generation resources, and 95 resources to connect, or "plumb" the resources together. The other 96 model is that of a server that offers announcement services, 97 interactive voice response (IVR) services (including speech 98 recognition and speech synthesis modalities), interactive video 99 response (IVVR) services, basic mixing services, and enhanced mixing 100 services. 102 In general, when we say "multi-function Media Server", we are 103 referring to the server model. 105 As the IP Media Server evolved from a box of low-level resources into 106 a first-class server in the Internet, the protocol interfaces to 107 control the IP Media Server evolved, as well. When people thought of 108 the media server as a box of low-level resources, device control 109 protocols like H.248 [1] seemed appropriate. At the time, the 110 primary model for control of a media server was from a "SoftSwitch", 111 or Media Gateway Controller. The principal application was for 112 playing announcements and collecting a small number of digits. The 113 Media Gateway Controller already implemented a device control state 114 machine to control the Media Gateways. Moreover, the Media Gateway 115 Controller implemented some form of Gateway Control protocol to 116 control the Media Gateways. Thus it was logical to assume that a 117 device control protocol, more specifically H.248 from the IETF 118 perspective, would be appropriate for media resource control. 120 Although the "SoftSwitch" (traditional telephony) model (and market) 121 was an early driver for the need for media resources, within two 122 years it was clear that the primary consumer of media resources would 123 be Internet-oriented applications. Developers create and deploy 124 these applications on Internet Application Servers, using Internet 125 and Web tools and protocols. These Application Servers have no need 126 to control Media Gateways, and thus do not generally have 127 implementations of device control protocols such as H.248. Moreover, 128 Application Servers were much more likely to have HTTP [2] and SIP 129 [3] and use stimulus-markup, client-server application architectures. 131 RFC3087 [4] introduced the concept of addressing services as if they 132 were users in SIP. This meant that it was possible to address 133 specific resources from an application simply by sending the session 134 to a "user" at a media server. However, RFC3087 did not provide any 135 mechanism to achieve Internet-wide interoperability. What was needed 136 was some sort of naming convention to address the various services 137 available at the media server. The netann [5] specification provides 138 such a naming convention. 140 Recalling the functions of a multi-function IP Media Server, the 141 netann specification is directly sufficient for announcements and 142 simple conferencing. 144 For Interactive Voice Response (IVR), VoiceXML [6] provides a 145 standard method for defining voice (and now video) dialogs. However, 146 there is a need to inform the IP multifunction media server that the 147 request is for the VoiceXML service and the URI of the initial 148 document. The netann specification provides this definition. 150 What is missing is a method for enhanced conference control. 152 By enhanced conference control, we mean facilities for creating sub- 153 mixes, recording the mix or a leg, playing media into a mix or leg, 154 altering the gain on a leg or the mix as a whole, defining which 155 media is eligible for the mix, and so on. 157 To date, there have been several proposals, experimental protocols, 158 and de facto standards to address the enhanced conference control 159 problem. Factors influencing these protocols include the 160 application's media resource model (raw resources versus service 161 server), the desire to leverage existing protocol infrastructure 162 (such as using SIP Registrars for resource discovery, SIP Proxies for 163 resource location, scale, and availability), and the expectations of 164 Internet-scale deployment sizing. The following sections examine 165 these factors and then look at the various proposals to address them. 167 As a side note, two XML-based, SIP-transported media server control 168 markup languages command approximately 100% of the market: MSCML [16] 169 and MOML [17]. 171 2. Factors 173 2.1. Media Resource Model 175 As the Introduction indicated, many new applications use the Internet 176 model for media resources. That is, applications request media 177 services from an Internet-oriented, IP multi-function Media Server. 178 However, some legacy applications, as well as application developers 179 more comfortable with a telco-oriented approach, would like to model 180 the media processing function as a set of low-level resources. 182 There is no question that with a low-level model, one has the full 183 flexibility to address any possible requirement. For example, 184 creating a sidebar conference is simply the manipulation of some 185 mixer resources and plumbing the selected RTP streams (possibly 186 through transcoders) to the mixer resources. Likewise, one can 187 accomplish playing a prompt to a leg by disconnecting the leg from 188 the mixer, allocating a media player, plumbing the media player to 189 the RTP port that represents the leg, directing the media player to 190 play the prompt, then deallocate the media player, and finally re- 191 plumbing the RTP stream to the mixer. 193 Conversely, with an Internet server model, applications request media 194 manipulation using protocols appropriate for applications. For 195 example, media streams are addressed using application constructs, 196 such as SIP dialog identifiers. Rather than specifying a sidebar by 197 manipulating RTP streams directly, the application specifies which 198 legs the Media Server is to place into a sidebar. In fact, as we 199 will show below, one can specify complex topologies, such as Agent/ 200 Supervisor/Mark, with fewer messages than using a device control 201 protocol. 203 2.2. Number of Protocol Messages for a Given Operation 205 The number of protocol messages required for a given set of 206 operations is a factor that can potentially affect the scale of the 207 deployment. 209 Too many messages can result in bandwidth problems at the media 210 server control interface, packet handling problems at either the 211 media server or application server, and stack processing problems at 212 either the media server or application server. 214 Conversely, optimizing on number of messages can result in complex 215 protocols with a very large number of verbs. This is often in 216 conflict with engineering principles such as offering a simple 217 protocol with a small number of verbs. 219 2.3. Network Topology 221 In determining the control mechanism, we need to examine the control 222 topology. Namely, will there be a one-to-one mapping of Application 223 Servers to Media Servers? Will there be a one-to-many mapping of 224 Applications Servers to Media Servers? Will there be a many-to-one 225 mapping of Applications Servers to Media Servers? Or, can there be a 226 many-to-many mapping of Application Servers to Media Servers. 227 Answers to this question helps determine the question as to whether 228 there should be a single control channel per Media Server, single 229 control channel per Application Server, single control channel per 230 session, or single control channel per leg. 232 Since control channels consume operating system resources, fewer 233 control channels use fewer operating system resources. Of course, 234 overall system resource utilization is more complex than simply how 235 many channels there are at a given node. For example, on most 236 operating systems, message routing is done in kernel space with 237 pointer manipulation. However, once in application space, message 238 routing is often done with buffer copying. 240 Another aspect influencing the cardinality of control channels is 241 protocol layer integrity. We will examine this point in the next 242 section. 244 2.4. Protocol Layer Integrity 246 There are many fundamental principles driving the IETF model of 247 layered protocols. For example, a single TCP socket uses less system 248 resources that ten thousand TCP sockets. Given that, why do we have 249 FTP, TELNET, SMTP, NNTP, MGCP, etc.? It would appear to be much more 250 efficient to establish a single TCP socket between the hosts and 251 multiplex the different protocols over that socket. One of the 252 reasons we do not do this is that while we would save on memory and 253 kernel processing on the TCP socket, we end up spending memory and 254 kernel processing resources on demultiplexing the TCP stream to 255 direct the stream to the appropriate application process in user 256 space. 258 Likewise, one could multiplex a given protocol over a single channel. 259 In this case, the decision comes down to programming model. For 260 example, in the FTP case, it is easier to manage the media and 261 control separately over separate channels. Many implementations of 262 FTP has the server FTP daemon spawning separate FTP server processes 263 to handle requests. In this way the FTP server process can be quite 264 simple and straightforward. 266 Another approach has multiple requests physically multiplexed to a 267 single port, but establish separate logical sessions. One protocol 268 that uses this model is SIP. All requests go to a single port 269 (usually 5060), yet in the protocol data unit (PDU), we have a dialog 270 identifier that identifies which dialog the message belongs to. 272 The control channel per session model maintains protocol layer 273 integrity by allowing the kernel to do appropriate routing of 274 requests to the application. 276 Multiplexing the control channel requires special considerations. 278 If there is a limit of a single control channel at the Media Server, 279 then, by definition, there can be only a single Application Server 280 controlling it. This works in a device control model, such as H.248 281 [1], where a Media Gateway Controller controls an entire Media 282 Gateway. In order to allow multiple clients to control the server, 283 one must "virtualize" the server. That is, the server presents what 284 looks to the client as an entire, self-contained server, while in 285 fact those self-contained servers are actually logical partitions of 286 the physical server. 288 Depending on the server function, such partitioning may be easy or 289 extremely complex. Let us consider the case of a SIP Application 290 Server. A SIP Application Server, or Back-to-Back User Agent 291 (B2BUA), looks to the world like a whole bunch of SIP User Agent 292 Servers. This is not too difficult to manage, as the SIP User Agent 293 Servers all generally look alike. On the other hand, consider a SIP 294 Media Server. The SIP Media Server often has a fixed number of 295 different types of resources, such as announcement players, 296 conference bridges, recorders, and so on. Partitioning these 297 resources can be exceedingly complex. 299 Some applications benefit from a single control channel model. For 300 example, the classic SoftSwitch model and the current IMS model 301 assume that all media processing requests go through a single network 302 element that, in the words of TRON, is a "Master Control Program." 303 While many from the telco world are comfortable with having a large, 304 centralized system, many in the IETF have found time and time again 305 that a single central server rarely meets the requirements for 306 Internet scale. Other methods, such as server farms and alternate 307 return contact addresses, enable theoretically infinite scale. 309 2.5. Computer Science Issues 311 Two issues to consider when using a device control protocol are how 312 long it takes to create an application and the quality of the work 313 product. Two factors influencing these issues are the program length 314 and cyclomatic complexity. 316 There is an interesting result through 30 years of programmer 317 productivity studies. It turns out that with the exception of the 318 introduction of compilers, visual editors, and visual debuggers, 319 programmer productivity has been relatively constant, at 10 to 50 320 lines of code delivered per day. Thus, reducing the number of lines 321 of code required for a given function is an important tactic to 322 achieve the goal of improving either the time-to-market or robustness 323 of an application. This is one of the reasons why we code in Java, 324 C++, VB, etc., instead of assembly language. 326 Cyclomatic complexity measures the number of branches and function 327 calls in a given application. Again, 15 years of research have shown 328 a strong correlation between cyclomaitc complexity and the difficulty 329 of test and liklihood of bugs in fielded code. This is an intuitive 330 result: more branches means more test cases, or the collary, that 331 more branches means more code that testing will miss. However, the 332 emperical results are more impressive: the higher the cyclomatic 333 complexity, the more errors found in the field. 335 Here is a concrete example of how this plays out in practice. iSCSI 336 [7] defines how one can, over IP, read and write blocks on a disk. 337 One could then ask, "Why do we access data bases using data base- 338 oriented protocols, like TDS [8]?" After all, one can do all the 339 manipulation one needs for a data base application at the disk block 340 level. Moreover, one can virtualize the target disk, so the 341 application does not have to have direct control over physical disk 342 blocks. 344 We would offer the answer is obvious. Data base application 345 developers think and operate at the table access level. They don't 346 care about disk blocks, B-Trees, indices, and so on. 348 One could argue that supplying a client library that hides the data 349 base-centric operations from an application would hide the low-level 350 nature of a disk access protocol from the application. That is, it 351 would present an application-layer interface to the application. We 352 offer here that protocol layer integrity comes to play here, as well. 353 In particular, embedding data base code in the client means that one 354 cannot have any data base innovation at the server. Everything 355 occurs at, and is bound to, the client. 357 Clearly there is a need for a low-level disk access protocol. That 358 is what drove the iSCSI effort. However, application developers need 359 a file access protocol like NFS [10]; data base application 360 developers need a high-level data base access protocol; mail 361 application developers need a mail transfer protocol like SMTP [11]; 362 and so on. 364 A similar situation exists in the media processing milieu. The IETF, 365 with the ITU-T has created a media gateway control protocol, H.248 366 [1]. Although designed for the media gateway control problem, H.248 367 has capabilities for controlling arbitrary media functions, albeit at 368 a very low level. H.248, and, THE MODEL IT REPRESENTS, assumes a 369 master/slave, low-level device control programming model. This is 370 analogous to direct disk block manipulation for data access, as 371 represented by iSCSI. Features accessible via H.248 or protocols in 372 the style of H.248 include audio players, audio recorders, RTP 373 termination and origination, mixers, tone detectors and generators, 374 and plumbing primitives. 376 High-level media processing protocols have been proposed, modeling a 377 media resource server as just that, a server that offers multimedia 378 processing functions. Services offered by media servers include IVR, 379 conference mixing, announcements, interactive video, and so on. 381 Consider the choice of terms: a H.248 device offers "features" while 382 a media server offers "services". Section 3 examines the different 383 protocol proposals in detail. 385 2.6. Deployment Scale 387 Just how many sessions do we need at any given Media Server? First, 388 let us consider a Media Server that would handle ALL calls on the 389 globe. 391 Take a population of seven billion people. Let us assume that every 392 person calls one other person, on average, once every week. That 393 means we are looking at 1 billion calls per day. Calculating the 394 maximum number of simultaneous calls, let us assume that in any given 395 populated time zone, up to 1/12th of the population of the world is 396 actively making calls. The assumption here is that the time zones 397 dividing the Pacific and Atlantic Oceans are essentially unpopulated 398 (sorry Greenland and Alaska), while the time zones covering Europe 399 have a relatively high teledensity. We make this assumption as we 400 assume that busy hour will rotate around the Earth for a given 401 application. 403 With these assumptions, there are about 83 million calls per day in a 404 given time zone. Since, for most applications, 15% of calls occur 405 during the busy hour, we are looking at 12.5 million simultaneous 406 calls. 408 Now it is time for a reality check. Just how many simultaneous 409 sessions will any given Application Server or Media Server really 410 need to handle? In the above example, we found an upper limit of 411 12.5 million simultaneous sessions ASSUMING ALL CALLS IN THE WORLD GO 412 THROUGH THE APPLICATION. That is a pretty hefty assumption. 414 What if we worked it backward? Let us assume that a single 415 Application Server and Media Server provided voice messaging to the 416 entire world. Again, let us start with a population of seven billion 417 people. With a ratio of 200 subscribers per session, we get 35 418 million sessions. Taking time zones into account, we would be 419 looking at about 2 million simultaneous sessions. 421 What is the point of these calculations? It is that the argument 422 that one must have a single control channel to effectively scale 423 services is a bit disingenuous. Namely, if an Application Server 424 will be handling, say, 100 million users, only a small percentage 425 will be using the service at any given time. Moreover, if one 426 architected the Application Server to be a single node, it will have 427 to handle hundreds of thousands of inbound connections anyway. If 428 you can handle a few hundreds of thousands of simultaneous 429 connections, you can probably handle a few two- or three- hundreds of 430 thousands of connections. To put this into perspective, 100,000 431 inbound connections represents well over 2 entire IP port address 432 spaces. 434 2.7. Compatibility with SIP Model 436 Various proposals offer to use SIP in some way. The question is, 437 will one use SIP within the acceptable use of SIP, or will one use it 438 "because it is there." 440 For example, does a given protocol proposal leverage the SIP routing 441 infrastructure, or is it intended for a point-to-point deployment? 442 Does the server offer SIP-level services, or is it simply using SIP 443 to transport, or tunnel, device control commands? Does the protocol 444 preserve layer integrity, by using references in the SIP domain, or 445 does it require references to the SDP [9] or IP domain? 447 One measure of compatibility with the SIP model a given proposal 448 offers is to see what its compatibility with SIP Proxies, as defined 449 by RFC3261 [3], is. For example, does the proposal require SDP 450 manipulation? If so, how deep does the manipulation need to be? 451 Clearly, any SDP manipulation makes the protocol incompatible with 452 SIP Proxies - SDP modification requires the use of a back-to-back 453 User Agent (B2BUA). Is the B2BUA simply inserting an m-line in the 454 SDP to plumb a control channel? Is the B2BUA parsing the SDP to 455 determine RTP addresses and media types? 457 The best would be pure proxies, as this will have the highest chance 458 of avoiding compatibility issues in the future. 460 2.8. Security Issues 462 One issue is who is allowed to manipulate what at the Media Server. 463 For services like announcements, IVR, and IVVR, a straightforward 464 security model is to have commands come on the same SIP dialog as 465 what established the media connection. Clearly, if you can create 466 the connection, you have some kind of relationship with the end 467 point, if you are not the requesting end point itself. 469 Other relationships get more complicated. For example, if we have a 470 single control pipe from the Application Server, everything is OK if 471 there is only one Application Server. This is the model for H.248. 472 However, if we have more than one Application Server, then we have to 473 ensure a separation of the resources from one Application Server from 474 another. 476 One solution for this problem is to partition the Media Server into 477 multiple virtual Media Servers, each one dedicated to a given 478 Application Server. This is a suggested model in H.248. However, as 479 mentioned above in Section 2.4, this may be difficult for server- 480 centric Media Servers. 482 3. Transport Protocols 484 3.1. Pure Device Control 486 H.248 [1] is the IETF/ITU-T media gateway control protocol. H.248 487 provides generic session establishment machinery and gateway internal 488 resource interconnection. H.248 packages define various resources, 489 including tone detectors, tone generators, audio recorders, and 490 fixed-function audio prompt resources. 492 H.248 uses SDP for session negotiation, but it is considerably 493 different than SIP's SDP offer/answer [12] protocol. 495 H.248 assumes a single media gateway controller per media gateway. 496 H.248 uses a single TCP, UDP, or SCTP pipe between the controller and 497 gateway. 499 Most H.248 implementations use text encoding over the wire. For 500 those that are enamored with XML PDU's, H.248 does have an ASN.1 [13] 501 encoding. This means one can use XER [14] to have an XML wire 502 protocol. 504 3.2. Pure SIP 506 Using the netann [5] convention, one can perform basic media 507 services, such as announcements and basic mixing. However, SIP does 508 not provide the necessary controls for enhanced conferencing, such as 509 gain control, identification of preferred speakers (if they speak, 510 they have priority in the mix, even if they are not the loudest), 511 creating sidebar and other topologies (such as Coach/Agent/Mark), and 512 so on. 514 Note that Pure SIP uses a single TCP or SCTP socket. However, there 515 is a separate SIP session per leg. 517 3.3. SIP With TCP Side Channel 519 MRCPv2 [15] is an example of a media processing protocol that uses a 520 TCP side channel. In MRCPv2, the client uses SIP to route to a 521 speech server, uses SIP's SDP offer/answer [12] protocol to negotiate 522 the media codecs, and specifies the protocol machinery for 523 establishing a side channel transfer protocol, such as TCP or TLS, 524 for the actual MRCPv2 PDU's. 526 The MRCPv2 server hands back a unique session identifier to the 527 client. All subsequent messages relating to a given MRCPv2 session 528 include the session identifier. This means one can share the side 529 channel between multiple client instances on the requesting node. 530 MRCPv2 allows the client to request channel reuse or to request a new 531 channel at session establishment time. Correspondingly, the MRCPv2 532 server can insist on a side channel per session, rather than sharing 533 the side channel amongst sessions. 535 The MRCPv2 model has the benefit of using the SIP protocol machinery 536 for session establishment. This includes using the SIP security 537 mechanisms to authorize the association of the side channel with the 538 media channel. 540 MRCPv2 itself has the drawbacks of having a totally different state 541 machine. The MRCPv2 state machine is optimized for speech services 542 like speech recognition and speech synthesis. Moreover, the methods 543 are incompatible with the needs for conference control. 545 In addition, the MRCPv2 approach rules out the use of the protocol by 546 SIP Proxies, as the B2BUA must modify the SDP to insert the SDP 547 m-line for the control channel. 549 One might ask, "If all we are doing is establishing a TCP connection 550 to control the media server, what do we need SIP for?" This is a 551 reasonable question. The key is to be using SIP for media session 552 establishment. If we are using SIP for media session establishment, 553 then we need to ensure the URI used for session establishment 554 resolves to the same node as the node for session control. Using the 555 SIP routing mechanism, and having the server initiate the TCP 556 connection back, ensures this works. For example, the URI sip: 557 myserver.example.com may resolve to sip: 558 server21.farm12.northeast.example.net, whereas the URI 559 http://myserver.example.com may resolve to 560 http://server41.httpfarm.central.example.net. That is, the host part 561 is NOT NECESSARILY unambiguous. 563 3.4. SIP With INFO 565 Two proposals have been put forward that use the SIP dialog for the 566 side channel. Both use the INFO method. They are MSCML [16] and 567 MSML [18]. 569 MSCML uses the SIP Requires and Content-Type headers to ensure 570 interoperability and preservation of SIP semantics. MSCML correlates 571 the commands received on the dialog with the dialog's media streams. 572 In the case of enhanced conferences, where there are global commands 573 such as conference size, playing to the entire conference, or 574 recording the entire conference, MSCML has the concept of a 575 Conference Control Leg. The Conference Control Leg is not associated 576 with any media dialog. However, it is a SIP dialog in the normal 577 sense. 579 MSML relies on a private (non-Internet) agreement between the 580 Application Server and Media Server to know the context of the INFO 581 messages. MSML tunnels SDP-layer information over the established 582 dialog; in the case of media processing, it uses a secondary markup, 583 MOML [18]. MOML is a device control protocol, with primitives 584 similar to H.248. 586 Deployed versions of MOML/MSML do not use SIP, such as for 587 referencing entities with SIP dialog properties, using SIP semantics 588 for control, or transparently correlating SIP dialogs with RTP 589 streams. However, the current version of the MSML specification does 590 suggest using the SIP Dialog identifier to identify media sessions. 592 We will touch upon the content of what goes over the side channel in 593 Section 4. 595 Using the SIP dialog for the side channel has the benefit of using 596 the SIP routing network for getting the messages to locate and follow 597 (in the mobility case) the UAS and UAC. In particular, proxies that 598 are important for routing can Record-Route, while proxies that are 599 not needed other than for session establishment can chose to not 600 Record-Route. Thus the transport of side channel commands places 601 only a small burden on the SIP routing network. 603 Note that there are a few problems resulting from the use of INFO. 604 First, there are no throttling mechanisms, other than that provided 605 by the underlying transport mechanism (TCP or Connection-Mode SCTP). 606 If you are using UDP, you are out of luck. Second, even in the case 607 of MSCML, which is well behaved in that it is guaranteed by the SIP 608 protocol machinery that both the UAS and UAC will interoperate and 609 understand the semantics of the MSCML INFO messages, the stacks can 610 still get other, ill-behaved INFO messages that it may not 611 understand. Third, even though this has never happened in the real 612 world, there is a theoretical problem that INFO message handling may 613 overwhelm a proxy. In practice, one sizes ones proxies to the total 614 traffic they need to handle. Moreover, only active element proxies, 615 such as Edge Proxies, need Record-Route. That said, this might be a 616 problem in the future. 618 The following sections explore alternatives that use the SIP Dialog. 620 3.5. SIP With SUBSCRIBE/NOTIFY 622 As outlined in the expired draft, INFO Considered Harmful [19], the 623 events framework (SUBSCRIBE/NOTIFY) addresses all of the problems 624 with INFO. Namely, event packages must offer throttling mechanisms, 625 all event packages identify themselves and thus globally 626 interoperate, and even stupid proxies that Record-Route everything 627 often decide not to Record-Route SUBSCRIBE and NOTIFY messages. 629 Of course, SUBSCRIBE/NOTIFY really, really, really should not 630 (actually, most of us, including me, say "MUST NOT") reuse the SIP 631 dialog directly associated with the media session. This means we 632 lose the auto-correlation feature that we have by using the INFO 633 method. 635 There is a subtler, yet arguably more important problem with using 636 SUBSCRIBE/NOTIFY. Namely, the semantics of SUBSCIBE are, "tell me 637 (monitor) what is going on at the device." Typical uses for 638 SUBSCRIBE are for presence [20] (what is the state of the user?), MWI 639 [21] (what is the state of the message store?), and KPML [22] (what 640 is the state of the key press buffer?). No package changes the state 641 of the UAS. Using SUBSCRIBE, for example, to play a prompt or to 642 change the configuration of a mixer, most definitely changes the 643 state of the UAS. 645 3.6. SIP With MEDIA 647 Another approach outlined in INFO Considered Harmful [19] is to 648 introduce a new method. This was the route taken by PUBLISH [23], as 649 it was not quite NOTIFY. 651 Properly defined, a new method can safely share the SIP dialog. 652 Moreover, it would satisfy the auto-correlation properties used by, 653 for example, MSCML. Lastly, the semantics would be well defined, 654 addressing the issues raised by INFO Considered Harmful. 656 4. Models 657 4.1. H.248 659 H.248 [1] provides: 660 1. A single control channel between Application Server and Media 661 Server. 662 2. The possibility for an XML transport encoding. 663 3. Total control of media resources, at the assembly language level. 664 The first item is of use to those whom would want a single control 665 channel and socket per Application Server. The second item is of use 666 to those whom love XML. The third item ensures a measure of 667 capabilities possibility. That is, since the Application explicitly 668 defines the application-level semantics of media processing at the 669 media layer, future Applications can define future, unanticipated 670 topologies. 672 The drawbacks of H.248 are: 673 1. Layer violation et al. 674 2. Market adoption 675 The first item touches upon virtually every issue raised in 676 Section 2. By definition, H.248 is a low-level device control 677 protocol. That means more lines of code for a given function, higher 678 complexity for a given function, no compatibility with the SIP model 679 (everything becomes a MGC), and the Application Server must dive deep 680 into SDP and they media layer to do basic operations. 682 The second item, while not in itself a determining factor in the 683 IETF, is important to note as a leading indicator. For many of the 684 reasons noted above, neither Application Server developers nor Media 685 Server developers desire H.248 as an Application Server - Media 686 Server protocol. Moreover, none of the major media server 687 manufacturers have or plan to offer H.248-based media servers. In a 688 sense, the market has spoken about this option, even in light of the 689 1999 declaration (well before there were any enhanced media services) 690 by 3GPP that H.248 would be the media server (MRFP) interface. 692 4.2. MSCML 694 MSCML [16] provides: 695 1. Automatic correlation, including security associations, between 696 the control channel and the media session. 697 2. Preservation of SIP semantics, including being SIP Proxy 698 friendly. 699 3. Operations and all semantics are at the SIP dialog layer. 700 4. Application Servers can be relatively simple, as addressing of 701 media processing commands is straightforward: send the command 702 down the associated SIP media dialog. 704 5. Establishing a media session is straightforward: INVITE the Media 705 Server to a session. 706 6. Strict adherence to the philosophy espoused by, among other 707 places, the Application Interaction Framework [24]. 709 The drawbacks of MSCML include: 710 1. Even though MSCML properly uses INFO, using INFO in itself has 711 theoretical problems with non-interoperating devices. 712 2. By relying on SIP dialogs, the Application Server uses multiple 713 SIP dialogs to control, for example, an enhanced conference on 714 the Media Server. 715 3. By taking the application layer approach, MSMCL requires one to 716 two more protocol messages than a device control approach. 717 The first issue is a result of using INFO. 719 The second issue is more interesting. For example, the enhanced 720 conference case, that is, where one needs to play or record into the 721 entire conference, one has to setup an additional SIP dialog, the 722 Conference Control Dialog, per conference. In the extreme case of 723 two-party conferences, this increases the number of SIP dialogs by 724 50%. Of course, few two-party scenarios require the enhanced 725 conferencing features, and thus would not increase the number of 726 dialogs. However, if one did need those features, then the dialog 727 expansion would occur. 729 The third issue refers to the situation where the Application Server 730 wants to place the caller into a conference, but the application 731 needs to interact with the caller before the application knows which 732 conference to place them into. In the MSCML model, the application 733 has to INVITE the caller into a dialog (VoiceXML) or IVR session with 734 the caller, determine the address of the conference, and then re- 735 INVITE or REFER the caller into the conference. 737 Of course, if one uses a low-level device control markup rather than 738 an application-level markup like VoiceXML, then the number of 739 protocol messages to implement a voice dialog will swamp the extra 740 redirect message. 742 Interestingly, MSML and MSCML exchange the same number of messages to 743 do the same task. 745 The re-INVITE model offers total flexibility, in that the application 746 never has to change if the modality of the IVR step changes. For 747 example, the IVR step could be to a low-cost audio media resource, 748 which then places the caller into a high-cost, 30fps, continuous 749 presence video bridge. 751 Application Server Media Server 752 | | 753 |INVITE sip:dialog@ms.example.net | 754 |;voicexml=http://as.example.net/get-id | 755 |----------------------------------------->| 756 | | 757 |200 OK | 758 |<-----------------------------------------| 759 | | 760 |ACK | 761 |----------------------------------------->| 762 | | 763 |GET http://as.example.net/cgi-bin/get-id | 764 |<-----------------------------------------| 765 | | 766 |(VoiceXML script) | 767 |..........................................| 768 | | 769 |POST (result) | 770 |<-----------------------------------------| 771 | | 772 |REFER sip:conf=12345@ms.example.net | 773 |----------------------------------------->| 774 | | 775 |202 ACCEPTED | 776 |<-----------------------------------------| 777 | | 778 |NOTIFY | 779 |<-----------------------------------------| 780 | | 781 |200 OK (NOTIFY) | 782 |----------------------------------------->| 783 | | 784 | | 786 The downside of the re-INVITE model is that it involves the endpoint 787 in the SDP renegotiation. This puts an additional burden on the 788 Application Server and caller device to relay and act upon the 789 messages. 791 The REFER model does not involve the calling endpoint. However, it 792 does have one additional protocol message. 794 Application Server Media Server 795 | | 796 |INVITE sip:dialog@ms.example.net | 797 |;voicexml=http://as.example.net/get-id | 798 |----------------------------------------->| 799 | | 800 |200 OK | 801 |<-----------------------------------------| 802 | | 803 |ACK | 804 |----------------------------------------->| 805 | | 806 |GET http://as.example.net/cgi-bin/get-id | 807 |<-----------------------------------------| 808 | | 809 |(VoiceXML script) | 810 |..........................................| 811 | | 812 |POST (result) | 813 |<-----------------------------------------| 814 | | 815 |REFER sip:conf=12345@ms.example.net | 816 |----------------------------------------->| 817 | | 818 |202 ACCEPTED | 819 |<-----------------------------------------| 820 | | 821 |NOTIFY | 822 |<-----------------------------------------| 823 | | 824 |200 OK (NOTIFY) | 825 |----------------------------------------->| 826 | | 827 | | 829 4.3. MOML/MSML 831 MSML [18] provides: 832 1. As of the -04 draft, a SIP Dialog addressing scheme. 833 2. Arbitrarily complex mixing topologies, on a par with H.248. 834 3. With MOML [17], the audio prompt, record, DTMF detection, and 835 other functions of H.248, with the addition of access to speech 836 resources. 837 4. Switching between IVR and conferencing can be done without a re- 838 INVITE or REFER. 840 The drawbacks of MSML include: 842 1. The application has to be aware of and manipulate the media 843 resource plumbing. 844 2. With most operations on a par with H.248, why not use H.248? 845 3. The MSML model assumes everything resides in a single server, 846 especially with respect to the audio/video example given above. 848 Application Server Media Server 849 | | 850 | | 851 |INVITE sip:dialog@ms.example.net | 852 |;moml=cid:foobratz12@ms.example.net * | 853 |----------------------------------------->| 854 | | 855 |200 OK | 856 |<-----------------------------------------| 857 | | 858 |ACK | 859 |----------------------------------------->| 860 | | 861 |GET http://as.example.net/cgi-bin/get-id | 862 |<-----------------------------------------| 863 | | 864 |(VoiceXML script) | 865 |..........................................| 866 | | 867 |POST (result) | 868 |<-----------------------------------------| 869 | | 870 |INFO (MSML ) | 871 |<-----------------------------------------| 872 | | 873 |200 OK | 874 |----------------------------------------->| 875 | | 876 |INFO (MSML ) | 877 |----------------------------------------->| 878 | | 879 |200 OK | 880 |<-----------------------------------------| 881 | | 882 | | 884 * The MSML specification does not state how to start a session. We 885 assume that one starts a MOML session and then send a 886 document. The URI of the VoiceXML script, and the programming logic 887 necessary to start that script, is embedded in the MSML document sent 888 to the Media Server. 890 5. Recommendations 892 This section is in the spirit of getting a conversation started. 893 Everything here is opinion. Feel free to argue. 895 First of all, it is clear there is interest in a standard for the 896 Application Server - Media Server protocol in the Internet community. 897 The adoption of MOML/MSML in the developer community and MSCML in the 898 developer and vendor community is an existence proof of the utility 899 of, and need for, such a protocol. 901 The official impetus for this work is the XCON Media Server 902 Requirements [26]. However, in spite of the fact we have VoiceXML 903 for application level IVR specification and H.248 for low-level IVR 904 specification, people keep asking for IVR with conferencing, as 905 evidenced by the XCON requirements. The problem is this IVR 906 functionality bleeds out, and thus we need to ensure it is well 907 thought out before just tossing something in there. 909 There is a desire to leverage the SIP protocol machinery for media 910 session establishment, namely the SIP Offer/Answer protocol. 912 Application developers want to see the Media Server as a server that 913 offers application-level media processing. That is, modeling the 914 Media Server as a server that offers IVR, conference mixing, and 915 other, application-level media processing services. 917 If application developers want low-level, DSP-level media 918 manipulation, they already have an IETF protocol, H.248. 920 If application developers want a single control channel (total, 921 including session establishment) from the Application Server to the 922 Media Server, they already have an IETF protocol, H.248. 924 If application developers want an XML transport encoding for a low- 925 level protocol or a single control channel, they already have an IETF 926 protocol, H.248. 928 Assuming developers do not want H.248, what are the options? 930 INFO probably isn't it. 932 That leaves to directions to go. The first is to stick with the SIP 933 Dialog model of MSCML and the other is to stick with the side channel 934 model of MRCPv2. 936 The former would indicate a new method, such as MEDIA. The latter 937 would indicate a new establishment procedure, such as described in 938 the other MSRP [25]. 940 What does all this mean? 942 WHAT GOES DOWN THE PIPE IS AS IMPORTANT AS THE PIPE ITSELF. 944 It is easy to identify protocol abuse in the determination of the 945 control channel. However, even if we have a decent control channel 946 establishment mechanism, sending the wrong kind of messages down that 947 channel can render the protocol less than useful. 949 For example, it is great to use SIP to route messages to a media 950 server. However, if those messages emulate H.248, but encoded in 951 XML, it would be much more efficient, cleaner, and avoid the layer 952 violation by simply using H.248. You can even get H.248 in XML! 953 Just please, please, please, don't transport it in SIP or a SIP side 954 channel. 956 NOTE: This is one of the reasons I pulled out of [25] at the last 957 minute. What goes in to the pipe is as important as the pipe 958 itself. 960 6. Security Considerations 962 One issue is who is allowed to manipulate what at the Media Server. 963 For services like announcements, IVR, and IVVR, a straightforward 964 security model is to have commands come on the same SIP dialog as 965 what established the media connection. Clearly, if you can create 966 the connection, you have some kind of relationship with the end 967 point, if you are not the requesting end point itself. 969 Other relationships get more complicated. For example, if we have a 970 single control pipe from the Application Server, everything is OK if 971 there is only one Application Server. This is the model for H.248. 972 However, if we have more than one Application Server, then we have to 973 ensure a separation of the resources from one Application Server from 974 another. 976 One solution for this problem is to partition the Media Server into 977 multiple virtual Media Servers, each one dedicated to a given 978 Application Server. This is a suggested model in H.248. However, as 979 mentioned above in Section 2.4, this may be difficult for server- 980 centric Media Servers. 982 7. IANA Considerations 983 As this is an Informative exploration, there are no IANA 984 Considerations. 986 8. Informative References 988 [1] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway 989 Control Protocol Version 1", RFC 3525, June 2003. 991 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 992 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 993 HTTP/1.1", RFC 2616, June 1999. 995 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 996 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 997 Session Initiation Protocol", RFC 3261, June 2002. 999 [4] Campbell, B. and R. Sparks, "Control of Service Context using 1000 SIP Request-URI", RFC 3087, April 2001. 1002 [5] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media 1003 Services with SIP", RFC 4240, December 2005. 1005 [6] Burnett, D., Hunt, A., McGlashan, S., Porter, B., Lucas, B., 1006 Ferrans, J., Rehor, K., Carter, J., Danielsen, P., and S. 1007 Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version 1008 2.0", W3C REC REC-voicexml20-20040316, March 2004. 1010 [7] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. 1011 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 1012 RFC 3720, April 2004. 1014 [8] Sybase, Inc., "TDS 5.0 Functional Specification Version 3.4", 1015 URL http://www.sybase.com/content/1013412/tds34.pdf, 1016 August 1999. 1018 [9] Handley, M. and V. Jacobson, "SDP: Session Description 1019 Protocol", RFC 2327, April 1998. 1021 [10] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 1022 C., Eisler, M., and D. Noveck, "Network File System (NFS) 1023 version 4 Protocol", RFC 3530, April 2003. 1025 [11] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1026 April 2001. 1028 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1029 Session Description Protocol (SDP)", RFC 3264, June 2002. 1031 [13] Telecommunication Standardization Sector of International 1032 Telecommunication Union, "Abstract Syntax Notation One (ASN.1): 1033 Specification of basic notation", ITU-T Recommendation X.680, 1034 July 2002. 1036 [14] Telecommunication Standardization Sector of International 1037 Telecommunication Union, "ASN.1 encoding rules: XML Encoding 1038 Rules (XER)", ITU-T Recommendation X.693, December 2001. 1040 [15] Burnett, D. and S. Shanmugham, "Media Resource Control Protocol 1041 Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-09 (work in 1042 progress), December 2005. 1044 [16] Dyke, J., "Media Server Control Markup Language (MSCML) and 1045 Protocol", draft-vandyke-mscml-08 (work in progress), May 2006. 1047 [17] Saleem, A. and G. Sharratt, "Media Objects Markup Language 1048 (MOML)", draft-melanchuk-sipping-moml-06 (work in progress), 1049 October 2005. 1051 [18] Melanchuk, T. and G. Sharratt, "Media Sessions Markup Language 1052 (MSML)", draft-melanchuk-sipping-msml-05 (work in progress), 1053 March 2006. 1055 [19] Rosenberg, J., "The Session Initiation Protocol (SIP) INFO 1056 Method Considered Harmful", draft-rosenberg-sip-info-harmful-00 1057 (work in progress), January 2003. 1059 [20] Rosenberg, J., "A Presence Event Package for the Session 1060 Initiation Protocol (SIP)", RFC 3856, August 2004. 1062 [21] Mahy, R., "A Message Summary and Message Waiting Indication 1063 Event Package for the Session Initiation Protocol (SIP)", 1064 RFC 3842, August 2004. 1066 [22] Burger, E., "A Session Initiation Protocol (SIP) Event Package 1067 for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-07 1068 (work in progress), December 2004. 1070 [23] Niemi, A., "Session Initiation Protocol (SIP) Extension for 1071 Event State Publication", RFC 3903, October 2004. 1073 [24] Rosenberg, J., "A Framework for Application Interaction in the 1074 Session Initiation Protocol (SIP)", 1075 draft-ietf-sipping-app-interaction-framework-05 (work in 1076 progress), July 2005. 1078 [25] Boulton, C. and T. Melanchuk, "Media Server Request Protocol", 1079 draft-boulton-media-server-control-00 (work in progress), 1080 June 2005. 1082 [26] Even, R., "Requirements for a media server control protocol", 1083 draft-even-media-server-req-00 (work in progress), 1084 January 2005. 1086 Appendix A. Contributors 1088 I cannot share blame with anyone on this one. 1090 Appendix B. Acknowledgements 1092 Brooks Gelfand in 1985 made the quote, "If you cannot do it in 1093 assembly language, you cannot do it at all," during an argument I was 1094 having with another engineer about the relative merrits of C versus 1095 Lisp. 1097 The catalyst for this document was the very hard and dedicated work 1098 of Chris Boulton, Tim Melanchuk, and I to bang out the and argue over 1099 the other MSRP draft, starting in April of 2005 and lasting through 1100 the very end of June. 1102 Author's Address 1104 Eric Burger 1105 Cantata Technology, Inc. 1106 18 Keewaydin Dr. 1107 Salem, NH 03079-2839 1108 USA 1110 Phone: +1 603 890 7587 1111 Fax: +1 603 457 5944 1112 Email: eburger@cantata.com 1114 Intellectual Property Statement 1116 The IETF takes no position regarding the validity or scope of any 1117 Intellectual Property Rights or other rights that might be claimed to 1118 pertain to the implementation or use of the technology described in 1119 this document or the extent to which any license under such rights 1120 might or might not be available; nor does it represent that it has 1121 made any independent effort to identify any such rights. Information 1122 on the procedures with respect to rights in RFC documents can be 1123 found in BCP 78 and BCP 79. 1125 Copies of IPR disclosures made to the IETF Secretariat and any 1126 assurances of licenses to be made available, or the result of an 1127 attempt made to obtain a general license or permission for the use of 1128 such proprietary rights by implementers or users of this 1129 specification can be obtained from the IETF on-line IPR repository at 1130 http://www.ietf.org/ipr. 1132 The IETF invites any interested party to bring to its attention any 1133 copyrights, patents or patent applications, or other proprietary 1134 rights that may cover technology that may be required to implement 1135 this standard. Please address the information to the IETF at 1136 ietf-ipr@ietf.org. 1138 Disclaimer of Validity 1140 This document and the information contained herein are provided on an 1141 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1142 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1143 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1144 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1145 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1146 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1148 Copyright Statement 1150 Copyright (C) The Internet Society (2006). This document is subject 1151 to the rights, licenses and restrictions contained in BCP 78, and 1152 except as set forth therein, the authors retain all their rights. 1154 Acknowledgment 1156 Funding for the RFC Editor function is currently provided by the 1157 Internet Society.