Subject: [mediactrl] FW: draft-dolly-xcon-mediacntrlframe-02.txt submission

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 22 Jun 2006 14:19:10 +0100

<SPAN 
class=549251513-22062006>Hello,
<SPAN 
class=549251513-22062006> 
<SPAN 
class=549251513-22062006>The requirements draft has been updated per 
the BOF meeting notes from March and Roni's comments, with the exception of 
the architectural specific comments and leaving media mixing for further 
study<SPAN 
class=549251513-22062006>.
 
<FONT 
color=#0000ff>Also, I would like to 
attend ECRIT which is during the time slot proposed for our July 
meeting.
<SPAN 
class=549251513-22062006> 
<SPAN 
class=549251513-22062006>Cheers,
<SPAN 
class=549251513-22062006> 
<SPAN 
class=549251513-22062006>Martin

From: Dolly, Martin C, ALABS Sent: 
Thursday, June 22, 2006 9:14 AMTo: 
[email-masked]: Munson, Gary A, ALABS; 'Rafferty, James'; 
'Burger, Eric'Subject: draft-dolly-xcon-mediacntrlframe-02.txt 
submission

<FONT face=Arial 
size=2>Internet-Drafts Administrator:
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  
  Please accept the submission for the 
  following
  individual internet draft. Please let me know if 
  you
  need any further help with this 
  draft.
  
  Thank you very much for your help with this<SPAN 
  class=980462823-16102005> I-D submission.
  Cheers, 
  
  <FONT face=Arial 
  size=2> 
  <FONT face=Arial 
  size=2>Martin
   
  Draft name: 
  draft-dolly-xcon-mediacntrlframe-0<FONT 
  color=#0000ff> 2 .txt
  <FONT face=Arial 
  size=2>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.<FONT face=Arial 
  color=#0000ff 
size=2> 

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: [email-masked]
   URI:

   Gary Munson
   AT&T Labs
   200 Laurel Avenue
   Middletown, NJ  07748
   USA

   Phone:
   Email: [email-masked]
   URI:

   James Rafferty
   Cantata
   410 First Avenue
   Needham, MA  02494
   US

   Phone:
   Email: [email-masked]
   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
   [email-masked].

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]

---

From: "Adi Even-Tzur" <[email-masked]>
Date: Mon, 26 Jun 2006 13:52:21 +0100

<span
style='font-size:10.0pt;font-family:Arial;color:navy'>Hi Martin,

<span
style='font-size:10.0pt;font-family:Arial;color:navy'> 

<span
style='font-size:10.0pt;font-family:Arial;color:navy'>I have a question
regarding the updated version of the requirements draft – although there
are requirements for specific application capabilities, such as IVR and
announcement management (REQ-MCP-18-22), it is lacking any requirements
regarding the ability of the AS to control the MS that concern video applications,
such as control video layout etc. 

<span
style='font-size:10.0pt;font-family:Arial;color:navy'>Is it on purpose and video
application requirements are under REQ-MCP-14? 

<span
style='font-size:10.0pt;font-family:Arial;color:navy'> 

<span
style='font-size:10.0pt;font-family:Arial;color:navy'> 

<p class=MsoAutoSig dir=LTR style='text-align:left;direction:ltr;unicode-bidi:
embed'><span style='font-size:
10.0pt;font-family:"Comic Sans MS";color:blue'>thanks,

<p class=MsoAutoSig dir=LTR style='text-align:left;direction:ltr;unicode-bidi:
embed'><span style='font-size:
10.0pt;font-family:"Comic Sans MS";color:blue'>Adi.

<span
style='font-size:10.0pt;font-family:Arial;color:navy'> 

<span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----
From:
[email-masked]
[mailto:[email-masked]] <span style='font-weight:
bold'>On Behalf Of Dolly, Martin C, ALABS
Sent: Thursday, June 22, 2006 4:22
PM
To:
[email-masked]
Subject: [mediactrl] FW:
draft-dolly-xcon-mediacntrlframe-02.txt submission

<font size=3
face="Times New Roman"> 

<font size=2 color=blue
face=Arial>Hello,

<font size=3
face="Times New Roman"> 

<font size=2 color=blue
face=Arial>The
requirements draft has been updated per the BOF meeting notes from
March and Roni's comments, with the exception of the architectural specific
comments and leaving media mixing for further study.

<font size=3
face="Times New Roman"> 

<font size=2 color=blue
face=Arial>Also, I
would like to attend ECRIT which is during the time slot proposed for our July
meeting.

<font size=3
face="Times New Roman"> 

<font size=2 color=blue
face=Arial>Cheers,

<font size=3
face="Times New Roman"> 

<font size=2 color=blue
face=Arial>Martin

<font size=3
face="Times New Roman"> 

<div class=MsoNormal align=center dir=LTR style='margin-left:.5in;text-align:
center'>

<p class=MsoNormal dir=LTR style='margin-right:0in;margin-bottom:12.0pt;
margin-left:.5in'><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:<font size=2
face=Tahoma> Dolly, Martin C,
ALABS 
Sent: Thursday, June 22, 2006 9:14
AM
To: [email-masked]
Cc: Munson, Gary A, ALABS;
'Rafferty, James'; 'Burger, Eric'
Subject:
draft-dolly-xcon-mediacntrlframe-02.txt submission

<span
style='font-size:10.0pt;font-family:Arial'>Internet-Drafts Administrator:

<blockquote style='border:none;border-right:solid blue 1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<span
style='font-size:10.0pt;font-family:Arial'>Please accept the submission for the
following

<span
style='font-size:10.0pt;font-family:Arial'>individual internet draft. Please
let me know if you

<span
style='font-size:10.0pt;font-family:Arial'>need any further help with this
draft.

<span
style='font-size:10.0pt;font-family:Arial'>Thank you very much for your help
with this I-D submission.

<span
style='font-size:10.0pt;font-family:Arial'>Cheers, 

<span
style='font-size:12.0pt;font-family:Tahoma'> 

<span
style='font-size:10.0pt;font-family:Arial'>Martin

<span
style='font-size:12.0pt;font-family:Tahoma'> 

<span
style='font-size:10.0pt;font-family:Arial'>Draft name:
draft-dolly-xcon-mediacntrlframe-0 2 .txt

<span
style='font-size:10.0pt;font-family:Arial'>Abstract:

<span
style='font-size:12.0pt;font-family:Tahoma'>   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.
<span style='font-size:10.0pt;
font-family:Arial;color:blue'>