idnits 2.17.1 draft-ietf-mediactrl-mrb-17.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 4, 2013) is 4099 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 5687, 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 8, 2013 Meetecho 6 G. Munson 7 AT&T 8 February 4, 2013 10 Media Resource Brokering 11 draft-ietf-mediactrl-mrb-17 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 8, 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 . . . . . . . 32 78 5.2.1. Query Mode / HTTP Consumer Interface Usage . . . . . 32 79 5.2.2. In-Line Aware Mode / SIP Consumer Interface Usage . . 33 80 5.2.3. Consumer Interface Lease Mechanism . . . . . . . . . 36 81 5.2.4. . . . . . . . . . . . . . . . . . . . . 39 82 5.2.5. Media Service Resource Request . . . . . . . . . . . 39 83 5.2.6. Media Service Resource Response . . . . . . . . . . . 51 84 5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . 54 85 6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 56 86 7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 57 87 8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 58 88 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 60 89 9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 60 90 9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 65 91 9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 65 92 9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 68 93 10. Media Service Resource Publisher Interface XML Schema . . . . 84 94 11. Media Service Resource Consumer Interface XML Schema . . . . 107 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 128 96 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131 97 13.1. Media Control Channel Framework Package Registration . . 131 98 13.2. application/mrb-publish+xml Media Type . . . . . . . . . 131 99 13.3. application/mrb-consumer+xml Media Type . . . . . . . . 132 100 13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 133 101 13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 133 102 13.6. XML Schema Registration for mrb-publish . . . . . . . . 133 103 13.7. XML Schema Registration for mrb-consumer . . . . . . . . 134 104 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 105 14.1. Changes from 13 Version . . . . . . . . . . . . . . . . 135 106 14.2. Changes from 12 Version . . . . . . . . . . . . . . . . 135 107 14.3. Changes from 11 Version . . . . . . . . . . . . . . . . 135 108 14.4. Changes from 10 Version . . . . . . . . . . . . . . . . 135 109 14.5. Changes from 09 Version . . . . . . . . . . . . . . . . 136 110 14.6. Changes from 08 Version . . . . . . . . . . . . . . . . 136 111 14.7. Changes from 07 Version . . . . . . . . . . . . . . . . 136 112 14.8. Changes from 06 Version . . . . . . . . . . . . . . . . 137 113 14.9. Changes from 05 Version . . . . . . . . . . . . . . . . 137 114 14.10. Changes from 04 Version . . . . . . . . . . . . . . . . 137 115 14.11. Changes from 03 Version . . . . . . . . . . . . . . . . 137 116 14.12. Changes from 02 Version . . . . . . . . . . . . . . . . 138 117 14.13. Changes from 01 Version . . . . . . . . . . . . . . . . 138 118 14.14. Changes from 00 Version . . . . . . . . . . . . . . . . 138 119 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 139 120 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 140 121 16.1. Normative References . . . . . . . . . . . . . . . . . . 140 122 16.2. Informative References . . . . . . . . . . . . . . . . . 141 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 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 zero or more of the following 663 attributes: 665 version: a token specifying the mrb-publish package version. The 666 value is fixed as '1.0' for this version of the package. The 667 attribute MUST be present. 669 The element has the following child elements, only one 670 of which is allowed to occur in a request. 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 zero or more of the following child 688 elements: 690 for initiating a subscription to a Media Server 691 from an MRB. See Section 5.1.3.1. 693 5.1.3.1. 695 The element is included in a request from an MRB to a 696 Media Server to provide the details relating to the configuration of 697 updates. This element can be used either to request a new 698 subscription or to update an existing one (e.g., to change the 699 frequency of the updates), and to remove ongoing subscriptions as 700 well (e.g., to stop an indefinite update). The MRB will inform the 701 Media Server how long it wishes to receive updates for and the 702 frequency that updates should be sent. Updates related to the 703 subscription are sent using the element. 705 The element has the following attributes: 707 id: indicates a unique token representing the subscription session 708 between the MRB and the Media Server. The attribute MUST be 709 present. 711 seqnumber: indicates a sequence number to be used in conjunction 712 with the subscription session id to identify a specific 713 subscription command. The first subscription MUST have 1 as 714 'seqnumber', and following subscriptions MUST increment by 1 the 715 previous 'seqnumber' value. The attribute MUST be present. 717 action: provides the operation that should be carried out on the 718 subscription: 720 * The value of 'create' instructs the Media Server to attempt to 721 set-up a new subscription. 723 * The value of 'update' instructs the Media Server to attempt to 724 update an existing subscription. 726 * The value of 'remove' instructs the Media Server to attempt to 727 remove an existing subscription and consequently stop any 728 ongoing related notification. 730 The attribute MUST be present. 732 The element has zero or more of the following child 733 elements: 735 : Provides the amount of time in seconds that a 736 subscription should be installed for notifications at the Media 737 Server. Once the amount of time has passed, the subscription 738 expires and the MRB has to subscribe again in case it is still 739 interested in receiving notifications from the Media Server. The 740 element MAY be present. 742 : Provides the minimum frequency in seconds that the 743 MRB wishes to receive notifications from the Media Server. The 744 element MAY be present. 746 : Provides the maximum frequency in seconds that the 747 MRB wishes to receive notifications from the Media Server. The 748 element MAY be present. 750 Please note that these three optional pieces of information provided 751 by the MRB only act as a suggestion: the Media Server MAY change the 752 proposed values if it considers the suggestions unacceptable (e.g., 753 if the MRB has requested a too high notification frequency). In such 754 case, the request would not fail, but the updated, acceptable values 755 would be reported in the accordingly. 757 5.1.4. 759 Responses to requests are indicated by a element. 761 The element has the following attributes: 763 status: numeric code indicating the response status. The attribute 764 MUST be present. 766 reason: string specifying a reason for the response status. The 767 attribute MAY be present. 769 The element has zero or more of the following child 770 elements: 772 for providing details related to a subscription a 773 Media Server requested (see below in this section). 775 The following status codes are defined for 'status': 777 +-----------+-------------------------------------------------------+ 778 | code | description | 779 +-----------+-------------------------------------------------------+ 780 | 200 | OK | 781 | | | 782 | 400 | Syntax error | 783 | | | 784 | 401 | Unable to create Subscription | 785 | | | 786 | 402 | Unable to update Subscription | 787 | | | 788 | 403 | Unable to remove Subscription | 789 | | | 790 | 404 | Subscription does not exist | 791 | | | 792 | 405 | Subscription already exists | 793 | | | 794 | 420 | Unsupported attribute or element | 795 +-----------+-------------------------------------------------------+ 797 Table 1: status codes 799 In case a new subscription request made by an MRB (action='create') 800 has been accepted, the Media Server MUST reply with a 801 with status code 200. The same rule applies whenever a request to 802 update (action='update') or remove (action='remove') an existing 803 transaction can be fulfilled by the Media Server. 805 A subscription request, nevertheless, may fail for several reasons. 806 In such a case, the status codes defined in Table 1 must be used 807 instead. Specifically, if the Media Server fails to handle a request 808 due to a syntax error in the request itself (e.g., incorrect XML, 809 violation of the schema constraints or invalid values in any of the 810 attributes/elements) the Media Server MUST reply with a 811 with status code 400. If a syntactically correct request fails 812 because the request also includes any attribute/element the Media 813 Server doesn't understand, the Media Server MUST reply with a 814 with status code 420. If a syntactically correct 815 request fails because the MRB wants to create a new subscription, but 816 the provided unique 'id' for the subscription already exists, the 817 Media Server MUST reply with a with status code 405. 818 If a syntactically correct request fails because the MRB wants to 819 update/remove a subscription that doesn't exist, the Media Server 820 MUST reply with a with status code 404. If the Media 821 Server is unable to accept a request for any other reason (e.g., the 822 MRB has no more resources to fulfil the request), the Media Server 823 MUST reply with a with status code 401/402/403, 824 depending on the action the MRB provided in its request: 826 o action='create' --> 401; 828 o action='update' --> 402; 830 o action='remove' --> 403; 832 A response to a subscription request that has a status of "200" 833 indicates that the request is successful. The response MAY also 834 contain a child that describes the subscription. The 835 child MAY contain 'expires', 'minfrequency' and 836 'maxfrequency' values even if they were not contained in the request. 838 The Media Server MAY change the suggested 'expires', 'minfrequency' 839 and 'maxfrequency' values provided by the MRB in its , if 840 it considers them unacceptable (e.g., the requested frequency range 841 is too high). In such a case, the response MUST contain a 842 element describing the subscription as the Media 843 Server accepted it, and the Media Server MUST include in the 844 element all of those values that it modified relative 845 to the request, to inform the MRB about the change. 847 5.1.5. 849 The element is included in a request from a Media 850 Server to an MRB to provide the details relating current status. The 851 Media Server will inform the MRB of its current status as defined by 852 the information in the element. Updates are sent 853 using the element. 855 The element has the following attributes: 857 id: indicates a unique token representing the session between the 858 MRB and the Media Server and is the same as the one appearing in 859 the element. The attribute MUST be present. 861 seqnumber: indicates a sequence number to be used in conjunction 862 with the subscription session id to identify a specific 863 notification update. The first notification MUST have 1 as 864 'seqnumber', and following notifications MUST increment by 1 the 865 previous 'seqnumber' value. The attribute MUST be present. 867 It's important to point out that the 'seqnumber' that appears in a 868 is not related to the 'seqnumber' appearing in a 869 . In fact, the latter is associated with 870 subscriptions and would increase at every command issued by the MRB, 871 while the former is associated with the asynchronous notifications 872 the Media Server would trigger according to the subscription, and as 873 such would increase at every notification message to enable the MRB 874 keep track of them. 876 The following subsections provide details of the child elements that 877 are the content of the element. 879 5.1.5.1. 881 The element provides a unique system wide 882 identifier for a Media Server instance. The element MUST be present, 883 and MUST chosen such that it is extremely unlikely that two different 884 media servers would present the same id to a given MRB. 886 5.1.5.2. 888 The element provides the list of Media Control 889 Channel Packages supported by the media server. The element MAY be 890 present. 892 The element has no attributes. 894 The element has zero or more of the following 895 child elements: 897 : The element gives the name of a package 898 supported by the media server. The element has a single 899 attribute, 'name', which provides the name of the supported Media 900 Control Channel Framework package, compliant with the Section 901 13.1.1 of [RFC6230]. 903 5.1.5.3. 905 The element provides information detailing the 906 current active Real-time Transport Protocol(RTP) sessions. The 907 element MAY be present. 909 The element has no attributes. 911 The element has zero or more of the following 912 child elements: 914 : Describes a supported codec and the number of active 915 sessions using that codec. The element has one 916 attribute. The value of the attribute 'name' is a media type 917 (which can include parameters per [RFC6381]). The 918 element has two child elements. The child element, , 919 has as content the decimal number of RTP sessions being decoded 920 using the specified codec. The child element, , has as 921 content the decimal number of RTP sessions being encoded using the 922 specified codec. 924 5.1.5.4. 926 The element provides information detailing 927 the current active mixed RTP sessions. The element MAY be present. 929 The element has no attributes. 931 The element has zero or more of the following 932 child elements: 934 : Describes a mixed active RTP session. The element has one attribute. The value of the attribute 936 'conferenceid' is the name of the mix. The element 937 has one child element. The child element, , contains 938 the same information relating to RTP sessions as defined in 939 Section 5.1.5.3. The element MAY be present. 941 5.1.5.5. 943 The element provides information detailing 944 the currently available inactive RTP sessions, that is, how many more 945 RTP streams this Media Server can support. The element MAY be 946 present. 948 The element has no attributes. 950 The element has zero or more of the 951 following child elements: 953 : Describes a supported codec and the number of non- 954 active sessions for that codec. The element has one 955 attribute. The value of the attribute 'name' is a media type 956 (which can include parameters per [RFC6381]). The 957 element has two child elements. The child element, , 958 has as content the decimal number of RTP sessions available for 959 decoding using the specified codec. The child element, 960 , has as content the decimal number of RTP sessions 961 available for encoding using the specified codec. 963 5.1.5.6. 965 The element provides information 966 detailing the current inactive mixed RTP sessions, that is, how many 967 more mixing sessions this Media Server can support. The element MAY 968 be present. 970 The element has no attributes. 972 The element has zero of more of the 973 following child element: 975 : Describes available mixed RTP sessions. The 976 element has one attribute. The value of the 977 attribute 'available' is the number of mixes that could be used 978 using that profile. The element has one child 979 element. The child element, , contains the same 980 information relating to RTP sessions as defined in 981 Section 5.1.5.5. The element MAY be present. 983 5.1.5.7. 985 The element provides information detailing the 986 current status of the media server. The element MUST be present. It 987 can return one of the following values: 989 active: Indicating that the Media Server is available for service. 991 deactivated: Indicating that the Media Server has been withdrawn 992 from service, and as such requests should not be sent to it before 993 it becomes 'active' again. 995 unavailable: Indicating that the Media Server continues to process 996 past requests but cannot accept new requests, and as such should 997 not be contacted before it becomes 'active' again. 999 The element has no attributes. 1001 The element has no child elements. 1003 5.1.5.8. 1005 The element provides information detailing the 1006 current codecs supported by a media server and associated actions. 1007 The element MAY be present. 1009 The element has no attributes. 1011 The element has zero or more of the following 1012 child element: 1014 : has a single attribute, 'name', which provides 1015 the name of the codec about which this element provides 1016 information. A valid value is a media type which, depending on 1017 its definition, can include additional parameters (e.g., 1018 [RFC6381]). The element then has a further 1019 child element, . The element has a single attribute, 'name', which provides 1021 the name of the Media Control Channel Framework package, compliant 1022 with the Section 13.1.1 of [RFC6230], for which the codec support 1023 applies. The element has zero or more 1024 children, each one of which describes an action 1025 that a Media Server can apply to this codec: 1027 * 'decoding', meaning a decoder for this codec is available; 1029 * 'encoding', meaning an encoder for this codec is available; 1031 * 'passthrough', meaning the Media Server is able to pass a 1032 stream encoded using that codec through without re-encoding. 1034 5.1.5.9. 1036 The element provides an arbitrary string of 1037 characters as application level data. This data is meant to only 1038 have meaning at the application level logic and as such is not 1039 otherwise restricted by this specification. The set of allowed 1040 characters are the same as those in XML (viz., tab, carriage return, 1041 line feed, and the legal characters of Unicode and ISO/IEC 10646 [see 1042 http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present. 1044 The element has no attributes. 1046 The element has no child elements. 1048 5.1.5.10. 1050 The element provides a list of file formats supported 1051 for the purpose of playing media. The element MAY be present. 1053 The element has no attributes. 1055 The element has zero of more the following child 1056 elements: 1058 : has a single attribute, 'name', which provides 1059 the type of file format that is supported. A valid value is a 1060 media type which, depending on its definition, can include 1061 additional parameters (e.g., [RFC6381]). The 1062 element then has a further child element, . The element provides the name 1064 of the Media Control Channel Framework package, compliant with the 1065 Section 13.1.1 of [RFC6230], for which the file format support 1066 applies. 1068 5.1.5.11. 1070 The element provides the maximum amount of 1071 time a media dialog will be kept in the prepared state before timing 1072 out before it is executed (see section 4.4.2.2.6 of RFC 1073 6231[RFC6231]. The element MAY be present. 1075 The element has no attributes. 1077 The element has zero or more of the following 1078 child elements: 1080 : has a single attribute, 'max-time-seconds', which 1081 provides the amount of time in seconds that a media dialog can be 1082 in the prepared state. The element then has a further 1083 child element, . The element 1084 provides the name of the Media Control Channel Framework package, 1085 compliant with the Section 13.1.1 of [RFC6230], for which the time 1086 period applies. 1088 5.1.5.12. 1090 The element specifies the supported methods to detect 1091 DTMF tones and to generate them. The element MAY be present. 1093 The element has no attributes. 1095 The element has zero of more of the following child 1096 elements: 1098 : Indicates the support for DTMF detection. The 1099 element has no attributes. The element then has a 1100 further child element, . The element has 1101 two attributes, 'name' and 'package. The 'name' attribute 1102 provides the type of DTMF being used, and it can only be a case 1103 insensitive string containing either 'RFC4733' [RFC4733] or 1104 'Media' (detecting tones as signals from the audio stream). The 1105 'package' attribute provides the name of the Media Control Channel 1106 Framework package, compliant with the Section 13.1.1 of [RFC6230], 1107 for which the DTMF type applies. 1109 : Indicates the support for DTMF generation. The 1110 element has no attributes. The element then 1111 has a further child element, . The element 1112 has two attributes, 'name' and 'package. The 'name' attribute 1113 provides the type of DTMF being used, and it can only be a case 1114 insensitive string containing either 'RFC4733' [RFC4733] or 1115 'Media' (generating tones as signals in the audio stream). The 1116 'package' attribute provides the name of the Media Control Channel 1117 Framework package, compliant with the Section 13.1.1 of [RFC6230], 1118 for which the DTMF type applies. 1120 : Indicates the support for passing DTMF through 1121 without re-encoding. The element has no attributes. 1122 The element then has a further child element, . The element has two attributes, 'name' and 1124 'package. The 'name' attribute provides the type of DTMF being 1125 used, and it can only be a case insensitive string containing 1126 either 'RFC4733' [RFC4733] or 'Media' (passing tones as signals 1127 through the audio stream). The 'package' attribute provides the 1128 name of the Media Control Channel Framework package, compliant 1129 with the Section 13.1.1 of [RFC6230], for which the DTMF type 1130 applies. 1132 5.1.5.13. 1134 The element provides information about the support for 1135 audio and video mixing of a Media Server, specifically a list of 1136 supported algorithms to mix audio and a list of supported video 1137 presentation layouts. The element MAY be present. 1139 The element has no attributes. 1141 The element has zero or more of the following child 1142 elements: 1144 : Describes the available algorithms for audio 1145 mixing. The element has no attributes. The 1146 element has one child element. The child 1147 element, , contains a specific available 1148 algorithm. Valid values for the element are 1149 algorithm names, e.g., 'nbest' and 'controller' as defined in 1150 [RFC6505]. The element has a single attribute, 'package'. The 1151 attribute 'package' provides the name of the Media Control Channel 1152 Framework package, compliant with the Section 13.1.1 of [RFC6230], 1153 for which the algorithm support applies. 1155 : Describes the available video presentation 1156 layouts and the supported functionality for what concerns video 1157 mixing. The element has two attributes, 1158 'vas' and 'activespeakermix'. The 'vas' attribute is of type 1159 boolean with a value of 'true' indicating the Media Server 1160 supports automatic Voice Activated Switching. The 1161 'activespeakermix' is of type boolean with a value of 'true' 1162 indicating that the Media Server is able to prepare an additional 1163 video stream for the loudest speaker participant without its 1164 contribution. The element has one child 1165 element. The child element, , contains the 1166 name of a specific video presentation layout. The name may refer 1167 to one of predefined video layouts defined in the XCON conference 1168 information data model, or to non-XCON layouts as well, as long as 1169 they are properly prefixed according to the schema they belong to. 1170 The element has a single attribute, 'package'. 1171 The attribute 'package' provides the name of the Media Control 1172 Channel Framework package, compliant with the Section 13.1.1 of 1173 [RFC6230], for which the algorithm support applies. 1175 5.1.5.14. 1177 The element provides information about which tones 1178 a media server is able to play and recognize. In particular, the 1179 support is reported referring to both country codes support (ISO 1180 3166-1 [ISO.3166-1]) and supported functionality (ITU-T 1181 Recommendation Q.1950 [ITU-T.Q.1950]). The element MAY be present. 1183 The element has no attributes. 1185 The element has zero or more of the following child 1186 elements: 1188 : Describes the supported country codes 1189 with respect to tones. The element has 1190 no attributes. The has one child 1191 element. The child element, , reports support for a 1192 specific country code, compliant with the ISO 3166-1 [ISO.3166-1] 1193 specification. The element has a single attribute, 1194 'package'. The attribute 'package' provides the name of the Media 1195 Control Channel Framework package, compliant with the Section 1196 13.1.1 of [RFC6230], in which the tones from the specified country 1197 code are supported. 1199 : Describes the supported H.248 codes with 1200 respect to tones. The element has no 1201 attributes. The has one child element. 1202 The child element, , reports support for a specific 1203 H.248 code, compliant with the ITU-T Recommendation Q.1950 1204 [ITU-T.Q.1950] specification. The codes can be either specific 1205 (e.g., cg/dt to only report the Dial Tone from the Call Progress 1206 Tones package) or generic (e.g., cg/* to report all the tones from 1207 the Call Progress Tones package) using wild-cards. The element has a single attribute, 'package'. The attribute 1209 'package' provides the name of the Media Control Channel Framework 1210 package, compliant with the Section 13.1.1 of [RFC6230], in which 1211 the specified codes are supported. 1213 5.1.5.15. 1215 The element allows the Media Server to specify 1216 which scheme names are supported for transferring files to a Media 1217 Server for each Media Control Channel Framework package type. For 1218 example, whether the Media Server supports fetching resources via 1219 HTTP, HTTPS, NFS etc protocols. The element MAY be present. 1221 The element has no attributes. 1223 The element has zero or more of the following 1224 child element: 1226 : has two attributes, 'name' and 'package'. 1227 The 'name' attribute provides the scheme name of the protocol that 1228 can be used for file transfer (e.g., "HTTP", "HTTPS", NFS etc.): 1229 the value of the attribute is case insensitive. The 'package' 1230 attribute provides the name of the Media Control Channel Framework 1231 package, compliant with the specification in the related IANA 1232 registry (e.g., "msc-ivr/1.0"), for which the scheme name applies. 1234 It is important to point out that this element provides no 1235 information about whether or not the Media Server supports any 1236 flavour of live streaming: for instance, a value of "HTTP" for the 1237 IVR Package would only mean the 'http' scheme makes sense to the 1238 Media Server within the context of that package. Whether or not the 1239 Media Server can make use of HTTP to only fetch resources, or also to 1240 attach an HTTP live stream to a call, is to be considered 1241 implementation specific to the Media Server and irrelevant to the 1242 Application Server and/or MRB. Besides, the Media Server supporting 1243 a scheme does not imply it also supports the related secure versions: 1244 for instance, if the Media Server supports both "HTTP" and "HTTPS", 1245 both the schemes will appear in the element. A lack of the "HTTPS" 1246 value would need to be interpreted as a lack of support for the 1247 'https' scheme. 1249 5.1.5.16. 1251 The element provides information about the support 1252 for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) 1253 functionality in a media server. The functionality are reported by 1254 referring to the supported languages (using ISO-639-1 [ISO.639.1988] 1255 codes) for what regards both ASR and TTS. The element MAY be 1256 present. 1258 The element has no attributes. 1260 The element has zero or more of the following child 1261 elements: 1263 : Describes the available languages for ASR. The 1264 element has no attributes. The has 1265 one child element. The child element, , reports the 1266 Media Server supports ASR for a specific language. The 1267 element has a single attribute, 'xml:lang'. The attribute 'xml: 1268 lang' contains the ISO-639-1 [ISO.639.1988] code of the supported 1269 language. 1271 : Describes the available languages for TTS. The 1272 element has no attributes. The has 1273 one child element. The child element, , reports the 1274 Media Server supports tts 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 5.1.5.17. 1281 The element specifies if the Media Server supports 1282 VoiceXML and if it does which protocols the support is exposed 1283 through (e.g., via the control framework, RFC4240 [RFC4240], or 1284 RFC5552 [RFC5552]). The element MAY be present. 1286 The element has no attributes. 1288 The element has zero or more of the following child 1289 elements: 1291 : has two attributes, 'package' and 'support'. The 1292 'package' attribute provides the name of the Media Control Channel 1293 Framework package, compliant with the Section 13.1.1 of [RFC6230], 1294 for which the VXML support applies. The 'support' attribute 1295 provides the type of VXML support provided by the Media Server 1296 (e.g., RFC5552 [RFC5552], RFC4240 [RFC4240] or IVR Package 1297 [RFC6231]), and valid values are case insensitive RFC references 1298 (e.g., "rfc6231" to specify the Media Server supports VoiceXML as 1299 provided by the IVR Package [RFC6231]). 1301 The presence of at least one child element would indicate 1302 that the Media Server does support VXML as specified by the child 1303 element itself. An empty element would otherwise indicate the 1304 Media Server does not support VXML at all. 1306 5.1.5.18. 1308 The element provides information about the 1309 civic location of a media server. Its description makes use of the 1310 Civic Address Schema standardized in RFC 5139 [RFC5139]. The element 1311 MAY be present. More precisely, this section is entirely optional, 1312 and it's implementation specific to fill it with just the details 1313 each implementor deems necessary for any optimization that may be 1314 needed. 1316 The element has no attributes. 1318 The element has zero or more of the following 1319 child elements: 1321 : Describes the civic address location of the media 1322 server, whose representation refers to the Section 4 of RFC 5139 1323 [RFC5139]. 1325 5.1.5.19.