idnits 2.17.1 draft-dolly-xcon-mediacntrlframe-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 399. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 (June 12, 2006) is 6520 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) == Unused Reference: 'I-D.ietf-sip-gruu' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-simple-event-list' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-app-interaction-framework' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-dialog-package' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'I-D.vandyke-mscml' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'IEEE.1003.1-2001' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC1889' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC2327' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'RFC2833' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC3435' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC3525' is defined on line 332, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-01 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-05 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-app-interaction-framework-01 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-02 == Outdated reference: A later version (-09) exists of draft-vandyke-mscml-04 -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2833 (Obsoleted by RFC 4733, RFC 4734) -- Obsolete informational reference (is this intentional?): RFC 3525 (Obsoleted by RFC 5125) Summary: 8 errors (**), 0 flaws (~~), 26 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON M. Dolly 3 Internet-Draft G. Munson 4 Expires: December 14, 2006 AT&T Labs 5 J. Rafferty 6 Cantata 7 June 12, 2006 9 Media Control Protocol Requirements 10 draft-dolly-xcon-mediacntrlframe-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 14, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document provides requirements for a protocol, that will enable 44 one physical entity that includes the media policy server, 45 notification server and the focus to interact with one or more 46 physical entities that serves as mixer or media server. It will 47 address all phases and aspects of media handling in a conferencing 48 service including announcements and IVR functionality. 50 Table of Contents 52 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Media Control Requirements . . . . . . . . . . . . . . . . 4 56 3.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.3. Operational Requirements . . . . . . . . . . . . . . . . . 6 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. Changes from Version-01 . . . . . . . . . . . . . . . . . . . 6 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 62 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Intellectual Property and Copyright Statements . . . . . . . . . . 10 67 1. Overview 69 The IETF XCON conferencing framework presents an architecture that is 70 built of several functional entities. The framework document does 71 not specify the protocols between the functional entities since it is 72 considered out of scope. 74 There is an interest to work on a protocol that will enable one 75 physical entity that includes the media policy server, notification 76 server and the focus to interact with one or more physical entities 77 that serves as mixer or media server. 79 The document will present the requirements for such a protocol. It 80 will address all phases and aspects of media handling in a enhanced 81 conferencing service including announcements and IVR functionality. 82 The following items are out of scope of this document: 83 Mechanism for MS to advertise its capabilities and other 84 attributes (e.g, Geolocation). 85 Mechanism for the AS to discover a MS. 86 Ability to move an existing conference from the current Media 87 Servers supporting it to other Media Servers, where the latter 88 have been identified to the AS. 90 2. Terminology 92 The Media Server work uses when appropriate and expands on the 93 terminology introduced in the SIP conferencing framework and XCON 94 conferencing framework. The following additional terms are defined 95 for use within the Media Server work. 97 Application Server (AS) - The application server includes the 98 conference policy server, the focus and the conference notification 99 server as defined in draft-ietf-sipping-conferencing-framework. 101 Media Server (MS) - The media server includes the mixer as defined in 102 draft-ietf-sipping-conferencing-framework. The media server source 103 media streams for announcements, it process media streams for 104 functions like DTMF detection and transcoding. The media server may 105 also record media streams for supporting IVR functions like 106 announcing participants 108 Notification - A notification is used when there is a need to report 109 event related information from the MS to the AS. 111 Request - A request is sent from the controlling entity, such as an 112 Application Server, to another resource, such as a Media Server, 113 asking that a particular type of operation be executed. 115 Response - A response is used to signal information such as an 116 acknowledgement or error code in reply to a previously issued 117 request. 119 Need to add additional definitions 121 3. Requirements 123 3.1. Media Control Requirements 125 The following are the media control requirements: 127 REQ-MCP-01 - There MUST be a requirement for a control protocol that 128 will enable one or more Application Servers to control a media 129 server. 131 REQ-MCP-02 The protocol MUST be independent from the transport 132 protocol. 134 REQ-MCP-03 The protocol MUST use a reliable transport protocol. 136 REQ-MCP-04 - The application scope of the protocol shall include 137 Enhanced Conferencing Control and Interactive Voice Response. 139 Though the protocol enables these services, the functionality is 140 invoked through other mechanisms. 142 REQ-MCP-05 - The protocol will utilize an XML markup language. 144 REQ-MCP-06 - A Media Server SHOULD be application/service 145 independent. It should be possible to have a many-to-many 146 relationship between Application Servers and Media Servers that 147 use this protocol. 149 REQ-MCP-07 - Media types that are supported in the context of the 150 applications shall include audio, tones, text and video. 152 REQ-MCP-08 - The protocol should allow, but must not require, a media 153 server resource broker or intermediate proxy to exist between the 154 Application Server and Media Server. 156 REQ-MCP-09 - The solution MUST enable one control channel between an 157 AS and MS, and shall allow for the support of multiple channels. 159 One channel could control multiple conferences, but you could have 160 multiple channels controlling one or more conferences. 162 There can be a connection per conference or one connection from the 163 AS to MS for controlling many conferences 165 REQ-MCP-10 - On the control channel, there shall be requests to the 166 MS, responses from the MS and notifications to the AS. 168 REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify RTP 169 connections to a Media Server. 171 REQ-MCP-12 - It should be possible to support a single conference 172 spanning multiple Media Servers. 173 Note: The previous draft used "must". It is probably true that 174 spanning multiple MSes can be accomplished by the AS and does not 175 require anything in the protocol for the scenarios we have in 176 mind. However, the concern is that if this requirement is treated 177 too lightly, one may end up with a protocol that precludes its 178 support. Therefore, we are reluctant to weaken this requirement 179 any further than "should". 181 REQ-MCP-13 - It must be possible to split call legs individually or 182 in groups away from a main conference on a given Media Server, 183 without performing SIP re-establishment of the call legs to the MS 184 (e.g., for purposes such as performing IVR with a single call leg 185 or creating sub-conferences, not for creating entirely new 186 conferences). 188 REQ-MCP-14 - The protocol should be extendable, facilitating forward 189 and backward compatibility. 191 REQ-MCP-15 - The protocol shall include security mechanisms. 193 REQ-MCP-16 - During session establishment, there shall be a 194 capability to negotiate parameters that are associated with media 195 streams. 197 REQ-MCP-17 - The AS shall be able to define operations that the MS 198 will perform on streams like mute and gain control. 200 REQ-MCP-18 - The AS shall be able to instruct the MS to play a 201 specific announcement. 203 REQ-MCP-19 - The MS shall be able to retrieve announcements from an 204 external connection. 206 REQ-MCP-20 - The MS shall be able to request the MS to create, 207 delete, and manipulate a mixing, IVR or announcement session. 209 REQ-MCP-21 - The AS shall be able to tell the MS if the message can 210 be delayed if the MS cannot play it immediately. 212 REQ-MCP-22 - The AS shall be able to instruct the MS to play 213 announcements to a single user or to a conference mix. 215 3.2. 217 Media Mixing Requirements are for further discussion. 219 3.3. Operational Requirements 221 REQ-MCP-23 - The AS-MS control protocol must allow the AS to audit 222 the MS state, during an active session. 224 REQ-MCP-24 - The MS shall be able to inform the AS about its status 225 during an active session. 227 4. Security Considerations 229 As an XML markup, all of the security considerations of RFC3023 230 [RFC3023] and RFC3406 [RFC3406] must be met. Pay particular 231 attention to the robustness requirements of parsing XML. 233 The protocol shall include security mechanisms. 235 5. Changes from Version-01 237 The document was updated per the notes from the BOF meeting in March, 238 and comments from Roni Even. 240 6. References 242 6.1. Normative References 244 [I-D.ietf-sip-gruu] 245 Rosenberg, J., "Obtaining and Using Globally Routable User 246 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 247 (SIP)", draft-ietf-sip-gruu-01 (work in progress), 248 February 2004. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 254 Specifications: ABNF", RFC 2234, November 1997. 256 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 257 Types", RFC 3023, January 2001. 259 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 260 A., Peterson, J., Sparks, R., Handley, M., and E. 261 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 262 June 2002. 264 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 265 Event Notification", RFC 3265, June 2002. 267 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 268 "Uniform Resource Names (URN) Namespace Definition 269 Mechanisms", BCP 66, RFC 3406, October 2002. 271 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 272 January 2004. 274 [W3C.REC-xmlschema-1-20010502] 275 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 276 "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1- 277 20010502, May 2001. 279 6.2. Informative References 281 [I-D.ietf-simple-event-list] 282 Roach, A., Rosenberg, J., and B. Campbell, "A Session 283 Initiation Protocol (SIP) Event Notification Extension for 284 Resource Lists", draft-ietf-simple-event-list-05 (work in 285 progress), August 2004. 287 [I-D.ietf-sipping-app-interaction-framework] 288 Rosenberg, J., "A Framework for Application Interaction in 289 the Session Initiation Protocol (SIP)", 290 draft-ietf-sipping-app-interaction-framework-01 (work in 291 progress), February 2004. 293 [I-D.ietf-sipping-dialog-package] 294 Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated 295 Dialog Event Package for the Session Initiation Protocol 296 (SIP", draft-ietf-sipping-dialog-package-02 (work in 297 progress), June 2003. 299 [I-D.vandyke-mscml] 300 Burger, E., Van Dyke, J., and A. Spitzer, "Media Server 301 Control Markup Language (MSCML) and Protocol", 302 draft-vandyke-mscml-04 (work in progress), March 2004. 304 [IEEE.1003.1-2001] 305 Institute of Electrical and Electronics Engineers, 306 "Information Technology - Portable Operating System 307 Interface (POSIX) - Part 1: Base Definitions, Chapter 9", 308 IEEE Standard 1003.1, June 2001. 310 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 311 Jacobson, "RTP: A Transport Protocol for Real-Time 312 Applications", RFC 1889, January 1996. 314 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 315 Protocol", RFC 2327, April 1998. 317 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 318 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 319 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 321 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 322 Digits, Telephony Tones and Telephony Signals", RFC 2833, 323 May 2000. 325 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 326 with Session Description Protocol (SDP)", RFC 3264, 327 June 2002. 329 [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control 330 Protocol (MGCP) Version 1.0", RFC 3435, January 2003. 332 [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, 333 "Gateway Control Protocol Version 1", RFC 3525, June 2003. 335 [W3C.REC-xml-20001006] 336 Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 337 "Extensible Markup Language (XML) 1.0 (Second Edition)", 338 W3C REC REC-xml-20001006, October 2000. 340 Appendix A. Acknowledgments 342 The authors would like to thank Eric Burger for his guidance, and 343 Roni Even for earlier requirements work in this area. 345 Authors' Addresses 347 Martin Dolly 348 AT&T Labs 349 200 Laurel Avenue 350 Middletown, NJ 07748 351 USA 353 Phone: 354 Email: mdolly@att.com 355 URI: 357 Gary Munson 358 AT&T Labs 359 200 Laurel Avenue 360 Middletown, NJ 07748 361 USA 363 Phone: 364 Email: gamunson@att.com 365 URI: 367 James Rafferty 368 Cantata 369 410 First Avenue 370 Needham, MA 02494 371 US 373 Phone: 374 Email: jraff@cantata.com 375 URI: 377 Intellectual Property Statement 379 The IETF takes no position regarding the validity or scope of any 380 Intellectual Property Rights or other rights that might be claimed to 381 pertain to the implementation or use of the technology described in 382 this document or the extent to which any license under such rights 383 might or might not be available; nor does it represent that it has 384 made any independent effort to identify any such rights. Information 385 on the procedures with respect to rights in RFC documents can be 386 found in BCP 78 and BCP 79. 388 Copies of IPR disclosures made to the IETF Secretariat and any 389 assurances of licenses to be made available, or the result of an 390 attempt made to obtain a general license or permission for the use of 391 such proprietary rights by implementers or users of this 392 specification can be obtained from the IETF on-line IPR repository at 393 http://www.ietf.org/ipr. 395 The IETF invites any interested party to bring to its attention any 396 copyrights, patents or patent applications, or other proprietary 397 rights that may cover technology that may be required to implement 398 this standard. Please address the information to the IETF at 399 ietf-ipr@ietf.org. 401 Disclaimer of Validity 403 This document and the information contained herein are provided on an 404 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 405 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 406 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 407 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 408 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 409 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 411 Copyright Statement 413 Copyright (C) The Internet Society (2006). This document is subject 414 to the rights, licenses and restrictions contained in BCP 78, and 415 except as set forth therein, the authors retain all their rights. 417 Acknowledgment 419 Funding for the RFC Editor function is currently provided by the 420 Internet Society.