idnits 2.17.1 draft-ietf-mediactrl-mrb-19.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 date (February 18, 2013) is 4078 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) == Missing Reference: '0-9' is mentioned on line 5652, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.Q.1950' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft NS-Technologies 4 Intended status: Standards Track L. Miniero 5 Expires: August 22, 2013 Meetecho 6 G. Munson 7 AT&T 8 February 18, 2013 10 Media Resource Brokering 11 draft-ietf-mediactrl-mrb-19 13 Abstract 15 The MediaCtrl work group in the IETF has proposed an architecture for 16 controlling media services. The Session Initiation Protocol (SIP) is 17 used as the signalling protocol which provides many inherent 18 capabilities for message routing. In addition to such signalling 19 properties, a need exists for intelligent, application level media 20 service selection based on non-static signalling properties. This is 21 especially true when considered in conjunction with deployment 22 architectures that include 1:M and M:N combinations of Application 23 Servers and Media Servers. This document introduces a Media Resource 24 Broker (MRB) entity which manages the availability of Media Servers 25 and the media resource demands of Application Servers. The document 26 includes potential deployment options for an MRB and appropriate 27 interfaces to Application Servers and Media Servers. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 22, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 65 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . 8 66 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 9 67 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . 10 69 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . 11 70 5. MRB Interface Definitions . . . . . . . . . . . . . . . . . . 14 71 5.1. Media Server Resource Publish Interface . . . . . . . . 14 72 5.1.1. Control Package Definition . . . . . . . . . . . . . 15 73 5.1.2. Element Definitions . . . . . . . . . . . . . . . . . 16 74 5.1.3. . . . . . . . . . . . . . . . . . . . . 17 75 5.1.4. . . . . . . . . . . . . . . . . . . . . 19 76 5.1.5. . . . . . . . . . . . . . . . . . . 20 77 5.2. Media Service Resource Consumer Interface . . . . . . . 31 78 5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 32 79 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 32 80 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 36 81 5.2.4. . . . . . . . . . . . . . . . . . . . . 38 82 5.2.5. Media Service Resource Request . . . . . . . . . . . 39 83 5.2.6. Media Service Resource Response . . . . . . . . . . . 50 84 5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . 53 85 6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 55 86 7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 56 87 8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 57 88 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 59 89 9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 59 90 9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 64 91 9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 64 92 9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 67 93 10. Media Service Resource Publisher Interface XML Schema . . . . 83 94 11. Media Service Resource Consumer Interface XML Schema . . . . 106 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 127 96 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 97 13.1. Media Control Channel Framework Package Registration . . 130 98 13.2. application/mrb-publish+xml Media Type . . . . . . . . . 130 99 13.3. application/mrb-consumer+xml Media Type . . . . . . . . 131 100 13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 132 101 13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 132 102 13.6. XML Schema Registration for mrb-publish . . . . . . . . 132 103 13.7. XML Schema Registration for mrb-consumer . . . . . . . . 133 104 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 105 14.1. Changes from 13 Version . . . . . . . . . . . . . . . . 134 106 14.2. Changes from 12 Version . . . . . . . . . . . . . . . . 134 107 14.3. Changes from 11 Version . . . . . . . . . . . . . . . . 134 108 14.4. Changes from 10 Version . . . . . . . . . . . . . . . . 134 109 14.5. Changes from 09 Version . . . . . . . . . . . . . . . . 135 110 14.6. Changes from 08 Version . . . . . . . . . . . . . . . . 135 111 14.7. Changes from 07 Version . . . . . . . . . . . . . . . . 135 112 14.8. Changes from 06 Version . . . . . . . . . . . . . . . . 136 113 14.9. Changes from 05 Version . . . . . . . . . . . . . . . . 136 114 14.10. Changes from 04 Version . . . . . . . . . . . . . . . . 136 115 14.11. Changes from 03 Version . . . . . . . . . . . . . . . . 136 116 14.12. Changes from 02 Version . . . . . . . . . . . . . . . . 137 117 14.13. Changes from 01 Version . . . . . . . . . . . . . . . . 137 118 14.14. Changes from 00 Version . . . . . . . . . . . . . . . . 137 119 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 138 120 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 139 121 16.1. Normative References . . . . . . . . . . . . . . . . . . 139 122 16.2. Informative References . . . . . . . . . . . . . . . . . 140 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 142 125 1. Introduction 127 As IP based multimedia infrastructures mature, the complexity and 128 demands from deployments increase. Such complexity will result in a 129 wide variety of capabilities from a range of vendors that should all 130 be interoperable using the architecture and protocols produced by the 131 MediaCtrl work group. It should be possible for a controlling entity 132 to be assisted in Media Server selection so that the most appropriate 133 resource is selected for a particular operation. The importance 134 increases when you introduce a flexible level of deployment 135 scenarios, as specified in the RFC 5167 [RFC5167] and RFC 5567 136 [RFC5567] documents. These documents make statements like "it should 137 be possible to have a many-to-many relationship between Application 138 Servers and Media Servers that use this protocol". This leads to the 139 following deployment architectures being possible when considering 140 media resources, to provide what can be effectively described as 141 Media Resource Brokering. 143 The simplest deployment view is illustrated in Figure 1. 145 +---+-----+---+ +---+-----+---+ 146 | Application | | Media | 147 | Server |<-------MS Control------>| Server | 148 +-------------+ +-------------+ 150 Figure 1: Basic Architecture 152 This simply involves a single Application Server and Media Server. 153 Expanding on this view, it is also possible for an Application Server 154 to control multiple (greater that 1) Media Server instances at any 155 one time. This deployment view is illustrated in Figure 2. 156 Typically, such architectures are associated with application logic 157 that requires high demand media services. It is more than possible 158 that each media server possesses a different media capability set. 159 Media servers may offer different media services as specified in the 160 Mediactrl architecture document. A Media server may have similar 161 media functionality but may have different capacity or media codec 162 support. 164 +---+-----+---+ 165 | Media | 166 +----->| Server | 167 | +-------------+ 168 | 169 +---+-----+---+ | +---+-----+---+ 170 | Application | | | Media | 171 | Server |<--MS Control-----+----->| Server | 172 +-------------+ | +-------------+ 173 | 174 | +---+-----+---+ 175 +----->| Media | 176 | Server | 177 +-------------+ 179 Figure 2: Multiple Media Servers 181 Figure 3 conveys the opposite view to that in Figure 2. In this 182 model there are a number of (greater than 1) application servers, 183 possibly supporting dissimilar applications, controlling a single 184 media server. Typically, such architectures are associated with 185 application logic that requires low demand media services. 187 +---+-----+---+ 188 | Application | 189 | Server |<-----+ 190 +-------------+ | 191 | 192 +---+-----+---+ | +---+-----+---+ 193 | Application | | | Media | 194 | Server |<-----+-----MS Control-->| Server | 195 +-------------+ | +-------------+ 196 | 197 +---+-----+---+ | 198 | Application | | 199 | Server |<-----+ 200 +-------------+ 202 Figure 3: Multiple Application Servers 204 The final deployment view is the most complex. In this model (M:N) 205 there exists any number of Application Servers and any number of 206 Media Servers. It is again possible in this model that media servers 207 might not be homogeneous and have different capability sets and 208 capacity. 210 +---+-----+---+ +---+-----+---+ 211 | Application | | Media | 212 | Server |<-----+ +---->| Server | 213 +-------------+ | | +-------------+ 214 | | 215 +---+-----+---+ | | +---+-----+---+ 216 | Application | | | | Media | 217 | Server |<-----+-MS Control-+---->| Server | 218 +-------------+ | | +-------------+ 219 | | 220 +---+-----+---+ | | +---+-----+---+ 221 | Application | | +---->| Media | 222 | Server |<-----+ | Server | 223 +-------------+ +---+-----+---+ 225 Figure 4: Basic Architecture 227 The remaining sections in this specification will focus on a new 228 entity called a Media Resource Broker (MRB) which can be utilised in 229 the deployment architectures described previously in this section. 230 The MRB entity provides the ability to obtain media resource 231 information and appropriately allocate(broker) on behalf of client 232 applications. 234 The high level deployment options discussed in this section rely on 235 network architecture and policy to prohibit inappropriate use. Such 236 policies are out of the scope of this document. 238 This document will take a look at the specific problem areas related 239 to such deployment architectures. It is recognised that the 240 solutions proposed in this document should be equally adaptable to 241 all of the previously described deployment models. It is also 242 recognised that the solution is far more relevant to some of the 243 previously discussed deployment models and can almost be viewed as 244 redundant on others. 246 2. Conventions and Terminology 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 250 document are to be interpreted as described in RFC 2119 [RFC2119]. 252 This document inherits terminology proposed in RFC 5567 [RFC5567] and 253 Media Control Channel Framework [RFC6230] documents. In addition, 254 the following terms are defined for use in this document and for use 255 in the context of the MediaCtrl Work group in the IETF: 257 Media Resource Broker (MRB): A logical entity that is responsible 258 for both collection of appropriate published Media Server (MS) 259 information and selecting appropriate Media Server resources on 260 behalf of consuming entities. 262 Query MRB: An instantiation of an MRB (See previous definition) 263 that provides an interface for an Application Server to retrieve 264 the address of an appropriate Media Server. The result returned 265 to the Application Server can be influenced by information 266 contained in the query request. 268 In-line MRB: An instantiation of an MRB (See previous definition) 269 that directly receives requests on the signalling path. There is 270 no separate query. 272 CFW: Media Control Channel Framework, as specified in [RFC6230]. 274 Within the context of In-line MRBs, additional terms are defined: 276 In-line Aware MRB Mode (IAMM): Defined in Section 5.2.2.1. 278 In-line Unaware MRB Mode (IUMM): Defined in Section 5.3. 280 The document will often specify when a specific identifier in a 281 protocol message needs to be unique. Unless stated otherwise, such 282 uniqueness will always be within the scope of the Media Servers 283 controlled by the same Media Resource Broker. The interaction 284 between different Media Resource Broker instances, as the 285 partitioning of a logical Media Resource Broker, is out of scope to 286 this document. 288 3. Problem Discussion 290 As discussed in Section 1, a goal of the MediaCtrl group is to 291 produce a solution that will service a wide variety of deployment 292 architectures. Such architectures range from the simplest 1:1 293 relationship between Media Servers and Application Servers to 294 potentially linearly scaling 1:M, M:1 and M:N deployments. 296 Managing such deployments is itself non-trivial for the proposed 297 solution until an additional number of factors are included into the 298 equation that increase complexity. As Media Servers evolve it must 299 be taken into consideration that, where many can exist in a 300 deployment, they may not have been produced by the same vendor and 301 may not have the same capability set. It should be possible for an 302 Application Server that exists in a deployment to select a Media 303 Service based on a common, appropriate capability set. In 304 conjunction with capabilities, it is also important to take available 305 resources into consideration. The ability to select an appropriate 306 Media Service function is an extremely useful feature but becomes 307 even more powerful when considered with available resources for 308 servicing a request. 310 In conclusion, the intention is to create a tool set that allows 311 MediaCtrl deployments to effectively utilize the available media 312 resources. It should be noted that in the simplest deployments where 313 only a single media server exists, an MRB function is probably not 314 required. Only a single capability set exists and resource 315 availability can be handled using the appropriate underlying 316 signalling, e.g., SIP response. This document does not prohibit such 317 uses of an MRB, it simply provides the tools for various entities to 318 interact where appropriate. It is also worth noting that the 319 functions specified in this document aim to provide a 'best effort' 320 view of media resources at the time of request for initial Media 321 Server routing decisions. Any dramatic change in media capabilities 322 or capacity after a request has taken place should be handled by the 323 underlying protocol. 325 It should be noted that there may be additional information that it 326 is desirable for the MRB to have for purposes of selecting a Media 327 Server resource, such as resource allocation rules across different 328 applications, planned or unplanned downtime of Media Server 329 resources, the planned addition of future Media Server resources, or 330 Media Server resource capacity models. How the MRB acquires such 331 information is outside the scope of this document. The specific 332 techniques used for selecting an appropriate Media Resource by an MRB 333 is also outside the scope of this document. 335 4. Deployment Scenario Options 337 Research into Media Resource Brokering concluded that a couple of 338 high level models provided an appropriate level of flexibility. The 339 general principles of "in-line" and "query" MRB concepts are 340 discussed in the rest of this section. It should be noted that while 341 the interfaces are different they both use common underlying 342 mechanisms defined in this specification. 344 4.1. Query MRB 346 The "Query" model for MRB interactions provides the ability for a 347 client of media services (for example an Application Server) to "ask" 348 an MRB for an appropriate Media Server, as illustrated in Figure 5. 350 +---+-----+---+ 351 +------------>| MRB |<----------+----<-----+---+ 352 | +-------------+ (1)| | | 353 | | | | 354 |(2) +---+--+--+---+ | | 355 | | Media | | | 356 | +---->| Server | | | 357 | | +-------------+ | | 358 | | (1)| | 359 +---+--+--+---+ | +---+-----+---+ | | 360 | Application | | | Media | | | 361 | Server |<-----+-MS Control-+---->| Server |->-+ | 362 +-------------+ (3) | +-------------+ | 363 | | 364 | +---+-----+---+ (1)| 365 +---->| Media | | 366 | Server |--->---+ 367 +---+-----+---+ 369 Figure 5: Query MRB 371 In this deployment, the Media Servers use the "Media Server Resource 372 Publish Interface", as discussed in Section 5.1, to convey capability 373 sets as well as resource information. This is depicted by (1) in 374 Figure 5. It is then the MRB's responsibility to accumulate all 375 appropriate information relating to media services in the logical 376 deployment cluster. The Application Server (or other media services 377 client) is then able to query the MRB for an appropriate resource (as 378 identified by (2) in Figure 5). Such a query would carry specific 379 information related to the Media Service required and enable the MRB 380 to provide an increased accuracy in its response. This particular 381 interface is discussed in "Media Resource Consumer Interface" in 382 Section 5.2. The Application Server is then able to direct control 383 commands (for example create conference) and Media Dialogs to the 384 appropriate Media Server, as shown by (3) in Figure 5. Additionally, 385 with Query mode, the MRB is not directly in the signalling path 386 between the Application Server and the selected Media Server 387 resource. 389 4.1.1. Hybrid Query MRB 391 As mentioned previously, it is the intention that a tool kit is 392 provided for MRB functionality within a MediaCtrl architecture. It 393 is expected that in specific deployment scenarios the role of the MRB 394 might be co-hosted as a hybrid logical entity with an Application 395 Server, as shown in Figure 6. 397 +------------<----------------<---------+----<-----+---+ 398 | (1) | | | 399 | | | | 400 | +---+--+--+---+ | | 401 | | Media | | | 402 V +---->| Server | | | 403 +------+------+ | +-------------+ | | 404 | MRB | | | | 405 +---+--+--+---+ | +---+-----+---+ | | 406 | Application | | | Media | | | 407 | Server |<-----+-MS Control-+---->| Server |->-+ | 408 +-------------+ | +-------------+ | 409 | | 410 | +---+-----+---+ | 411 +---->| Media | | 412 | Server |--->---+ 413 +---+-----+---+ 415 Figure 6: Hybrid Query MRB - Application Server Hosted 417 This diagram is identical to that in Figure 5 with the exception that 418 the MRB is now hosted on the Application Server. The "Media Server 419 Publish Interface" is still being used to accumulate resource 420 information at the MRB but as it is co-hosted on the Application 421 Server, the "Media Server Consumer Interface" has collapsed. It 422 might still exist within the Application Server/MRB interaction but 423 this is an implementation issue. This type of deployment suits a 424 single Application Server environment but it should be noted that a 425 "Media Server Consumer Interface" could then be offered from the 426 hybrid if required. 428 In a similar manner, the Media Server could also act as a hybrid for 429 the deployment cluster, as illustrated in Figure 7. 431 (1) +---+-----+---+ 432 +---+---+------------->---------------->----------->| MRB | 433 | | | +---+--+--+---+ +---+-----+---+ 434 | | +-<-| Application | | Media | 435 | | | Server |<--+-MS Control-+------->| Server | 436 | | +-------------+ | +-------------+ 437 | | | 438 | | +---+--+--+---+ | 439 | +---<---| Application | | 440 | | Server |<--+-MS Control-+--+ 441 | +-------------+ | 442 | | 443 | +---+--+--+---+ | 444 +---<-------| Application | | 445 | Server |<--+-MS Control-+--+ 446 +-------------+ 448 Figure 7: Hybrid Query MRB - MS Hosted 450 In this example, the MRB has collapsed and is co-hosted by the Media 451 Server. The "Media Server Consumer Interface" is still available to 452 the Application Servers (1) to query Media Server resources. The 453 "Media Server Publish Interface" has collapsed onto the Media Server. 454 It might still exist within the Media Server/MRB interaction but this 455 is an implementation issue. This type of deployment suits a single 456 Media Server environment but it should be noted that a "Media Server 457 Publish Interface" could then be offered from the hybrid if required. 458 A typical use case scenario for such a topology would be a single 459 Media Server representing a pool of MSs in a cluster. In this case, 460 the MRB would actually be handling a cluster of Media Servers, rather 461 than one. 463 4.2. In-Line MRB 465 The "In-line" MRB is architecturally different from the "Query" model 466 discussed in the previous section. The concept of a separate query 467 disappears. The client of the MRB simply uses the media resource 468 control and media dialog signalling to involve the MRB. This type of 469 deployment is illustrated in Figure 8. 471 +-------<----------+----<-------+---+ 472 | | (1) | | 473 | | | | 474 | +---+--+--+---+ | | 475 | | Media | | | 476 | +------>| Server | | | 477 | |(3) +-------------+ | | 478 | | (1)| | 479 +---+--+--+---+ | | +---+-----+---+ | | 480 | Application | (2) +---+--V--+---+ (3) | Media | | | 481 | Server |----->| MRB |----->| Server |->-+ | 482 +-------------+ +---+-----+---+ +-------------+ | 483 | | 484 | (3) +---+-----+---+ (1)| 485 +------>| Media | | 486 | Server |--->---+ 487 +---+-----+---+ 489 Figure 8: In-line MRB 491 The Media Servers still use the 'Media Server Publish Interface' to 492 convey capabilities and resources to the MRB - as illustrated by (1). 493 The media server Control (and Media dialogs as well, if required) are 494 sent to the MRB (2) which then selects an appropriate Media Server 495 (3) and remain in the signalling path between the Application Server 496 and the Media Server resources. 498 In-line MRB can be split into two distinct logical roles which can be 499 applied on a per request basis. They are: 501 In-line Unaware MRB Mode (IUMM): Allows an MRB to act on behalf of 502 clients requiring media services who are not aware of an MRB or 503 its operation. In this case the Application Server does not 504 provide explicit information on the kind of Media Server resource 505 it needs (as in Section 5.2) and the MRB is left to deduce it by 506 potentially inspecting other information in the request from the 507 Application Server; for example, SDP content, or address of the 508 requesting Application Server, or additional Request-URI 509 parameters as per RFC 4240 [RFC4240]. 511 In-line Aware MRB Mode (IAMM): Allows an MRB to act on behalf of 512 clients requiring media services who are aware of an MRB and its 513 operation. In particular it allows the Application Server to 514 explicitly convey matching characteristics to those provided by 515 media servers, as does the Query MRB mode (as in Section 5.2). 517 In either of the previously described roles, signalling as specified 518 by the Media Control Channel Framework ([RFC6230]) would be involved, 519 and the MRB would deduce that the selected Media Server resources are 520 no longer needed when the Application Server or Media Server 521 terminates the corresponding SIP dialog. The two modes are discussed 522 in more detail in Section 5.3. 524 5. MRB Interface Definitions 526 The intention of this specification is to provide a tool-kit for a 527 variety of deployment architectures where media resource brokering 528 can take place. Two main interfaces are required to support the 529 differing requirements. The two interfaces are described in the 530 remainder of this section and have been named the 'Media Server 531 Resource Publish' and 'Media Server Resource Consumer' interfaces. 533 It is beyond the scope of this document to define exactly how to 534 construct an MRB using the interfaces described. It is, however, 535 important that the two interfaces are complimentary so that 536 development of appropriate MRB functionality is supported. 538 5.1. Media Server Resource Publish Interface 540 The Media Server Resource Publish interface is responsible for 541 providing an MRB with appropriate Media Server resource information. 542 As such, this interface is assumed to provide both general and 543 specific details related to Media Server resources. This information 544 needs to be conveyed using an industry standard mechanism to provide 545 increased levels of adoption and interoperability. A Control Package 546 for the Media Control Channel Framework will be specified to fulfil 547 this interface requirement. It provides an establishment and 548 monitoring mechanism to enable a Media Server to report appropriate 549 statistics to an MRB. The Publish interface is used with both Query 550 and In-line modes of MRB operation. 552 As already discussed in the Section 1, the MRB view of Media Server 553 resource availability will in reality be approximate - i.e., partial 554 and imperfect. The MRB Publish interface does not provide an 555 exhaustive view of current Media Server resource consumption, the 556 Media Server may in some cases provide a best-effort computed view of 557 resource consumption parameters conveyed in the Publish interface 558 (e.g., DSP's with a fixed number of streams versus GPU's with CPU 559 availability). Media Resource information may only be reported 560 periodically over the Publish interface to an MRB. 562 It is also worth noting that, while the scope of the MRB is in 563 providing interested Application Servers with the available 564 resources, the MRB also allows for the retrieval of information about 565 consumed resources. While this is of course a relevant piece of 566 information (e.g., for monitoring purposes), such functionality 567 inevitably raises security considerations, and implementations should 568 take this into account. See Section 12 for more details. 570 The MRB Publish interface uses the Media Control Channel Framework 571 ([RFC6230]) as the basis for interaction between a Media Server and 572 an MRB. The Media Control Channel Framework uses an extension 573 mechanism to allow specific usages which are known as control 574 packages. Section 5.1.1 defines the control package that MUST be 575 implemented by any Media Server wanting to interact with an MRB 576 entity. 578 5.1.1. Control Package Definition 580 This section fulfils the mandatory requirement for information that 581 must be specified during the definition of a Control Framework 582 Package, as detailed in Section 8 of [RFC6230]. 584 5.1.1.1. Control Package Name 586 The Media Channel Control Framework requires a Control Package 587 definition to specify and register a unique name and version. 589 The name and version of this Control Package is "mrb-publish/1.0". 591 5.1.1.2. Framework Message Usage 593 The MRB publish interface allows a media server to convey available 594 capabilities and resources to an MRB entity. 596 This package defines XML elements in Section 5.1.2 and provides an 597 XML Schema in Section 10. 599 The XML elements in this package are split into requests, responses 600 and event notifications. Requests are carried in CONTROL message 601 bodies; element is defined as a package request. This 602 request can be used for creating new subscriptions and updating/ 603 removing existing subscriptions. Event notifications are also 604 carried in CONTROL message bodies; the element is 605 defined for package event notifications. Responses are carried 606 either in REPORT message or Control Framework 200 response bodies; 607 the element is defined as a package level response. 609 Note that package responses are different from framework response 610 codes. Framework error response codes (see Section 7 of [RFC6230]) 611 are used when the request or event notification is invalid; for 612 example, a request has invalid XML (400), or is not understood (500). 613 Package level responses are carried in framework 200 response or 614 REPORT message bodies. This package's response codes are defined in 615 Section 5.1.4. 617 5.1.1.3. Common XML Support 619 The Media Control Channel Framework [RFC6230] requires a Control 620 Package definition to specify if the attributes for media dialog or 621 conference references are required. 623 The Publish interface defined in Section 10 does import and make use 624 of the common XML schema defined in the Media Control Channel 625 Framework. 627 The Consumer interface defined in Section 11 does import and make use 628 of the common XML schema defined in the Media Control Channel 629 Framework. 631 5.1.1.4. CONTROL Message Body 633 A valid CONTROL body message MUST conform to the schema defined in 634 Section 10 and described in Section 5.1.2. XML messages appearing in 635 CONTROL messages MUST contain either a or 636 element. 638 5.1.1.5. REPORT Message Body 640 A valid REPORT body MUST conform to the schema defined in Section 10 641 and described in Section 5.1.2. XML messages appearing in REPORT 642 messages MUST contain a element. 644 5.1.1.6. Audit 646 The 'mrb-publish/1.0' Media Control Channel Framework package does 647 not require any additional auditing capability. 649 5.1.2. Element Definitions 651 This section defines the XML elements for the Publish interface Media 652 Control Channel package defined in Section 5.1. The formal XML 653 schema definition for the Publish interface can be found in 654 Section 10. 656 The root element is . All other XML elements (requests, 657 responses, notifications) are contained within it. The MRB Publish 658 interface request element is detailed in Section 5.1.3. The MRB 659 Publish interface notification element is detailed in Section 5.1.5. 660 MRB Publish interface response element is contained in Section 5.1.4. 662 The element has the following attributes: 664 version: a token specifying the mrb-publish package version. The 665 value is fixed as '1.0' for this version of the package. The 666 attribute MUST be present. 668 The element has the following child elements, and there 669 MUST NOT be more than one such child element in any 670 message: 672 for sending an MRB request. See Section 5.1.3. 674 for sending an MRB response. See Section 5.1.4. 676 for sending an MRB notification. See 677 Section 5.1.5. 679 5.1.3. 681 This section defines the element used to initiate 682 requests from an MRB to a Media Server. The element describes 683 information relevant for the interrogation of a media server. 685 The element has no defined attributes. 687 The element has the following child elements: 689 for initiating a subscription to a Media Server 690 from an MRB. See Section 5.1.3.1. 692 5.1.3.1. 694 The element is included in a request from an MRB to a 695 Media Server to provide the details relating to the configuration of 696 updates (known as a subscription session). This element can be used 697 either to request a new subscription or to update an existing one 698 (e.g., to change the frequency of the updates), and to remove ongoing 699 subscriptions as well (e.g., to stop an indefinite update). The MRB 700 will inform the Media Server how long it wishes to receive updates 701 for and the frequency that updates should be sent. Updates related 702 to the subscription are sent using the element. 704 The element has the following attributes: 706 id: indicates a unique token representing the subscription session 707 between the MRB and the Media Server. The attribute MUST be 708 present. 710 seqnumber: indicates a sequence number to be used in conjunction 711 with the subscription session id to identify a specific 712 subscription command. The first subscription MUST contain a non- 713 zero number 'seqnumber', and following subscriptions MUST contain 714 a higher number that the previous 'seqnumber' value. If a 715 subsequent 'seqnumber' is not higher, a 405 response code is 716 generated as per section Section 5.1.4. The attribute MUST be 717 present. 719 action: provides the operation that should be carried out on the 720 subscription: 722 * The value of 'create' instructs the Media Server to attempt to 723 set-up a new subscription. 725 * The value of 'update' instructs the Media Server to attempt to 726 update an existing subscription. 728 * The value of 'remove' instructs the Media Server to attempt to 729 remove an existing subscription and consequently stop any 730 ongoing related notification. 732 The attribute MUST be present. 734 The element has zero or more of the following child 735 elements: 737 : Provides the amount of time in seconds that a 738 subscription should be installed for notifications at the Media 739 Server. Once the amount of time has passed, the subscription 740 expires and the MRB has to subscribe again in case it is still 741 interested in receiving notifications from the Media Server. The 742 element MAY be present. 744 : Provides the minimum frequency in seconds that the 745 MRB wishes to receive notifications from the Media Server. The 746 element MAY be present. 748 : Provides the maximum frequency in seconds that the 749 MRB wishes to receive notifications from the Media Server. The 750 element MAY be present. 752 Please note that these three optional pieces of information provided 753 by the MRB only act as a suggestion: the Media Server MAY change the 754 proposed values if it considers the suggestions unacceptable (e.g., 755 if the MRB has requested a too high notification frequency). In such 756 case, the request would not fail, but the updated, acceptable values 757 would be reported in the accordingly. 759 5.1.4. 761 Responses to requests are indicated by a element. 763 The element has the following attributes: 765 status: numeric code indicating the response status. The attribute 766 MUST be present. 768 reason: string specifying a reason for the response status. The 769 attribute MAY be present. 771 The element has zero or more of the following child 772 elements: 774 for providing details related to a subscription a 775 Media Server requested (see below in this section). 777 The following status codes are defined for 'status': 779 +-----------+-------------------------------------------------------+ 780 | code | description | 781 +-----------+-------------------------------------------------------+ 782 | 200 | OK | 783 | | | 784 | 400 | Syntax error | 785 | | | 786 | 401 | Unable to create Subscription | 787 | | | 788 | 402 | Unable to update Subscription | 789 | | | 790 | 403 | Unable to remove Subscription | 791 | | | 792 | 404 | Subscription does not exist | 793 | | | 794 | 405 | Wrong sequence number | 795 | | | 796 | 406 | Subscription already exists | 797 | | | 798 | 420 | Unsupported attribute or element | 799 +-----------+-------------------------------------------------------+ 801 Table 1: status codes 803 In case a new subscription request made by an MRB (action='create') 804 has been accepted, the Media Server MUST reply with a 805 with status code 200. The same rule applies whenever a request to 806 update (action='update') or remove (action='remove') an existing 807 transaction can be fulfilled by the Media Server. 809 A subscription request, nevertheless, may fail for several reasons. 810 In such a case, the status codes defined in Table 1 must be used 811 instead. Specifically, if the Media Server fails to handle a request 812 due to a syntax error in the request itself (e.g., incorrect XML, 813 violation of the schema constraints or invalid values in any of the 814 attributes/elements) the Media Server MUST reply with a 815 with status code 400. If a syntactically correct request fails 816 because the request also includes any attribute/element the Media 817 Server doesn't understand, the Media Server MUST reply with a 818 with status code 420. If a syntactically correct 819 request fails because the MRB wants to create a new subscription, but 820 the provided unique 'id' for the subscription already exists, the 821 Media Server MUST reply with a with status code 406. 822 If a syntactically correct request fails because the MRB wants to 823 update/remove a subscription that doesn't exist, the Media Server 824 MUST reply with a with status code 404. If the Media 825 Server is unable to accept a request for any other reason (e.g., the 826 MRB has no more resources to fulfil the request), the Media Server 827 MUST reply with a with status code 401/402/403, 828 depending on the action the MRB provided in its request: 830 o action='create' --> 401; 832 o action='update' --> 402; 834 o action='remove' --> 403; 836 A response to a subscription request that has a status of "200" 837 indicates that the request is successful. The response MAY also 838 contain a child that describes the subscription. The 839 child MAY contain 'expires', 'minfrequency' and 840 'maxfrequency' values even if they were not contained in the request. 842 The Media Server can choose to change the suggested 'expires', 843 'minfrequency' and 'maxfrequency' values provided by the MRB in its 844 , if it considers them unacceptable (e.g., the requested 845 frequency range is too high). In such a case, the response MUST 846 contain a element describing the subscription as the 847 Media Server accepted it, and the Media Server MUST include in the 848 element all of those values that it modified relative 849 to the request, to inform the MRB about the change. 851 5.1.5. 853 The element is included in a request from a Media 854 Server to an MRB to provide the details relating current status. The 855 Media Server will inform the MRB of its current status as defined by 856 the information in the element. Updates are sent 857 using the element. 859 The element has the following attributes: 861 id: indicates a unique token representing the session between the 862 MRB and the Media Server and is the same as the one appearing in 863 the element. The attribute MUST be present. 865 seqnumber: indicates a sequence number to be used in conjunction 866 with the subscription session id to identify a specific 867 notification update. The first notification update MUST contain a 868 non-zero number 'seqnumber', and following notification updates 869 MUST contain a higher number that the previous 'seqnumber' value. 870 If a subsequent 'seqnumber' is not higher the situation should be 871 considered an error by the entity receiving the notification 872 update. It is implementation specific how the receiving entity 873 deals with this situation. The attribute MUST be present. 875 It's important to point out that the 'seqnumber' that appears in a 876 is not related to the 'seqnumber' appearing in a 877 . In fact, the latter is associated with 878 subscriptions and would increase at every command issued by the MRB, 879 while the former is associated with the asynchronous notifications 880 the Media Server would trigger according to the subscription, and as 881 such would increase at every notification message to enable the MRB 882 keep track of them. 884 The following subsections provide details of the child elements that 885 are the content of the element. 887 5.1.5.1. 889 The element provides a unique system wide 890 identifier for a Media Server instance. The element MUST be present, 891 and MUST chosen such that it is extremely unlikely that two different 892 media servers would present the same id to a given MRB. 894 5.1.5.2. 896 The element provides the list of Media Control 897 Channel Packages supported by the media server. The element MAY be 898 present. 900 The element has no attributes. 902 The element has zero or more of the following 903 child elements: 905 : The element gives the name of a package 906 supported by the media server. The element has a single 907 attribute, 'name', which provides the name of the supported Media 908 Control Channel Framework package, compliant with the Section 909 13.1.1 of [RFC6230]. 911 5.1.5.3. 913 The element provides information detailing the 914 current active Real-time Transport Protocol(RTP) sessions. The 915 element MAY be present. 917 The element has no attributes. 919 The element has zero or more of the following 920 child elements: 922 : Describes a supported codec and the number of active 923 sessions using that codec. The element has one 924 attribute. The value of the attribute 'name' is a media type 925 (which can include parameters per [RFC6381]). The 926 element has two child elements. The child element, , 927 has as content the decimal number of RTP sessions being decoded 928 using the specified codec. The child element, , has as 929 content the decimal number of RTP sessions being encoded using the 930 specified codec. 932 5.1.5.4. 934 The element provides information detailing 935 the current active mixed RTP sessions. The element MAY be present. 937 The element has no attributes. 939 The element has zero or more of the following 940 child elements: 942 : Describes a mixed active RTP session. The element has one attribute. The value of the attribute 944 'conferenceid' is the name of the mix. The element 945 has one child element. The child element, , contains 946 the same information relating to RTP sessions as defined in 947 Section 5.1.5.3. The element MAY be present. 949 5.1.5.5. 951 The element provides information detailing 952 the currently available inactive RTP sessions, that is, how many more 953 RTP streams this Media Server can support. The element MAY be 954 present. 956 The element has no attributes. 958 The element has zero or more of the 959 following child elements: 961 : Describes a supported codec and the number of non- 962 active sessions for that codec. The element has one 963 attribute. The value of the attribute 'name' is a media type 964 (which can include parameters per [RFC6381]). The 965 element has two child elements. The child element, , 966 has as content the decimal number of RTP sessions available for 967 decoding using the specified codec. The child element, 968 , has as content the decimal number of RTP sessions 969 available for encoding using the specified codec. 971 5.1.5.6. 973 The element provides information 974 detailing the current inactive mixed RTP sessions, that is, how many 975 more mixing sessions this Media Server can support. The element MAY 976 be present. 978 The element has no attributes. 980 The element has zero of more of the 981 following child element: 983 : Describes available mixed RTP sessions. The 984 element has one attribute. The value of the 985 attribute 'available' is the number of mixes that could be used 986 using that profile. The element has one child 987 element. The child element, , contains the same 988 information relating to RTP sessions as defined in 989 Section 5.1.5.5. The element MAY be present. 991 5.1.5.7. 993 The element provides information detailing the 994 current status of the media server. The element MUST be present. It 995 can return one of the following values: 997 active: Indicating that the Media Server is available for service. 999 deactivated: Indicating that the Media Server has been withdrawn 1000 from service, and as such requests should not be sent to it before 1001 it becomes 'active' again. 1003 unavailable: Indicating that the Media Server continues to process 1004 past requests but cannot accept new requests, and as such should 1005 not be contacted before it becomes 'active' again. 1007 The element has no attributes. 1009 The element has no child elements. 1011 5.1.5.8. 1013 The element provides information detailing the 1014 current codecs supported by a media server and associated actions. 1015 The element MAY be present. 1017 The element has no attributes. 1019 The element has zero or more of the following 1020 child element: 1022 : has a single attribute, 'name', which provides 1023 the name of the codec about which this element provides 1024 information. A valid value is a media type which, depending on 1025 its definition, can include additional parameters (e.g., 1026 [RFC6381]). The element then has a further 1027 child element, . The element has a single attribute, 'name', which provides 1029 the name of the Media Control Channel Framework package, compliant 1030 with the Section 13.1.1 of [RFC6230], for which the codec support 1031 applies. The element has zero or more 1032 children, each one of which describes an action 1033 that a Media Server can apply to this codec: 1035 * 'decoding', meaning a decoder for this codec is available; 1037 * 'encoding', meaning an encoder for this codec is available; 1039 * 'passthrough', meaning the Media Server is able to pass a 1040 stream encoded using that codec through without re-encoding. 1042 5.1.5.9. 1044 The element provides an arbitrary string of 1045 characters as application level data. This data is meant to only 1046 have meaning at the application level logic and as such is not 1047 otherwise restricted by this specification. The set of allowed 1048 characters are the same as those in XML (viz., tab, carriage return, 1049 line feed, and the legal characters of Unicode and ISO/IEC 10646 [see 1050 http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present. 1052 The element has no attributes. 1054 The element has no child elements. 1056 5.1.5.10. 1058 The element provides a list of file formats supported 1059 for the purpose of playing media. The element MAY be present. 1061 The element has no attributes. 1063 The element has zero of more the following child 1064 elements: 1066 : has a single attribute, 'name', which provides 1067 the type of file format that is supported. A valid value is a 1068 media type which, depending on its definition, can include 1069 additional parameters (e.g., [RFC6381]). The 1070 element then has a further child element, . The element provides the name 1072 of the Media Control Channel Framework package, compliant with the 1073 Section 13.1.1 of [RFC6230], for which the file format support 1074 applies. 1076 5.1.5.11. 1078 The element provides the maximum amount of 1079 time a media dialog will be kept in the prepared state before timing 1080 out before it is executed (see section 4.4.2.2.6 of RFC 1081 6231[RFC6231]. The element MAY be present. 1083 The element has no attributes. 1085 The element has zero or more of the following 1086 child elements: 1088 : has a single attribute, 'max-time-seconds', which 1089 provides the amount of time in seconds that a media dialog can be 1090 in the prepared state. The element then has a further 1091 child element, . The element 1092 provides the name of the Media Control Channel Framework package, 1093 compliant with the Section 13.1.1 of [RFC6230], for which the time 1094 period applies. 1096 5.1.5.12. 1098 The element specifies the supported methods to detect 1099 DTMF tones and to generate them. The element MAY be present. 1101 The element has no attributes. 1103 The element has zero of more of the following child 1104 elements: 1106 : Indicates the support for DTMF detection. The 1107 element has no attributes. The element then has a 1108 further child element, . The element has 1109 two attributes, 'name' and 'package. The 'name' attribute 1110 provides the type of DTMF being used, and it can only be a case 1111 insensitive string containing either 'RFC4733' [RFC4733] or 1112 'Media' (detecting tones as signals from the audio stream). The 1113 'package' attribute provides the name of the Media Control Channel 1114 Framework package, compliant with the Section 13.1.1 of [RFC6230], 1115 for which the DTMF type applies. 1117 : Indicates the support for DTMF generation. The 1118 element has no attributes. The element then 1119 has a further child element, . The element 1120 has two attributes, 'name' and 'package. The 'name' attribute 1121 provides the type of DTMF being used, and it can only be a case 1122 insensitive string containing either 'RFC4733' [RFC4733] or 1123 'Media' (generating tones as signals in the audio stream). The 1124 'package' attribute provides the name of the Media Control Channel 1125 Framework package, compliant with the Section 13.1.1 of [RFC6230], 1126 for which the DTMF type applies. 1128 : Indicates the support for passing DTMF through 1129 without re-encoding. The element has no attributes. 1130 The element then has a further child element, . The element has two attributes, 'name' and 1132 'package. The 'name' attribute provides the type of DTMF being 1133 used, and it can only be a case insensitive string containing 1134 either 'RFC4733' [RFC4733] or 'Media' (passing tones as signals 1135 through the audio stream). The 'package' attribute provides the 1136 name of the Media Control Channel Framework package, compliant 1137 with the Section 13.1.1 of [RFC6230], for which the DTMF type 1138 applies. 1140 5.1.5.13. 1142 The element provides information about the support for 1143 audio and video mixing of a Media Server, specifically a list of 1144 supported algorithms to mix audio and a list of supported video 1145 presentation layouts. The element MAY be present. 1147 The element has no attributes. 1149 The element has zero or more of the following child 1150 elements: 1152 : Describes the available algorithms for audio 1153 mixing. The element has no attributes. The 1154 element has one child element. The child 1155 element, , contains a specific available 1156 algorithm. Valid values for the element are 1157 algorithm names, e.g., 'nbest' and 'controller' as defined in 1158 [RFC6505]. The element has a single attribute, 'package'. The 1159 attribute 'package' provides the name of the Media Control Channel 1160 Framework package, compliant with the Section 13.1.1 of [RFC6230], 1161 for which the algorithm support applies. 1163 : Describes the available video presentation 1164 layouts and the supported functionality for what concerns video 1165 mixing. The element has two attributes, 1166 'vas' and 'activespeakermix'. The 'vas' attribute is of type 1167 boolean with a value of 'true' indicating the Media Server 1168 supports automatic Voice Activated Switching. The 1169 'activespeakermix' is of type boolean with a value of 'true' 1170 indicating that the Media Server is able to prepare an additional 1171 video stream for the loudest speaker participant without its 1172 contribution. The element has one child 1173 element. The child element, , contains the 1174 name of a specific video presentation layout. The name may refer 1175 to one of predefined video layouts defined in the XCON conference 1176 information data model, or to non-XCON layouts as well, as long as 1177 they are properly prefixed according to the schema they belong to. 1178 The element has a single attribute, 'package'. 1179 The attribute 'package' provides the name of the Media Control 1180 Channel Framework package, compliant with the Section 13.1.1 of 1181 [RFC6230], for which the algorithm support applies. 1183 5.1.5.14. 1185 The element provides information about which tones 1186 a media server is able to play and recognize. In particular, the 1187 support is reported referring to both country codes support (ISO 1188 3166-1 [ISO.3166-1]) and supported functionality (ITU-T 1189 Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present. 1191 The element has no attributes. 1193 The element has zero or more of the following child 1194 elements: 1196 : Describes the supported country codes 1197 with respect to tones. The element has 1198 no attributes. The has one child 1199 element. The child element, , reports support for a 1200 specific country code, compliant with the ISO 3166-1 [ISO.3166-1] 1201 specification. The element has a single attribute, 1202 'package'. The attribute 'package' provides the name of the Media 1203 Control Channel Framework package, compliant with the Section 1204 13.1.1 of [RFC6230], in which the tones from the specified country 1205 code are supported. 1207 : Describes the supported H.248 codes with 1208 respect to tones. The element has no 1209 attributes. The has one child element. 1210 The child element, , reports support for a specific 1211 H.248 code, compliant with the ITU-T Recommendation Q.1950 1212 [ITU-T.Q.1950] specification. The codes can be either specific 1213 (e.g., cg/dt to only report the Dial Tone from the Call Progress 1214 Tones package) or generic (e.g., cg/* to report all the tones from 1215 the Call Progress Tones package) using wild-cards. The element has a single attribute, 'package'. The attribute 1217 'package' provides the name of the Media Control Channel Framework 1218 package, compliant with the Section 13.1.1 of [RFC6230], in which 1219 the specified codes are supported. 1221 5.1.5.15. 1223 The element allows the Media Server to specify 1224 which scheme names are supported for transferring files to a Media 1225 Server for each Media Control Channel Framework package type. For 1226 example, whether the Media Server supports fetching resources via 1227 HTTP, HTTPS, NFS etc protocols. The element MAY be present. 1229 The element has no attributes. 1231 The element has zero or more of the following 1232 child element: 1234 : has two attributes, 'name' and 'package'. 1235 The 'name' attribute provides the scheme name of the protocol that 1236 can be used for file transfer (e.g., "HTTP", "HTTPS", NFS etc.): 1237 the value of the attribute is case insensitive. The 'package' 1238 attribute provides the name of the Media Control Channel Framework 1239 package, compliant with the specification in the related IANA 1240 registry (e.g., "msc-ivr/1.0"), for which the scheme name applies. 1242 It is important to point out that this element provides no 1243 information about whether or not the Media Server supports any 1244 flavour of live streaming: for instance, a value of "HTTP" for the 1245 IVR (Interactive Voice Response) Package would only mean the 'http' 1246 scheme makes sense to the Media Server within the context of that 1247 package. Whether or not the Media Server can make use of HTTP to 1248 only fetch resources, or also to attach an HTTP live stream to a 1249 call, is to be considered implementation specific to the Media Server 1250 and irrelevant to the Application Server and/or MRB. Besides, the 1251 Media Server supporting a scheme does not imply it also supports the 1252 related secure versions: for instance, if the Media Server supports 1253 both "HTTP" and "HTTPS", both the schemes will appear in the element. 1254 A lack of the "HTTPS" value would need to be interpreted as a lack of 1255 support for the 'https' scheme. 1257 5.1.5.16. 1259 The element provides information about the support 1260 for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) 1261 functionality in a media server. The functionality are reported by 1262 referring to the supported languages (using ISO-639-1 [ISO.639.1988] 1263 codes) for what regards both ASR and TTS. The element MAY be 1264 present. 1266 The element has no attributes. 1268 The element has zero or more of the following child 1269 elements: 1271 : Describes the available languages for ASR. The 1272 element has no attributes. The has 1273 one child element. The child element, , reports the 1274 Media Server supports ASR for a specific language. The 1275 element has a single attribute, 'xml:lang'. The attribute 'xml: 1276 lang' contains the ISO-639-1 [ISO.639.1988] code of the supported 1277 language. 1279 : Describes the available languages for TTS. The 1280 element has no attributes. The has 1281 one child element. The child element, , reports the 1282 Media Server supports tts for a specific language. The 1283 element has a single attribute, 'xml:lang'. The attribute 'xml: 1284 lang' contains the ISO-639-1 [ISO.639.1988] code of the supported 1285 language. 1287 5.1.5.17. 1289 The element specifies if the Media Server supports 1290 VoiceXML and if it does which protocols the support is exposed 1291 through (e.g., via the control framework, RFC4240 [RFC4240], or 1292 RFC5552 [RFC5552]). The element MAY be present. 1294 The element has no attributes. 1296 The element has zero or more of the following child 1297 elements: 1299 : has two attributes, 'package' and 'support'. The 1300 'package' attribute provides the name of the Media Control Channel 1301 Framework package, compliant with the Section 13.1.1 of [RFC6230], 1302 for which the VXML support applies. The 'support' attribute 1303 provides the type of VXML support provided by the Media Server 1304 (e.g., RFC5552 [RFC5552], RFC4240 [RFC4240] or IVR Package 1305 [RFC6231]), and valid values are case insensitive RFC references 1306 (e.g., "rfc6231" to specify the Media Server supports VoiceXML as 1307 provided by the IVR Package [RFC6231]). 1309 The presence of at least one child element would indicate 1310 that the Media Server does support VXML as specified by the child 1311 element itself. An empty element would otherwise indicate the 1312 Media Server does not support VXML at all. 1314 5.1.5.18. 1316 The element provides information about the 1317 civic location of a media server. Its description makes use of the 1318 Civic Address Schema standardized in RFC 5139 [RFC5139]. The element 1319 MAY be present. More precisely, this section is entirely optional, 1320 and it's implementation specific to fill it with just the details 1321 each implementor deems necessary for any optimization that may be 1322 needed. 1324 The element has no attributes. 1326 The element has zero or more of the following 1327 child elements: 1329 : Describes the civic address location of the media 1330 server, whose representation refers to the Section 4 of RFC 5139 1331 [RFC5139]. 1333 5.1.5.19.