XCON M. Dolly Internet-Draft G. Munson Expires: December 14, 2006 AT&T Labs J. Rafferty Cantata June 12, 2006 Media Control Protocol Requirements draft-dolly-xcon-mediacntrlframe-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides requirements for a protocol, that will enable one physical entity that includes the media policy server, notification server and the focus to interact with one or more physical entities that serves as mixer or media server. It will address all phases and aspects of media handling in a conferencing service including announcements and IVR functionality. Dolly, et al. Expires December 14, 2006 [Page 1] Internet-Draft Media Control Protocol Requirements June 2006 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Media Control Requirements . . . . . . . . . . . . . . . . 4 3.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Operational Requirements . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Changes from Version-01 . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Dolly, et al. Expires December 14, 2006 [Page 2] Internet-Draft Media Control Protocol Requirements June 2006 1. Overview The IETF XCON conferencing framework presents an architecture that is built of several functional entities. The framework document does not specify the protocols between the functional entities since it is considered out of scope. There is an interest to work on a protocol that will enable one physical entity that includes the media policy server, notification server and the focus to interact with one or more physical entities that serves as mixer or media server. The document will present the requirements for such a protocol. It will address all phases and aspects of media handling in a enhanced conferencing service including announcements and IVR functionality. The following items are out of scope of this document: Mechanism for MS to advertise its capabilities and other attributes (e.g, Geolocation). Mechanism for the AS to discover a MS. Ability to move an existing conference from the current Media Servers supporting it to other Media Servers, where the latter have been identified to the AS. 2. Terminology The Media Server work uses when appropriate and expands on the terminology introduced in the SIP conferencing framework and XCON conferencing framework. The following additional terms are defined for use within the Media Server work. Application Server (AS) - The application server includes the conference policy server, the focus and the conference notification server as defined in draft-ietf-sipping-conferencing-framework. Media Server (MS) - The media server includes the mixer as defined in draft-ietf-sipping-conferencing-framework. The media server source media streams for announcements, it process media streams for functions like DTMF detection and transcoding. The media server may also record media streams for supporting IVR functions like announcing participants Notification - A notification is used when there is a need to report event related information from the MS to the AS. Request - A request is sent from the controlling entity, such as an Application Server, to another resource, such as a Media Server, asking that a particular type of operation be executed. Dolly, et al. Expires December 14, 2006 [Page 3] Internet-Draft Media Control Protocol Requirements June 2006 Response - A response is used to signal information such as an acknowledgement or error code in reply to a previously issued request. Need to add additional definitions 3. Requirements 3.1. Media Control Requirements The following are the media control requirements: REQ-MCP-01 - There MUST be a requirement for a control protocol that will enable one or more Application Servers to control a media server. REQ-MCP-02 The protocol MUST be independent from the transport protocol. REQ-MCP-03 The protocol MUST use a reliable transport protocol. REQ-MCP-04 - The application scope of the protocol shall include Enhanced Conferencing Control and Interactive Voice Response. Though the protocol enables these services, the functionality is invoked through other mechanisms. REQ-MCP-05 - The protocol will utilize an XML markup language. REQ-MCP-06 - A Media Server SHOULD be application/service independent. It should be possible to have a many-to-many relationship between Application Servers and Media Servers that use this protocol. REQ-MCP-07 - Media types that are supported in the context of the applications shall include audio, tones, text and video. REQ-MCP-08 - The protocol should allow, but must not require, a media server resource broker or intermediate proxy to exist between the Application Server and Media Server. REQ-MCP-09 - The solution MUST enable one control channel between an AS and MS, and shall allow for the support of multiple channels. One channel could control multiple conferences, but you could have multiple channels controlling one or more conferences. Dolly, et al. Expires December 14, 2006 [Page 4] Internet-Draft Media Control Protocol Requirements June 2006 There can be a connection per conference or one connection from the AS to MS for controlling many conferences REQ-MCP-10 - On the control channel, there shall be requests to the MS, responses from the MS and notifications to the AS. REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify RTP connections to a Media Server. REQ-MCP-12 - It should be possible to support a single conference spanning multiple Media Servers. Note: The previous draft used "must". It is probably true that spanning multiple MSes can be accomplished by the AS and does not require anything in the protocol for the scenarios we have in mind. However, the concern is that if this requirement is treated too lightly, one may end up with a protocol that precludes its support. Therefore, we are reluctant to weaken this requirement any further than "should". REQ-MCP-13 - It must be possible to split call legs individually or in groups away from a main conference on a given Media Server, without performing SIP re-establishment of the call legs to the MS (e.g., for purposes such as performing IVR with a single call leg or creating sub-conferences, not for creating entirely new conferences). REQ-MCP-14 - The protocol should be extendable, facilitating forward and backward compatibility. REQ-MCP-15 - The protocol shall include security mechanisms. REQ-MCP-16 - During session establishment, there shall be a capability to negotiate parameters that are associated with media streams. REQ-MCP-17 - The AS shall be able to define operations that the MS will perform on streams like mute and gain control. REQ-MCP-18 - The AS shall be able to instruct the MS to play a specific announcement. REQ-MCP-19 - The MS shall be able to retrieve announcements from an external connection. Dolly, et al. Expires December 14, 2006 [Page 5] Internet-Draft Media Control Protocol Requirements June 2006 REQ-MCP-20 - The MS shall be able to request the MS to create, delete, and manipulate a mixing, IVR or announcement session. REQ-MCP-21 - The AS shall be able to tell the MS if the message can be delayed if the MS cannot play it immediately. REQ-MCP-22 - The AS shall be able to instruct the MS to play announcements to a single user or to a conference mix. 3.2. Media Mixing Requirements are for further discussion. 3.3. Operational Requirements REQ-MCP-23 - The AS-MS control protocol must allow the AS to audit the MS state, during an active session. REQ-MCP-24 - The MS shall be able to inform the AS about its status during an active session. 4. Security Considerations As an XML markup, all of the security considerations of RFC3023 [RFC3023] and RFC3406 [RFC3406] must be met. Pay particular attention to the robustness requirements of parsing XML. The protocol shall include security mechanisms. 5. Changes from Version-01 The document was updated per the notes from the BOF meeting in March, and comments from Roni Even. 6. References 6.1. Normative References [I-D.ietf-sip-gruu] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-01 (work in progress), February 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Dolly, et al. Expires December 14, 2006 [Page 6] Internet-Draft Media Control Protocol Requirements June 2006 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [W3C.REC-xmlschema-1-20010502] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1- 20010502, May 2001. 6.2. Informative References [I-D.ietf-simple-event-list] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-05 (work in progress), August 2004. [I-D.ietf-sipping-app-interaction-framework] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", draft-ietf-sipping-app-interaction-framework-01 (work in progress), February 2004. [I-D.ietf-sipping-dialog-package] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP", draft-ietf-sipping-dialog-package-02 (work in progress), June 2003. Dolly, et al. Expires December 14, 2006 [Page 7] Internet-Draft Media Control Protocol Requirements June 2006 [I-D.vandyke-mscml] Burger, E., Van Dyke, J., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", draft-vandyke-mscml-04 (work in progress), March 2004. [IEEE.1003.1-2001] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: Base Definitions, Chapter 9", IEEE Standard 1003.1, June 2001. [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. [W3C.REC-xml-20001006] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000. Appendix A. Acknowledgments The authors would like to thank Eric Burger for his guidance, and Roni Even for earlier requirements work in this area. Dolly, et al. Expires December 14, 2006 [Page 8] Internet-Draft Media Control Protocol Requirements June 2006 Authors' Addresses Martin Dolly AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 USA Phone: Email: mdolly@att.com URI: Gary Munson AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 USA Phone: Email: gamunson@att.com URI: James Rafferty Cantata 410 First Avenue Needham, MA 02494 US Phone: Email: jraff@cantata.com URI: Dolly, et al. Expires December 14, 2006 [Page 9] Internet-Draft Media Control Protocol Requirements June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dolly, et al. Expires December 14, 2006 [Page 10]