idnits 2.17.1 draft-dolly-mediactrl-requirements-00.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 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. 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 (June 12, 2007) is 6162 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: December 14, 2007 Polycom 6 June 12, 2007 8 Media Server Control Protocol Requirements 9 draft-dolly-mediactrl-requirements-00.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 December 14, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document addresses the communication between an application 43 server and media server. The current work in SIPPING and XCON 44 working groups show these logical entities but do not address the 45 physical decomposition and the protocol between the entities. 47 This document presents the requirements from 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, IVR and 50 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 . . . . . . . . . . . . . . . . . . . . . 6 60 3.4. Operational Requirements . . . . . . . . . . . . . . . . . 7 61 4. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Introduction 72 The IETF SIPPING conferencing framework RFC 4353[CARCH] presents an 73 architecture that is built of several functional entities. The 74 framework document does not specify the protocols between the 75 functional entities since it is considered out of scope. 77 There is an interest to work on a protocol that will enable one 78 physical entity that includes the conference/media policy server, 79 notification server and the focus also known as Application server to 80 interact with one or more physical entities, called Media Server, 81 that serves as mixer or media server. 83 The Media server may also be used for announcements and IVR 84 (Interactive Voice Response) functions. 86 The decomposition to a media server and application server is 87 described in the media control framework document[mediactrl-fw]. 89 This document presents the requirements from a media server control 90 protocol (MCP) that enables an application server to use a media 91 server. It will address the aspects of announcements, IVR and 92 conferencing media services. 94 The requirements are from the protocol and do not address the AS or 95 MS functionality discussed in the media control framework. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC2119[RFC2119] and 102 indicate requirement levels for compliant RTP implementations. 104 The Media Server work uses, when appropriate, and expands on the 105 terminology introduced in the SIP conferencing framework[CARCH] and 106 XCON conferencing framework[xcon-framework]. The following 107 additional terms are defined: 109 Application Server (AS) - A functional entity that hosts one or more 110 instances of a communications application. The application server 111 includes the conference policy server, the focus and the conference 112 notification server as defined in [CARCH]. It can include also 113 communication applications that use IVR or announcements services. 115 Media Server (MS) - The media server includes the mixer as defined in 116 [CARCH]. The media server source media streams for announcements, it 117 process media streams for functions like DTMF detection and 118 transcoding. The media server may also record media streams for 119 supporting IVR functions like announcing participants 121 Media Resource Broker (MRB) - A logical entity that is responsible 122 for both collection of appropriate published Media Server (MS) 123 information and supplying of appropriate MS information to consuming 124 entities. 126 Notification - A notification is used when there is a need to report 127 event related information from the MS to the AS. 129 Request - A request is sent from the controlling entity, such as an 130 Application Server, to another resource, such as a Media Server, 131 asking that a particular type of operation be executed. 133 Response - A response is used to signal information such as an 134 acknowledgement or error code in reply to a previously issued 135 request. 137 3. Requirements 139 3.1. Media Control Requirements 141 The following are the media control requirements: 143 REQ-MCP-01 - The MS control protocol SHALL enable one or more 144 Application Servers to control one or more media servers. 146 REQ-MCP-02 The MS control protocol SHALL be independent from the 147 transport protocol. 149 REQ-MCP-03 The MS control protocol SHALL use a reliable transport 150 protocol. 152 REQ-MCP-04 - The application scope of the protocol shall include 153 Conferencing and Interactive Voice Response media services. 155 Note: Though the protocol enables these services, the functionality 156 is invoked through other mechanisms. 158 REQ-MCP-05 - Media types supported in the context of the 159 applications shall include audio, tones, text and video. 161 REQ-MCP-06- The MS control protocol should allow, but must not 162 require, a media resource broker (MRB) or intermediate proxy to 163 exist with the Application Server and Media Server. 165 REQ-MCP-07 - The solution MUST enable one control channel between an 166 AS and MS, and SHOULD allow for the support of multiple channels. 168 One control channel could control multiple sessions, but you could 169 have multiple control channels controlling one or more sessions. 171 REQ-MCP-8 - On the MS control channel, there shall be requests to 172 the MS, responses from the MS and notifications to the AS. 174 REQ-MCP-9 - SIP/SDP SHALL be used to establish and modify media 175 connections to a Media Server. 177 REQ-MCP-10 - It should be possible to support a single conference 178 spanning multiple Media Servers. 180 Note: It is probable that spanning multiple MS can be accomplished 181 by the AS and does not require anything in the protocol for the 182 scenarios we have in mind. However, the concern is that if this 183 requirement is treated too lightly, one may end up with a protocol 184 that precludes its support. 186 REQ-MCP-11 - It must be possible to split call legs individually or 187 in groups away from a main conference on a given Media Server, 188 without performing re-establishment of the call legs to the MS 189 (e.g., for purposes such as performing IVR with a single call leg 190 or creating sub-conferences, not for creating entirely new 191 conferences). 193 REQ-MCP-12 - The MS control protocol should be extendable, 194 facilitating forward and backward compatibility. 196 REQ-MCP-13 - The MS control protocol shall include security 197 mechanisms. 199 REQ-MCP-14 - During session establishment, there shall be a 200 capability to negotiate parameters that are associated with media 201 streams. 203 REQ-MCP-15 - The AS shall be able to define operations that the MS 204 will perform on streams like mute and gain control. 206 REQ-MCP-16 - The AS shall be able to instruct the MS to play a 207 specific announcement. 209 REQ-MCP-17 - The AS shall be able to request the MS to create, 210 delete, and manipulate a mixing, IVR or announcement session. 212 REQ-MCP-18 - The AS shall be able to instruct the MS to play 213 announcements to a single user or to a conference mix. 215 REQ-MCP-19 - The MS control protocol SHOULD enable the AS to ask the 216 MS for session summary report. 218 REQ-MCP-20 - The MS shall be able to notify the AS of events 219 received in the media stream if requested by AS. (Examples - STUN 220 request, Flow Control, etc.) 222 3.2. Media mixing Requirements 224 REQ-MCP-21 - The AS shall be able to define a conference mix. 226 REQ-MCP-22 - The AS may be able to define a separate mix for each 227 participant. 229 REQ-MCP-23 - The AS may be able to define a custom video layout 230 built of rectangular sub windows. 232 REQ-MCP-24 - For video the AS shall be able to map a stream to a 233 specific sub-window or to define to the MS how to decide which 234 stream will go to each sub window. The number of sub-windows will 235 start from one. 237 REQ-MCP-25 - The MS shall be able to notify the AS who is the active 238 speaker. 240 REQ-MCP-26 - The MS shall be able to inform the AS which layouts it 241 supports. 243 REQ-MCP-27 - The MS control protocol should enable the AS to 244 instruct the MS to record a specific conference mix. 246 3.3. IVR Requirements 248 REQ-MCP-28 - The AS shall be able to load one or more IVR script to 249 the MS and receive the results. 251 REQ-MCP-29 - The AS shall be able to mange the IVR session by 252 sending announcements and receiving the response (e.g., DTMF). 254 REQ-MCP-30 - The AS should be able to instruct the MS to record a 255 short participant stream and play it back to the conference. This 256 is not a recording requirement. 258 3.4. Operational Requirements 260 These requirements may be applicable to the MRB. 262 REQ-MCP-31 - The MS control protocol must allow the AS to audit the 263 MS state, during an active session. 265 REQ-MCP-32 - The MS shall be able to inform the AS about its status 266 during an active session. 268 4. IANA consideration 270 There are no IANA considerations. 272 5. Security Considerations 274 The protocol shall include security mechanisms. 276 6. Acknowledgment 278 would also like to acknowledge the work of Gary Munson from AT &T 279 Labs and James Rafferty from Cantata who helped with drafting 280 draft-dolly-xcon-mediacntrlframe-02 on which this work is based. 282 7. References 284 7.1. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 7.2. Informative References 291 [CARCH] Rosenberg, J., "A Framework for Conferencing with the 292 Session Initiation Protocol (SIP)", RFC 4353, 293 February 2006. 295 [mediactrl-fw] 296 Melanchuk, T., "An Architectural Framework for Media 297 Server Control", draft-melanchuk-mediactrl-framework-00 298 (work in progress), June 2007. 300 [xcon-framework] 301 Barnes, M., "A Framework for Centralized Conferencing", 302 draft-ietf-xcon-framework-08 (work in progress), May 2007. 304 Authors' Addresses 306 Martin Dolly 307 AT&T Labs 308 200 Laurel Avenue 309 Middletown, NJ 07748 310 USA 312 Phone: 313 Email: mdolly@att.com 314 URI: 316 Roni Even 317 Polycom 318 94 Derech Em Hamoshavot 319 Petach Tikva 49130 320 Israel 322 Email: roni.even@polycom.co.il 324 Full Copyright Statement 326 Copyright (C) The IETF Trust (2007). 328 This document is subject to the rights, licenses and restrictions 329 contained in BCP 78, and except as set forth therein, the authors 330 retain all their rights. 332 This document and the information contained herein are provided on an 333 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 334 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 335 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 336 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 337 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 338 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 340 Intellectual Property 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at 362 ietf-ipr@ietf.org. 364 Acknowledgment 366 Funding for the RFC Editor function is provided by the IETF 367 Administrative Support Activity (IASA).