idnits 2.17.1 draft-boulton-mediactrl-mrb-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2009) is 5503 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MRB-01' is mentioned on line 378, but not defined == Missing Reference: 'MRB-02' is mentioned on line 435, but not defined -- Looks like a reference, but probably isn't: '3' on line 438 -- Looks like a reference, but probably isn't: '2' on line 438 == Missing Reference: 'MRB-03' is mentioned on line 496, but not defined == Missing Reference: 'MRB-04' is mentioned on line 508, but not defined == Missing Reference: 'MRB-05' is mentioned on line 523, but not defined == Missing Reference: 'MRB-06' is mentioned on line 568, but not defined == Missing Reference: 'MRB-07' is mentioned on line 608, but not defined == Missing Reference: 'MRB-08' is mentioned on line 613, but not defined == Missing Reference: 'MRB-09' is mentioned on line 646, but not defined == Missing Reference: 'MRB-10' is mentioned on line 690, but not defined == Missing Reference: '0-9' is mentioned on line 792, but not defined == Unused Reference: 'RFC2578' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 826, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 836, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 3410 == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-10 Summary: 5 errors (**), 0 flaws (~~), 18 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: September 5, 2009 University of Napoli 6 March 4, 2009 8 Media Resource Brokering 9 draft-boulton-mediactrl-mrb-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 5, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The MediaCtrl work group in the IETF is currently proposing an 48 architecture for controlling media services. The Session Initiation 49 Protocol (SIP) will be used as the signalling protocol which provides 50 many inherent capabilities for message routing. In addition to such 51 signalling properties, a need exists for intelligent, application 52 level media service selection based on non-static signalling 53 properties. This is especially true when considered in conjunction 54 with deployment architectures that include 1:M and M:M combinations 55 of Application Servers and Media Servers. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 61 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 8 63 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 9 65 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 10 66 5. Interface Definition . . . . . . . . . . . . . . . . . . . . . 13 67 5.1. Media Server Resource Publishing Interface . . . . . . . . 13 68 5.2. Media Service Resource Consumer Interface . . . . . . . . 16 69 5.2.1. Media Service Resource Request . . . . . . . . . . . . 17 70 5.2.2. Media Service Resource Response . . . . . . . . . . . 17 71 6. Media Service Resource Consumer Interface XML Schema . . . . . 19 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 79 1. Introduction 81 The topic of Media Resources has been in discussion for a number of 82 years with varying proprietary solutions being used today. It is 83 clear that, as we move towards a consistent architecture and protocol 84 for Media Server Control, a standard mechanism is required for 85 accurate media resource location. 87 As IP based multimedia infrastructures mature, the complexity and 88 demands from deployments increase. Such complexity will result in a 89 wide variety of capabilities from a range of vendors that should all 90 be interoperable using the architecture and protocols produced by the 91 MediaCtrl work group. It should be possible for a controlling entity 92 to be assisted in Media Server selection so that the most appropriate 93 resource is selected for a particular operation. The importance 94 increases when you introduce a flexible level of deployment 95 scenarios, as specified in the MediaCtrl Requirements 96 [I-D.ietf-mediactrl-requirements] and MediaCtrl Architecture 97 [I-D.ietf-mediactrl-architecture] documents. These documents make 98 statements like "it should be possible to have a many-to-many 99 relationship between Application Servers and Media Servers that use 100 this protocol". This leads to the following deployment architectures 101 being possible when considering media resources. 103 The simplest deployment view is illustrated in Figure 1. 105 +---+-----+---+ +---+-----+---+ 106 | Application | | Media | 107 | Server |<-------MS Control------>| Server | 108 +-------------+ +-------------+ 110 Figure 1: Basic Architecture 112 This simply involves a single Application Server and Media Server. 113 Expanding on this view, it is also possible for an Application Server 114 to be controlling multiple (greater that 1) Media Servers. This 115 deployment view is illustrated in Figure 2. Typically, such 116 architectures are associated with application logic that requires 117 high demand media services. It is more than possible that each media 118 server possesses a different media capability set. Media servers may 119 offer different media services as specified in the Mediactrl 120 architecture document. A Media server may have similar media 121 functionality but may have different capacity or media codec support. 123 +---+-----+---+ 124 | Media | 125 +----->| Server | 126 | +-------------+ 127 | 128 +---+-----+---+ | +---+-----+---+ 129 | Application | | | Media | 130 | Server |<--MS Control-----+----->| Server | 131 +-------------+ | +-------------+ 132 | 133 | +---+-----+---+ 134 +----->| Media | 135 | Server | 136 +-------------+ 138 Figure 2: Basic Architecture 140 Figure 3 conveys the opposite view to that in Figure 2. In this 141 model there are a number of (greater than 1) application servers 142 controlling a single media server. Typically, such architectures are 143 associated with application logic that requires low demand media 144 services. 146 +---+-----+---+ 147 | Application | 148 | Server |<-----+ 149 +-------------+ | 150 | 151 +---+-----+---+ | +---+-----+---+ 152 | Application | | | Media | 153 | Server |<-----+-----MS Control-->| Server | 154 +-------------+ | +-------------+ 155 | 156 +---+-----+---+ | 157 | Application | | 158 | Server |<-----+ 159 +-------------+ 161 Figure 3: Basic Architecture 163 The final deployment view is the most complex. In this model (M:M) 164 there exists any number of Application Servers and any number of 165 Media Servers. It is again possible in this model that media servers 166 might not be homogenous and have different capability sets. 168 +---+-----+---+ +---+-----+---+ 169 | Application | | Media | 170 | Server |<-----+ +---->| Server | 171 +-------------+ | | +-------------+ 172 | | 173 +---+-----+---+ | | +---+-----+---+ 174 | Application | | | | Media | 175 | Server |<-----+-MS Control-+---->| Server | 176 +-------------+ | | +-------------+ 177 | | 178 +---+-----+---+ | | +---+-----+---+ 179 | Application | | +---->| Media | 180 | Server |<-----+ | Server | 181 +-------------+ +---+-----+---+ 183 Figure 4: Basic Architecture 185 This document will take a look at the specific problem areas related 186 to such deployment architectures. It is recognised that the 187 solutions proposed in this document should be equally adaptable to 188 all of the previously described deployment models. It is also 189 recognised that the solution is far more relevant to some of the 190 previously discussed deployment models and can almost be viewed as 191 redundant on others. 193 2. Conventions and Terminology 195 In this document, BCP 14/RFC 2119 [RFC2119] defines the key words 196 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 197 "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL". In addition, BCP 15 indicates requirement levels for 199 compliant implementations. 201 This document inherits terminology proposed in the MediaCtrl 202 Architecture [I-D.ietf-mediactrl-architecture] and Media Control 203 Channel Framework [I-D.ietf-mediactrl-sip-control-framework] 204 documents. In addition, the following terms are defined for use in 205 this document and for use in the context of the MediaCtrl Work group 206 in the IETF: 208 Media Resource Broker (MRB): A logical entity that is responsible 209 for both collection of appropriate published Media Server (MS) 210 information and supplying of appropriate MS information to 211 consuming entities. 213 Query MRB: An instantiation of an MRB (See previous definition) that 214 provides an interface for an Application Server to retrieve the 215 location of an appropriate Media Server. The result returned to 216 the Application Server can be influenced by information contained 217 in the query request. 219 In-line MRB: An instantiation of an MRB (See definition) that 220 directly receives requests on the signalling path. The decision 221 making process is totally delegated to the MRB. 223 3. Problem Discussion 225 It is clear from Section 1 that the MediaCtrl group will be producing 226 a solution that must service a wide variety of deployment 227 architectures. These range from the simplest 1:1 relationship 228 between Media Servers and Application Servers to potentially linearly 229 scaling 1:M, M:1 and M:M deployments. 231 This still does not seem like a major issue for the proposed solution 232 until you add a number of additional factors into the equation that 233 increase complexity. As Media Servers evolve it must be taken into 234 consideration that, where many can exist in a deployment, they may 235 not have been produced by the same vendor and may not have the same 236 capability set. It should be possible for an Application Server that 237 exists in a deployment to select a Media Service based on a common, 238 appropriate capability set. In conjunction with capabilities, it is 239 also important to take available resources into consideration. The 240 ability to select an appropriate Media Service function is an 241 extremely useful feature but becomes even more powerful when 242 considered in conjunction with available resources for servicing a 243 request. 245 In conclusion, the intention is to create a tool set that allows 246 MediaCtrl deployments to effectively utilize the available media 247 resources. It should be noted that in the simplest deployments where 248 only a single media server exists, an MRB function is probably not 249 required. Only a single capability set exists and resource 250 unavailability can be handled using the appropriate underlying 251 signalling e.g. SIP response. This document does not prohibit such 252 uses of an MRB, it simply provides the tools for various entities to 253 interact where appropriate. It is also worth noting that the tools 254 provided in this document aim to provide a 'best effort' view of 255 media resources at the time of request for initial Media Server 256 routing decisions. Any dramatic change in media capabilities after a 257 request has taken place should be handled by the underlying protocol. 259 4. Deployment Scenario Options 261 On researching Media Resource Brokering it became clear that a couple 262 of high level models exist. The general principles of "in-line" and 263 "query" MRB concepts are discussed in the rest of this section. 265 4.1. Query MRB 267 The "Query" model for MRB interactions provides the ability for a 268 client of media services (for example an Application Server) to "ask" 269 an MRB for an appropriate Media Server, as illustrated in Figure 5. 271 +---+-----+---+ 272 +------------>| MRB |<----------+----<-----+---+ 273 | +-------------+ (1)| | | 274 | | | | 275 |(2) +---+--+--+---+ | | 276 | | Media | | | 277 | +---->| Server | | | 278 | | +-------------+ | | 279 | | (1)| | 280 +---+--+--+---+ | +---+-----+---+ | | 281 | Application | | | Media | | | 282 | Server |<-----+-MS Control-+---->| Server |->-+ | 283 +-------------+ (3) | +-------------+ | 284 | | 285 | +---+-----+---+ (1)| 286 +---->| Media | | 287 | Server |--->---+ 288 +---+-----+---+ 290 Figure 5: Query MRB 292 In this deployment, the Media Servers use the "Media Server Resource 293 Publishing Interface", as discussed in Section 5.1, to convey 294 capability sets as well as resource information. This is depicted by 295 (1) in Figure 5. It is then the MRB's responsibility to accumulate 296 all appropriate information relating to media services in the logical 297 deployment cluster. The Application Server (or other media services 298 client) is then able to query the MRB for an appropriate resource (as 299 identified by (2) in Figure 5). Such a query would carry specific 300 information related to the Media Service required and enable the MRB 301 to provide an increased accuracy in its response. This particular 302 interface is discussed in "Media Resource Consumer Interface" in 303 Section 5.2. The Application Server is then able to direct control 304 commands (for example create conference) and Media Dialogs to the 305 appropriate Media Server, as shown by (3) in Figure 5. 307 4.1.1. Hybrid Query MRB 309 As mentioned previously, it is the intention that a tool kit is 310 provided for MRB functionality within a MediaCtrl architecture. It 311 is expected that in specific deployment scenarios the role of the MRB 312 might be co-hosted as a hybrid logical entity with an Application 313 Server, as shown in Figure 6. 315 +------------<----------------<---------+----<-----+---+ 316 | (1) | | | 317 | | | | 318 | +---+--+--+---+ | | 319 | | Media | | | 320 V +---->| Server | | | 321 +------+------+ | +-------------+ | | 322 | MRB | | | | 323 +---+--+--+---+ | +---+-----+---+ | | 324 | Application | | | Media | | | 325 | Server |<-----+-MS Control-+---->| Server |->-+ | 326 +-------------+ | +-------------+ | 327 | | 328 | +---+-----+---+ | 329 +---->| Media | | 330 | Server |--->---+ 331 +---+-----+---+ 333 Figure 6: Hybrid Query MRB - AS Hosted 335 This diagram is identical to that in Figure 5 with the exception that 336 the MRB is now hosted on the Application Server. The "Media Server 337 Publishing Interface" is still being used to accumulate resource 338 information at the MRB but as it is co-hosted on the Application 339 Server, the "Media Server Consumer Interface" has collapsed. It 340 might still exist within the Application Server/MRB interaction but 341 this is an implementation issue. This type of deployment suits a 342 single Application Server environment but it should be noted that a 343 "Media Server Consumer Interface" could then be offered from the 344 hybrid if required. 346 In a similar manner, the Media Server could also act as a hybrid for 347 the deployment cluster, as illustrated in Figure 7. 349 (1) +---+-----+---+ 350 +---+---+------------->---------------->----------->| MRB | 351 | | | +---+--+--+---+ +---+-----+---+ 352 | | +-<-| Application | | Media | 353 | | | Server |<--+-MS Control-+------->| Server | 354 | | +-------------+ | +-------------+ 355 | | | 356 | | +---+--+--+---+ | 357 | +---<---| Application | | 358 | | Server |<--+-MS Control-+--+ 359 | +-------------+ | 360 | | 361 | +---+--+--+---+ | 362 +---<-------| Application | | 363 | Server |<--+-MS Control-+--+ 364 +-------------+ 366 Figure 7: Hybrid Query MRB - MS Hosted 368 This time the MRB has collapsed and is co-hosted by the Media Server. 369 The "Media Server Consumer Interface" is still available to the 370 Application Servers (1) to query Media Server resources. This time 371 the "Media Server Publishing Interface" has collapsed onto the Media 372 Server. It might still exist within the Media Server/MRB interaction 373 but this is an implementation issue. This type of deployment suits a 374 single Media Server environment but it should be noted that a "Media 375 Server Publishing Interface" could then be offered from the hybrid if 376 required. 378 [MRB-01] Is this second hybrid topology really useful? The only 379 use case for it seems to be for AS[i] to send a request, receive a 380 response, and decide whether or not to place a CFW request at all 381 (since only one MS is available). Such a use case makes sense, 382 but it may be a bit overkill to make use of the MRB for that. Or 383 should we envisage the possibility of having for instance the 384 AS[i] construct a "lighter" CFW request if the MS is too loaded, 385 and a "normal" CFW request otherwise? 387 4.2. In-Line MRB 389 The "In-line" MRB is architecturally different from the "Query" model 390 that was discussed in the previous section. The Concept of a "Media 391 Server Consumer Interface" disappears. The client of the MRB simply 392 uses the signalling to offload the decision making process - this 393 applies to both media server Control and Media Dialogs. This type of 394 deployment is illustrated in Figure 8. 396 +-------<----------+----<-------+---+ 397 | | (1) | | 398 | | | | 399 | +---+--+--+---+ | | 400 | | Media | | | 401 | +------>| Server | | | 402 | |(3) +-------------+ | | 403 | | (1)| | 404 +---+--+--+---+ | | +---+-----+---+ | | 405 | Application | (2) +---+--V--+---+ (3) | Media | | | 406 | Server |----->| MRB |----->| Server |->-+ | 407 +-------------+ +---+-----+---+ +-------------+ | 408 | | 409 | (3) +---+-----+---+ (1)| 410 +------>| Media | | 411 | Server |--->---+ 412 +---+-----+---+ 414 Figure 8: In-line MRB 416 The Media Servers still use the 'Media Server Publishing Interface' 417 to convey capabilities and resources to the MRB - as illustrated by 418 (1). The media server Control and Media dialogs are blindly sent to 419 the MRB (2) which then selects an appropriate Media Server (3). The 420 result of such an architecture is that the decision is left entirely 421 to the MRB and the Application Server has no input into the selection 422 process. This is the opposite to the "Query" model which provided 423 information that would help influence the Media Server decision 424 making process on the application server. As a by-product of this 425 decision shift, a lot more emphasis is placed on the intelligence of 426 the MRB to interpret the required capabilities of the request. It 427 will actually have to inspect both the SIP signalling and the media 428 server control protocol PDUs for the purpose of Media Server 429 selection. This includes, for example, looking for explicit 430 capabilities in the signalling and session details such as media 431 types, codecs and bandwidth requirements. Ultimately the decision 432 making and policy enforcement is removed from the Application Server 433 and shifted to the MRB logical entity. 435 [MRB-02] How much intelligence should the MRB have in this case? 436 In fact, it's not just a matter of capabilities, but of package- 437 specific decisions as well. For instance, let's say there's a 438 conference on MS[3]. If AS[2] has created the conference and 439 attaching new participants to it, it definitely wouldn't want the 440 MRB to arbitrarily join its users on different MS (with having its 441 requests failing anyway, since a non-existing conference would be 442 invoked). Should we envisage, as a parameter, something like a 443 "context" or an "application session"? Considering no AS would be 444 able to decide to invoke a specific MS, such a parameter would be 445 the only (or at least a possibly working) way of letting an AS 446 tell the MRB "this request is part of this specific application 447 logic context, and so using a different MS would make it all 448 collapse". 450 5. Interface Definition 452 As discussed in previous sections in this document, the intention is 453 to provide a toolkit for a variety of deployment architectures where 454 media resource brokering can take place. As a result, two main 455 interfaces are required to support the differing requirements. The 456 two interfaces are described in the remainder of this section and 457 have been named the 'Media Server Resource Publishing' and Media 458 Server Resource Consumer' interfaces. These two interfaces have 459 extremely differing responsibilities and usages which is reflected in 460 the choice of solutions. 462 It is beyond the scope of this document to define exactly how to 463 construct an MRB. This includes interpreting the data for the Media 464 Service Consumer interface supplied by the Media Server Publishing 465 interface. It is, however, important that the two interfaces are 466 complimentary so that development of appropriate MRB functionality is 467 supported. 469 5.1. Media Server Resource Publishing Interface 471 The Media Server Resource Publishing interface is responsible for 472 providing an MRB with appropriate Media Server resource information. 473 It is generally accepted that this interface provides both general 474 and specific details related to Media Server resources. This 475 information needs to be conveyed using an industry standard mechanism 476 to provide increased levels of adoption and interoperability. A 477 Control Package for the Media Control Channel Framework will be 478 specified to fulfill this interface requirement. It provides the 479 perfect establishment and monitoring mechanism to enable a Media 480 Server to report appropriate statistics to an MRB. 482 [EDITORS NOTE: The use of the Media Control Channel Framework is 483 still up for debate. This should be revisited and discussed 484 appropriately. It is fair to say that Media Servers will already 485 support the base Media Control Channel Framework and so adding this 486 extra auditing facility provides nice synergy and reuse.] 488 EDITORS NOTE: Need to map resources to a control package and define 489 appropriately. The following information has been taken from 490 feedback from the community. Please comment on existing entries and 491 any other that you feel should be added to the list. Note that some 492 of the publishing topics would naturally be included in the 'AS 493 Request to MRB' section that follows. At this stage it is only 494 included in one place for further discussion: 496 [MRB-03] Should we talk of a new Control Package and/or of 497 additional requirements to the auditing mechanism for each 498 package? Some of the addressable resources are generically MS- 499 related (e.g. how many G711 sessions you have available, since it 500 affects the SIP negotiations with new UACs), but some look like 501 information that only packages would be able to provide. 503 o Active RTP sessions (including codec information). For example, 504 10 G711 RTP sessions, 3 H.264 sessions. 506 o 508 * [MRB-04] This may not be required, since the purpose of the MRB 509 is to check for available resources rather than occupied 510 resources. Nevertheless, such details might be useful for 511 complementary functionality as debugging and monitoring inside 512 the MRB. What are your feelings about it? 514 o Active Mixers. For example F4: (2 G711, 3 G729), (second mixer 515 and the codecs), (third mixer), ...). 517 o Non Active sessions - so sessions available on this MS (based on 518 codecs supported). For example, 80 G711 RTP session,120 G729 519 sessions,30 H.264 sessions. 521 o 523 * [MRB-05] Should this be an AND or an OR? (e.g. an AS takes all 524 the 80 G711 RTP sessions, are the G729 sessions still available 525 as well or were the specified resources shared?) 527 o MS Uptime. 529 o Codecs/media supported (could just be bundled with above 'Non 530 Active Sessions'. 532 o In addition to the generic media processing related information, 533 there are definitely cases where the AS will want to specify 534 application-level criteria, which will be application-specific, 535 and difficult to enumerate in advance. So I'm thinking we need a 536 way to express arbitrary application specific criteria in addition 537 to the generic media processing criteria. For example, the AS may 538 need an MS which is capable of prompting and performing speech 539 recognition in Swahili. Or, an MS which has the capability to 540 invoke some application-specific functionality. 542 o File formats supported for announcement. E.g.: MP3, WAW etc... 543 May be this information is enough to determine announcement format 544 supported i.e. audio or video. 546 o Maximum duration for an announcement. Media servers can have 547 restrictions on memory to play the announcements for very long 548 durations. 550 o Variable announcements. Where the substitution variable can be 551 time, date, cost etc. 553 o DTMF detection and generation support. 555 o Types of mixing (conference supported) audio, video. 557 o Supported tone types in the Media Server. Different countries may 558 have different characteristics for the same tone. So the tone 559 characteristics can be configured in the media server or can be 560 downloaded. Capability to play the tone in both directions may be 561 required for conferencing applications. E.g. playing a tone when 562 a new participant joins in the conference. The tone needs to be 563 played towards the existing participants and also towards the new 564 participant. 566 o 568 * [MRB-06] All these features are something that probably fit 569 better in auditing, rather than in here (and some are actually 570 already there). What do you think? 572 o Audio RTSP streaming. Audio conferencing. Audio record. Audio 573 transcoding. 575 o ASR/TTS usage. ASR grammar complexity. Language complexity. 577 o Speaker verification/recognition. 579 o Music recognition. 581 o Audio transformation (mask voice, raise tone, add echo, effects 582 etc.) 584 o VoiceXML dialogs and their complexity. 586 o Encryption of audio/video media streams. 588 o Video transcoding. 590 o Dynamic or static video frame rate, bit rate or picture size 591 adaptation per multimedia stream. 593 o Video record. 595 o Video RTSP streaming. 597 o Media insertion (audio, video, text, picture, logo, avatar or 598 background/ambiance) in a multimedia stream. 600 o Video mixing. 602 o Video broadcasting. 604 o Face/shape/image detection/removal. 606 o 608 * [MRB-07] Some of these features are not available in any 609 package at the moment, but considering that additional packages 610 might be written in the feature, it's probably ok to leave them 611 there. What are your feelings about it? 613 [MRB-08] There's another additional information that might be 614 useful, something that might actually fit in the codec-related 615 information. When we say MS[i] supports codec X, what kind of 616 support are we talking about? Are both encoding and decoding 617 supported? Is it passthrough only (e.g. I understand it but I 618 won't transcode)? Can the MS encapsulate an X encoded stream 619 according to the proper RFC? Such details would likely provide 620 valuable information considering that it would affect how a 621 conference mix, a prompt, a recording etc. would work inside the 622 MS. Any comments about it? 624 5.2. Media Service Resource Consumer Interface 626 The Media Server Consumer interface provides the ability for clients 627 of an MRB, such as Application Servers, to request an appropriate 628 Media Server to satisfy specific criteria. The interface allows a 629 client to pass detailed meta-information to the MRB to help select an 630 appropriate Media Server. The MRB is then able to make and informed 631 decision and provide the client with an appropriate media server 632 resource. 634 It appears the most appropriate interface for such a 'query' style 635 interface is in fact a RESTful type HTTP usage. Using HTTP and XML 636 combined reduces complexity and encourages use of common tools that 637 are widely available in the industry today. The following 638 subsections explain the main operations required to request and then 639 receive information from an MRB. The following description will 640 describe the use of HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 642 [RFC2818] as transport for a query for media resource and the 643 appropriate response. Examples of the interface can be seen in 644 section [ref examples section]. 646 [MRB-09] Are we all ok with this or should we consider/list 647 alternatives? 649 5.2.1. Media Service Resource Request 651 The media resource query is carried in the body of an HTTP/HTTPS POST 652 request. The MIME type contained in the HTTP/HTTPS request/reponse 653 should be 'application/mrb+xml'. This value MUST be reflected in the 654 appropriate HTTP headers like 'Content-Type' and 'Accept'. The body 655 of the POST request MUST only contain the 'mediaResourceRequest' 656 element as defined in Section 6. The 'mediaResourceRequest' element 657 is the primary container of information related to a media resource 658 request and has the following child elements which specify the 659 request parameters: 661 5.2.1.1. element 663 The element provides a container for clients 664 wishing to query an external MRB entity. The 665 element has the following child elements that are used to provide 666 appropriate contextual information relating to the request: [Editors 667 Note: Convert groups input into appropriate XML schema.] 669 o RTP requirements - including media/codec type, codec priority. 671 o Conference requirements - number of users. 673 5.2.2. Media Service Resource Response 675 The use of HTTP/HTTPS for carrying the media service resource 676 information has no impact on the protocol. If protocol level 677 operations and errors occur then they should be signalled as 678 specified in HTTP RFC 2616 [RFC2616] and HTTPS RFC 2818 [RFC2119]. A 679 successful response to a HTTP POST request containing the 680 'mediaResourceRequest' MUST be responded to with a 200 OK HTTP/HTTPS 681 response message. This signifies that the request was received, was 682 valid and could be responded to appropriately. If the receiving MRB 683 wishes to generate information for the requesting entity it MUST 684 include a 'mediaResourceResponse' element in the 200 OK HTTP/HTTPS 685 response (as discussed later in this section). An MRB can 686 alternatively return an application level error by including a 687 'mediaResourceError' element in the 200 OK HTTP/HTTPS response (as 688 discussed later in this section). 690 [MRB-10] As it was discussed when presenting CCMP, the use of 200 691 to convey responses (whether the resource has been found or not) 692 and of error codes to handle HTTP-related errors is in contrast 693 with a pure RESTful approach. Is it ok to proceed anyway? Or 694 should we "lighten" the REST proposal just say something like 695 "it's XML on HTTP", clarifying that we're not claiming to be pure 696 RESTers? 698 5.2.2.1. element 700 The element provides a container for the MRB 701 to generate a response to a previous query. The 702 element has the following child elements that 703 are used to provide appropriate contextual information relating to 704 the request: [Editors Note: Convert groups input into appropriate XML 705 schema.] 707 o list of appropriate media server resources (include individual 708 capabilities). 710 5.2.2.2. element 712 The element provides a container for the MRB to 713 generate an error response to a previous query. The 714 has element the following child elements that 715 are used to provide appropriate contextual information relating to 716 the request: [Editors Note: Convert groups input into appropriate XML 717 schema.] 719 o list of appropriate error response codes. 721 6. Media Service Resource Consumer Interface XML Schema 723 This section gives the XML Schema Definition [W3C.REC-xmlschema-1- 724 20041028], [W3C.REC-xmlschema-2-20041028] of the "application/ 725 held+xml" format. 727 729 737 739 741 742 743 744 746 748 750 753 754 755 756 758 759 760 761 763 764 765 766 767 768 769 770 772 773 774 775 777 778 779 780 781 782 784 785 786 788 790 791 792 793 794 795 796 798 800 Figure 9 802 7. Acknowledgments 804 The authors would like to thank 806 8. Security Considerations 808 Security Considerations to be included in later versions of this 809 document. 811 9. References 813 9.1. Normative References 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 819 Schoenwaelder, Ed., "Structure of Management Information 820 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 822 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 823 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 824 STD 58, RFC 2579, April 1999. 826 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 827 "Conformance Statements for SMIv2", STD 58, RFC 2580, 828 April 1999. 830 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 831 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 832 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 834 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 836 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 837 "Introduction and Applicability Statements for Internet- 838 Standard Management Framework", RFC 3410, December 2002. 840 [W3C.CR-wsdl20-20051215] 841 Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, 842 "Web Services Description Language (WSDL) Version 2.0 Part 843 1: Core Language", W3C CR CR-wsdl20-20051215, 844 December 2005. 846 [W3C.REC-soap12-part1-20030624] 847 Gudgin, M., Hadley, M., Mendelsohn, N., Nielsen, H., and 848 J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", 849 World Wide Web Consortium FirstEdition REC-soap12-part1- 850 20030624, June 2003, 851 . 853 [W3C.REC-soap12-part2-20030624] 854 Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and 855 J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 856 Web Consortium FirstEdition REC-soap12-part2-20030624, 857 June 2003, 858 . 860 9.2. Informative References 862 [I-D.ietf-mediactrl-architecture] 863 Melanchuk, T., "An Architectural Framework for Media 864 Server Control", draft-ietf-mediactrl-architecture-04 865 (work in progress), November 2008. 867 [I-D.ietf-mediactrl-requirements] 868 Dolly, M. and R. Even, "Media Server Control Protocol 869 Requirements", draft-ietf-mediactrl-requirements-04 (work 870 in progress), February 2008. 872 [I-D.ietf-mediactrl-sip-control-framework] 873 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 874 Control Channel Framework", 875 draft-ietf-mediactrl-sip-control-framework-10 (work in 876 progress), February 2009. 878 Authors' Addresses 880 Chris Boulton 881 NS-Technologies 883 Email: chris@ns-technologies.com 885 Lorenzo Miniero 886 University of Napoli 888 Email: lorenzo.miniero@unina.it