idnits 2.17.1 draft-ietf-mediactrl-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2008) is 5877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mediactrl M. Dolly 3 Internet-Draft AT&T Labs 4 Intended status: Informational R. Even 5 Expires: August 27, 2008 Polycom 6 February 24, 2008 8 Media Server Control Protocol Requirements 9 draft-ietf-mediactrl-requirements-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 27, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document addresses the communication between an application 43 server and media server. The current work in IETF working groups 44 shows these logical entities but does not address the physical 45 decomposition and the protocol between the entities. 47 This document presents the requirements for a media server control 48 protocol (MCP) that enables an application server to use a media 49 server. It will address the aspects of announcements, Interactive 50 Voice Response and conferencing media services. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Media Control Requirements . . . . . . . . . . . . . . . . 4 58 3.2. Media mixing Requirements . . . . . . . . . . . . . . . . 6 59 3.3. IVR Requirements . . . . . . . . . . . . . . . . . . . . . 7 60 3.4. Operational Requirements . . . . . . . . . . . . . . . . . 7 61 4. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . . . 10 68 1. Introduction 70 The IETF conferencing framework in RFC4353[CARCH] presents an 71 architecture that is built of several functional entities. 72 RFC4353[CARCH] does not specify the protocols between the functional 73 entities since it is considered out of scope. 75 Based on RFC4353 [CARCH] the document defines the requirements for a 76 protocol that will enable one functional entity, known as an 77 Application Server (AS), that includes the conference/media policy 78 server, the notification server and the focus, all defined in RFC 79 4353[CARCH], to interact with one or more functional entities, called 80 Media Server (MS), that serves as mixer or media server. 82 The Media server can also be used for announcements and Interactive 83 Voice Response (IVR) functions. 85 Application Servers host one or more instances of a communications 86 application. Media servers provide real time media processing 87 functions. An example of the decomposition of a media server and an 88 application server is described in the media control framework 89 document[mediactrl-fw]. 91 This document presents the requirements for a media server control 92 protocol (MCP) that enables an application server to control a media 93 server. It will address the aspects of announcements, IVR and 94 conferencing media services. 96 The requirements are for the protocol and do not address the AS or MS 97 functionality discussed in the media control framework. 99 Since the media server is a centralized component, the charter of the 100 working group states that this work will not investigate distributed 101 media processing algorithms or control protocols. 103 2. Terminology 105 The Media Server work uses, when appropriate, and expands on the 106 terminology introduced in the conferencing framework[CARCH] and 107 Centralized Conferencing (XCON) conferencing 108 framework[xcon-framework]. The following additional terms are 109 defined: 111 Application Server (AS) - A functional entity that hosts one or more 112 instances of a communications application. The application server 113 may include the conference policy server, the focus and the 114 conference notification server as defined in [CARCH]. It may include 115 also communication applications that use IVR or announcements 116 services. 118 Media Server (MS) - The media server includes the mixer as defined in 119 [CARCH]. The media server plays announcements, it processes media 120 streams for functions like DTMF detection and transcoding. The media 121 server may also record media streams for supporting IVR functions 122 like announcing participants 124 Media Resource Broker (MRB) - A logical entity that is responsible 125 for both collection of appropriate published Media Server (MS) 126 information and supplying of appropriate MS information to consuming 127 entities. The MRB is an optional entity and will be discussed in a 128 separate document. 130 Notification - A notification is used when there is a need to report 131 event related information from the MS to the AS. 133 Request - A request is sent from the controlling entity, such as an 134 Application Server, to another resource, such as a Media Server, 135 asking that a particular type of operation be executed. 137 Response - A response is used to signal information such as an 138 acknowledgement or error code in reply to a previously issued 139 request. 141 3. Requirements 143 3.1. Media Control Requirements 145 The following are the media control requirements: 147 REQ-MCP-01 - The MS Control Protocol shall enable one or more 148 Application Servers to request media services from one or more 149 Media Servers. 151 REQ-MCP-02 The MS Control Protocol shall use a reliable transport 152 protocol. 154 REQ-MCP-03 - The applications supported by the protocol shall 155 include Conferencing and Interactive Voice Response media 156 services. 158 Note: Though the protocol enables these services, the functionality 159 is invoked through other mechanisms. 161 REQ-MCP-04 - Media types supported in the context of the 162 applications shall include audio, tones, text and video. Tones 163 media include in band audio or RFC 4733 payload. 165 REQ-MCP-05- The MS control protocol should allow, but must not 166 require, a media resource broker (MRB) or intermediate proxy to 167 exist with the Application Server and Media Server. 169 REQ-MCP-06 - On the MS control channel, there shall be requests to 170 the MS, responses from the MS and notifications to the AS. 172 REQ-MCP-07 - SIP/SDP shall be used to establish and modify media 173 connections to a Media Server. 175 REQ-MCP-08 - It should be possible to support a single conference 176 spanning multiple Media Servers. 178 Note: It is probable that spanning multiple MS can be accomplished 179 by the AS and does not require anything in the protocol for the 180 scenarios we have in mind. However, the concern is that if this 181 requirement is treated too lightly, one may end up with a protocol 182 that precludes its support. 184 REQ-MCP-09 - It must be possible to split call legs individually or 185 in groups away from a main conference on a given Media Server, 186 without performing re-establishment of the call legs to the MS 187 (e.g., for purposes such as performing IVR with a single call leg 188 or creating sub-conferences, not for creating entirely new 189 conferences). 191 REQ-MCP-10 - The MS control protocol should be extendable, 192 facilitating forward and backward compatibility. 194 REQ-MCP-11 - The MS control protocol shall include an authentication 195 component to ensure that only an authorized AS can communicate 196 with the MS and vice versa. 198 REQ-MCP-12 - The MS control protocol shall use some form of 199 transport protection to ensure the confidentiality and integrity 200 of the data between the AS and MS. 202 REQ-MCP-13 - Different Application Servers may have different 203 privileges for using a MS. The protocol should prevent the AS for 204 doing unauthorized operations on a MS. 206 REQ-MCP-14 - The MS control protocol requires mechanisms to protect 207 the MS resources used by one AS from another AS since the solution 208 need to support multiple AS controlling one MS. 210 REQ-MCP-15 - During session establishment, there shall be a 211 capability to negotiate parameters that are associated with media 212 streams. This requirement should enable also an AS managing 213 conference to specify the media streams allowed in the conference. 215 REQ-MCP-16 - The AS shall be able to instruct the MS to perform 216 streams operations like mute and gain control. 218 REQ-MCP-17 - The AS shall be able to instruct the MS to play a 219 specific announcement. 221 REQ-MCP-18 - The AS shall be able to request the MS to create, 222 delete, and manipulate a mixing, IVR or announcement session. 224 REQ-MCP-19 - The AS shall be able to instruct the MS to play 225 announcements to a single user or to a conference mix. 227 REQ-MCP-20 - The MS control protocol should enable the AS to ask the 228 MS for session summary report. The report may include resources 229 usage and quality metrics. 231 REQ-MCP-21 - The MS shall be able to notify the AS of events 232 received in the media stream if requested by AS. (Examples - STUN 233 request, Flow Control, etc.) 235 3.2. Media mixing Requirements 237 REQ-MCP-22 - The AS shall be able to define a conference mix, MS may 238 offer different mixing topologies. The conference mix may be 239 defined on a conference or user level. 241 REQ-MCP-23 - The AS may be able to define a custom video layout 242 built of rectangular sub windows. 244 REQ-MCP-24 - For video the AS shall be able to map a stream to a 245 specific sub-window or to define to the MS how to decide which 246 stream will go to each sub window. 248 REQ-MCP-25 - The MS shall be able to notify the AS who are the 249 active sources of the media; for example who is the active speaker 250 or who is being viewed in a conference. The speaker and the video 251 source may be different, for example a person describing a video 252 stream from a remote camera managed by a different user. 254 REQ-MCP-26 - The MS shall be able to inform the AS which layouts it 255 supports. 257 REQ-MCP-27 - The MS control protocol should enable the AS to 258 instruct the MS to record a specific conference mix. 260 3.3. IVR Requirements 262 REQ-MCP-28 - The AS shall be able to instruct the MS to perform one 263 or more IVR script and receive the results. The script may be in 264 a server or contained in the control message. 266 REQ-MCP-29 - The AS shall be able to manage the IVR session by 267 sending requests to play announcements to the MS and receiving the 268 response (e.g., DTMF). The IVR session flow in this case is 269 handled by the AS by starting a next phase based on the response 270 it receives from the MS on the current phase. 272 REQ-MCP-30 - The AS should be able to instruct the MS to record a 273 short participant stream and play it back. This is not a 274 recording requirement. 276 3.4. Operational Requirements 278 These requirements may be applicable to the MRB but can be used by an 279 AS if it has one to one connection to the MS. 281 REQ-MCP-31 - The MS control protocol must allow the AS to audit the 282 MS state, during an active session. 284 REQ-MCP-32 - The MS shall be able to inform the AS about its status 285 during an active session. 287 4. IANA consideration 289 There are no IANA considerations. 291 5. Security Considerations 293 This document discusses high-level requirements for MCP. The MCP has 294 some specific security requirements, which will be summarized here at 295 a very high level. 297 All of the operations and functions described in this document need 298 to be authorized by a MS or a AS. It is expected that MS resources 299 will be governed by a set of authorization rules defined as part of 300 the AS / MS policy. In order for the policy to be implemented, the 301 MS needs to be able to authenticate requests. Normal SIP mechanisms 302 including Digest authentication and certificates can be used as 303 specified in RFC3261[RFC3261] These MCP security requirements will be 304 discussed in detail in the framework and protocol documents. 306 6. Acknowledgment 308 This draft represents the work from two previous personal drafts, 309 draft-dolly-xcon-mediacntrlframe-02 and 310 draft-even-media-server-req-02. The authors would like to 311 acknowledge the work of Gary Munson from AT &T Labs and James 312 Rafferty from Cantata who helped with drafting 313 draft-dolly-xcon-mediacntrlframe-02 on which this work is based. 315 7. Informative References 317 [CARCH] Rosenberg, J., "A Framework for Conferencing with the 318 Session Initiation Protocol (SIP)", RFC 4353, 319 February 2006. 321 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 322 A., Peterson, J., Sparks, R., Handley, M., and E. 323 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 324 June 2002. 326 [mediactrl-fw] 327 Melanchuk, T., "An Architectural Framework for Media 328 Server Control", draft-ietf-mediactrl-architecture-02 329 (work in progress), February 2008. 331 [xcon-framework] 332 Barnes, M., "A Framework for Centralized Conferencing", 333 draft-ietf-xcon-framework-10 (work in progress), 334 November 2007. 336 Authors' Addresses 338 Martin Dolly 339 AT&T Labs 340 200 Laurel Avenue 341 Middletown, NJ 07748 342 USA 344 Phone: 345 Email: mdolly@att.com 346 URI: 348 Roni Even 349 Polycom 350 94 Derech Em Hamoshavot 351 Petach Tikva 49130 352 Israel 354 Email: roni.even@polycom.co.il 356 Full Copyright Statement 358 Copyright (C) The IETF Trust (2008). 360 This document is subject to the rights, licenses and restrictions 361 contained in BCP 78, and except as set forth therein, the authors 362 retain all their rights. 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 368 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Intellectual Property 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; nor does it represent that it has 379 made any independent effort to identify any such rights. Information 380 on the procedures with respect to rights in RFC documents can be 381 found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use of 386 such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository at 388 http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention any 391 copyrights, patents or patent applications, or other proprietary 392 rights that may cover technology that may be required to implement 393 this standard. Please address the information to the IETF at 394 ietf-ipr@ietf.org. 396 Acknowledgment 398 Funding for the RFC Editor function is provided by the IETF 399 Administrative Support Activity (IASA).