Subject: RE: [mediactrl] How to get this work into a WG

From: "Even, Roni" <[email-masked]>
Date: Sun, 21 May 2006 13:47:34 +0100

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>During the last meeting I mentioned the
requirement document I wrote when we started the work. It is attached here; I
thought it will be added to the list of document in 

<span style='font-size:
10.0pt;font-family:Arial;color:navy'><a rel="nofollow"
href="http://flyingfox.cantata.com/i-d/mediactrl/">http://flyingfox.cantata.com/i-d/mediactrl/

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>BTW: I agree with Chris answers about the
work and want to mention that MSML and MSCML are not the only proprietary
protocols that support this interface. Polycom has its XML API that supports
this functionality and MS has proposed CCCP for the protocol.

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>I think that the consensus was to define a
protocol that will be inline with the requirements and the framework and not to
point at some vendors implementations.

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Of course we can leverage the knowledge that
was learnt by the manufacturers to create a good solution as fast as we can.

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

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

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

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

<span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:<font size=2
face=Tahoma>
[email-masked]
[mailto:[email-masked]] <span style='font-weight:
bold'>On Behalf Of Chris Boulton
Sent: Tuesday, May 09, 2006 3:40
PM
To: Adnan Saleem; Cullen Jennings;
[email-masked]
Cc: Burger, Eric
Subject: RE: [mediactrl] How to
get this work into a WG

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

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

<span
style='font-size:10.0pt'>Cullen,

I want to point out that we have rough consensus (imho) on the "control
framework" ID (<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt"
target="_blank">http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt),
from an architectural perspective and the direction this is going.

<span style='font-size:10.0pt;
font-family:Arial;color:navy;font-weight:bold;font-style:italic'>[Chris
Boulton] That’s really good to hear.

<font size=2
face="Times New Roman">However, there is no
consensus on the remaining IDs identified below.

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

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Chris Boulton] I’m not sure consensus was at all
proposed – certainly not by me.  That’s jumping the gun a
little.  I was just pointing out that we have current examples of how
Control Packages are written in-line with the framework.

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

<font size=2
face="Times New Roman">Convedia in particular
objects to the "extension" IDs listed below, covering IVR and
conference control.

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

<font size=2
face="Times New Roman">     
- (<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0"
target="_blank"><a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt">http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).

<font size=2
face="Times New Roman">     
- (<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack"
target="_blank"><a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt">http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).

<font size=2
face="Times New Roman">     
- (<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa"
target="_blank"><a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt">http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).

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

<font size=2
face="Times New Roman">The above <font
face="Times New Roman">new IDs essentially provide a subset
and duplication of the what MSML, and MSCML to a good extent, have already
provided for years.

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

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Chris Boulton] Totally understand your position.  All
I will say is that:-

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

<font size=2
color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>-<span style='font-size:7.0pt;
color:navy'>          <font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>yes, you are correct in that
this does provide duplication of MSML and MSCML.  The intention was to use
and build on the experiences gained from such languages to provide a solution
that architecturally fits with the new Control Framework.

<font size=2
color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>-<span style='font-size:7.0pt;
color:navy'>          <font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>Yes it provides subsets of
functionality.  This again was the intention to provide a modular approach. 
We are thinking (and received quite a large amount of feedback from media
control group) from the agnostic point of view that not everyone wants to
implement a large scripting language for simple IVR interactions.  It
should be possible to select exactly what you need to fit your requirements.

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

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>If you have got any more detail on your technical objections
I think it would be great to have some discussion.

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

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>Best Regards,

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

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>Chris.

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

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

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

<st1:place
 w:st="on">Garland<font
size=2> / Adnan

<span
style='font-size:10.0pt'>-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On
Behalf Of Chris
Boulton
Sent: May 8, 2006 2:36 AM
To: Cullen Jennings; MixerControl
Cc: Burger, Eric
Subject: RE: [mediactrl] How to get this work into a WG

Hi Cullen (donning AD cap),

We are still very much actively discussing this work and have met at
every IETF since Paris
(I think) - including a Beer BOF and a Meal BOF
:-).

        A long time ago, we had talked about
asking the SpeachSC chairs
if 
        that WG might take on this work. Is
there still interest in
that? 
       
Very much so - we have been discussing this regularly and I think we had
hoped (Eric will confirm but I know he is snowed under at the moment) to
move towards IETF working group towards the end of this year/maybe early
next.

        PS - A short summary of the status
of where we are, what we
have, and 
        where various parties might want to
eventually get to might be
really 
        helpful for me.

We are at the point where we have a Control Framework which has been
discussed at length at previous meetings
(<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework"
target="_blank">http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework
-02.txt) which aims to fulfill the detail outlined in the Requirements
document
(<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01"
target="_blank">http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01
.txt).  This is an agnostic approach that is not 'Media Server' specific
and aims to provide a core connection management system using SIP.

The authors of the Framework have also created a number of extensions to
the Control Framework that provides modules for achieving various levels
of Media Server Control.

- First extension provides simple IVR functionality
(<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0"
target="_blank">http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0
1.txt).

- There is an extension to the SIMPLE IVR functionality for the purpose
of using VXML
(<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack"
target="_blank">http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack
age-00.txt).

- This extensions provides conferencing capabilities
(<a rel="nofollow"
href="http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa"
target="_blank">http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa
ckage-00.txt).

If you need anymore information then give me a shout.

Best Regards,

Chris.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Cullen
Jennings
Sent: 07 May 2006 16:11
To: MixerControl
Subject: [mediactrl] How to get this work into a WG

A long time ago, we had talked about asking the SpeachSC chairs if 
that WG might take on this work. Is there still interest in that? 
With my AD hat on, I have no idea what is the best way to do this yet 
but I am looking for input on what the next logical steps are with 
all the work that has been happing here.

Thanks, Cullen

PS - A short summary of the status of where we are, what we have, and 
where various parties might want to eventually get to might be really 
helpful for me.
--------------------------
Ubiquity Software does not control or endorse the content, messages or
information found in this mail list and it specifically disclaims any
liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any
communications in violation of the Terms and Conditions of Use for this
website or as otherwise deemed improper.

Information contained in this e-mail and any attachments are intended for the
use of the addressee only, and may contain confidential information of Ubiquity
Software Corporation.  All unauthorized use, disclosure or distribution is
strictly prohibited.  If you are not the addressee, please notify the
sender immediately and destroy all copies of this email.  Unless otherwise
expressly agreed in writing signed by an officer of Ubiquity Software
Corporation, nothing in this communication shall be deemed to be legally
binding.  Thank you.

--------------------------
Ubiquity Software does not control or endorse the content, messages or
information found in this mail list and it specifically disclaims any liability
with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications
in violation of the Terms and Conditions of Use for this website or as
otherwise deemed improper.

XCON                                                             R. Even
Internet-Draft                                                   Polycom
Expires: July 28, 2005                                  January 27, 2005

            Requirements for a media server control protocol
                   draft-even-media-server-req-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 July 28, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document addresses the communication between an application
   server and media server.  The current work in SIPPING and XCON
   working groups show these logical functions but do not address the
   physical decomposition and the protocol between the entities.

   The document presents the architecture and the requirements from the
   protocol.  The document lists current work that is relevant to the
   problem.

Even                     Expires July 28, 2005                  [Page 1]

Internet-Draft                Media Server                  January 2005

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Architecture . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.   Requirements . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.   Current protocols  . . . . . . . . . . . . . . . . . . . . .  10
   6.   IANA consideration . . . . . . . . . . . . . . . . . . . . .  12
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  13
   8.   Informative References . . . . . . . . . . . . . . . . . . .  13
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  13
        Intellectual Property and Copyright Statements . . . . . . .  14

Even                     Expires July 28, 2005                  [Page 2]

Internet-Draft                Media Server                  January 2005

1.  Introduction

   The IETF SIPPING conferencing framework[CARCH] 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 conference/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
   conferencing service including announcements and IVR functionality.

Even                     Expires July 28, 2005                  [Page 3]

Internet-Draft                Media Server                  January 2005

2.  Terminology

   The Media Server work uses, when appropriate, and expands on the
   terminology introduced in the SIPPING conferencing framework[CARCH].
   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.[CARCH]

   Media Server (MS) - The media server includes the mixer as defined in
   draft-ietf-sipping-conferencing-framework[CARCH] 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.

Even                     Expires July 28, 2005                  [Page 4]

Internet-Draft                Media Server                  January 2005

3.  Architecture

   The proposed architecture is composed of an application server (AS)
   and a media server (MS).

   This section does not define any specific model for the interaction
   between the AS and MS.  It does assume that every interaction from
   the participant to the MS will be controlled by the AS.  The MS only
   handles data and may tunnel controls received in the media streams to
   the AS (e.g.  DTMF).

   The assumption is that the external protocols to these entities will
   be based on the IETF work.  The Conference aware participants will
   use XCON protocols to the AS.  The signaling protocol between the
   Participants and the AS will be SIP.  The media between the
   Participants and the MS will be RTP based.  The solution may work for
   other signaling protocols like H.323.

   The MS functionality includes:

   -   Control of the RTP streams.

   -   Mixing of incoming media streams.

   -   Media stream source (for multimedia announcements).

   -   Media stream processing (e.g.  transcoding, DTMF detection).

   -   Media stream sink ( Support announcing participants names)

   The AS functionality includes:

   -   Creation and management of conferences by conference aware
   participants.

   -   Creation of conference service logic using other mechanism which
   may be standard or non-standard.  Example is to create an IVR based
   conference service.

   -   Manage the conference flow in the MS from start to finish.

   The following diagram describes the architecture.  The purpose of the
   work is to address the AS-MS protocol.

Even                     Expires July 28, 2005                  [Page 5]

Internet-Draft                Media Server                  January 2005

                                                _____________
                      XCON Protocol            | Application |
                   +---------------------------| Server      |
                   |                           |_____________|
                   |                             |    |
                   |                             |    |
                   |                             |    |
        _____________           _______     SIP  |    |
       |             |  SIP    |       |---------+    |AS-MS
       | Participant |---------| SIP   |              |Protocol
       |_____________|         | Proxy |              |
                               |_______|----------+   |
                                            SIP   |   |
                                                  |   |
                                                   ________
                                                  |        |
                                                  | Media  |
                                                  | Server |
                                                  |________|

Even                     Expires July 28, 2005                  [Page 6]

Internet-Draft                Media Server                  January 2005

4.  Requirements

   This section addresses only the requirements.  The requirements will
   be divided to general protocol requirements and to specific service
   logic requirements.

   General protocol

   1.  The Media server control messages shall be sent over a reliable
   connection.

   2.  The protocol shall enable one AS to work with multiple MS.

   3.  The protocol should enable many AS to work with the same MS

   4.  The AS should be able to find the MS and connect to it.

   5.  The MS shall be able to inform the AS about it status.

   6.  The protocol should be extendable.

   7.  The MS shall be able to tell the AS its capacities.

   8.  The MS shall be able to tell the AS its functionality (Mixing,
   IVR, Announcements)

   9.  The AS shall be able to request the MS to create, delete, and
   manipulate a mixing, IVR or announcement session

   10.  The MS shall supply the media addresses (RTP transport address)
   to be used to the AS.

   11.  The MS should send a summary report when the session is
   terminated by the AS.

   12.  The AS should be able to request call/session and conference
   state from the MS.

   13.  The MS should support DTMF detection (in band tones and RFC2833)

   14.  The protocol shall include redundancy procedures.

   15.  The protocol shall include security mechanisms.

   16.  The AS should be able to reserve resources on the MS.  The
   resources models should be simple.  (this requirement needs more
   discussion)

Even                     Expires July 28, 2005                  [Page 7]

Internet-Draft                Media Server                  January 2005

   17.  The MS may support resource reservation and shall report the
   support in the initial connection to the AS.

   18.  The MS shall inform the AS about any changes in it capacities.
   The changes may be due to reservation, internal usage or due to some
   malfunction.

   19.  The AS shall be able to tell the MS which stream parameters to
   use on incoming and out going streams.  Stream parameters may be for
   example codec parameters (video codec features) or bit rates.  This
   requirement will help the MS to allocate the right resources.

   20.  The AS shall be able to define operations that the MS will
   perform on streams like mute and gain control.

   21.  The MS shall supply the AS with sufficient information for the
   event package.

   Announcements

   Announcements may include voice, audio, slides or video clips.

   1.  The AS shall be able to instruct the MS to play a specific
   announcement.

   2.  The MS shall be able to retrieve announcements from an external
   connection.

   3.  The AS shall be able to tell the MS if the message can be delayed
   if the MS cannot play it immediately.

   4.  The AS shall be able to instruct the MS to play announcements to
   a single user or to a conference mix.

   Media mixing

   1.  The AS shall be able to define a conference mix.

   2.  The AS may be able to define a separate mix for each participant.

   3.  The AS  shall be able to define the relationship between two
   mixes, for example a pair of audio and video for lip-synch or for
   voice activated video switch

   4.  The AS may be able to define a custom video layout built of
   rectangular sub windows.

   5.  For video the AS shall be able to map a stream to a specific

Even                     Expires July 28, 2005                  [Page 8]

Internet-Draft                Media Server                  January 2005

   sub-window or to define to the MS how to decide which stream will go
   to each sub window.  The number of sub-windows will start from one.

   6.  The MS shall be able to inform the AS who is the active speaker.

   7.  The AS may be able to cascade mixers ( side bar with whisper
   mode)

   8.  The MS shall be able to inform the AS which layouts it supports.

   IVR

   1.  The AS shall be able to load an IVR script to the MS and receive
   the result

   2.  The AS shall be able to mange the IVR session by sending
   announcements and receiving the response (DTMF)

   3.  The AS should be able to instruct the MS to record a short
   participant stream and play it back to the conference.  This is not a
   recording requirement.

Even                     Expires July 28, 2005                  [Page 9]

Internet-Draft                Media Server                  January 2005

5.  Current protocols

   Currently there are a few protocols that try to address this
   architecture.  The IETF drafts and ITU standards include:

   1.  draft-vandyke-mscml-05 [MSCML]

   2.  draft-melanchuk-sipping-msml-03[MSML]

   3.  draft-melanchuk-sipping-moml-03[MOML]

   4.  draft-burger-sipping-netann-10[NETANN]

   5.  draft-levin-xcon-cccp-00[CCCP]

   6.  ITU H.248.19 - Decomposed multipoint control unit, audio, video
   and data conferencing packages[ITU.H248.19]

   Note: The list is to the best of my knowledge and the order is
   meaningless

   A short overview of the drafts based on my poor understanding is
   given here please feel free to correct my mistakes.

   MSML[MSML]

   Convedia MSML (Media Sessions Mark-up Language)[MSML].  The latest
   version added support for video.  MSML addresses the relationships of
   media streams MSML defines an XML schema that enables the AS to
   create sessions on the MS.  The draft outlines how to use SIP as a
   transport for the XML schema by using SIP invite to create a control
   session between the AS and the MS.  Subsequent control messages
   between the MS and AS will be done using INFO or INVITE.  The control
   connection is only used for the transporting the XML schema.

   MSML supports several models for client interaction.  When clients
   use 3PCC to establish media sessions on behalf of end users, clients
   will have a SIP dialog for each media session.  MSML may be sent on
   these dialogs.  However the targets of MSML actions are not inferred
   from the session associated with the SIP dialog.  The targets of MSML
   actions are always explicitly specified using identifiers previously
   defined.

   The signaling from the SIP users is going to the AS.  The AS is using
   3pcc (third party call control) procedures to direct the SIP
   signaling messages to the MS.  The SDP is used to open the media
   channel between the user and the MS while the call control is handled
   by the AS.  This is how the users join a media session on the MS that

Even                     Expires July 28, 2005                 [Page 10]

Internet-Draft                Media Server                  January 2005

   was established using the MSML schema.  Convedia has a second
   protocol called Media Objects Mark-up Language (MOML)[MOML] that can
   be used to specify individual user dialog or media control commands.

   MSCML[MSCML]

   Brooktrout Technology has suggested MSCML, Media Server Control
   Mark-up Language.  This current version supports only audio.

   The general functionality is similar to MSML.  MSCML is using SIP
   Invite and Info to send the communication between the AS and MS.
   Like MSML it opens a control connection for the conference.  The
   difference is that MSCML messages sent in the control connection are
   for the entire conference while if they are sent over the users
   dialogs they apply to that user.

   Netann[NETANN]

   This protocol provides a simple way to initiate an announcement, IVR
   or mixing session on the media server using the URI parameters.  The
   AS can create the session bur has less control on what is happening
   during the session itself.

   Centralized Conference Control Protocol (CCCP)[CCCP]

   This document may be of interest since it suggests a transaction
   protocol that can serve the AS to MS communication.  The data schema
   is based on the conference event package.

   MEGACO / H.248[ITU.H248.19]

   The H.248[ITU.H248.19] protocol opens a channel between a controller
   and a device (these can be AS and MS in our implementations).  In
   this channel it sends command to the MS to create context and to open
   connections (terminations) for the media channel.  The specific
   functionality is defined by packages that can be extended.  The MS
   connects to it AS when it starts up and notify the AS which packages
   it supports and its capacities.  The H.248 packages include also
   support for announcement and IVR.

Even                     Expires July 28, 2005                 [Page 11]

Internet-Draft                Media Server                  January 2005

6.  IANA consideration

   None.

Even                     Expires July 28, 2005                 [Page 12]

Internet-Draft                Media Server                  January 2005

7.  Security Considerations

   The security section will be added later

8  Informative References

   [CARCH]    Rosenberg, J., "A Framework for Conferencing with the
              Session Initiation Protocol",
              draft-ietf-sipping-conferencing-framework-03 (work in
              progress), October 2004.

   [CCCP]     Levin, O. and G. Kimchi, "Centralized Conference Control
              Protocol (CCCP)", draft-levin-xcon-cccp-00 (work in
              progress), October 2004.

   [ITU.H248.19]
              International Telecommunications Union, "Gateway control
              protocol: Decomposed multipoint control unit, audio, video
              and data conferencing packages", ITU-T Recommendation
              H.248.19, March 2004.

   [MOML]     Sharratt, G. and T. Melanchuk, Ed., "Media Objects Markup
              Language (MOML)", draft-melanchuk-sipping-moml-03 (work in
              progress), August 2004.

   [MSCML]    Van Dyke, J. and Eric. Burger, Ed., "Media Server Control
              Markup Language (MSCML) and Protocol",
              draft-vandyke-mscml-05 (work in progress), October 2004.

   [MSML]     Sharratt, G. and T. Melanchuk, Ed., "Media Server Markup
              Language (MSML)", draft-melanchuk-sipping-msml-03 (work in
              progress), August 2004.

   [NETANN]   Van Dyke, J. and Eric. Burger, Ed., "Basic Network Media
              Services with SIP", draft-burger-sipping-netann-10 (work
              in progress), October 2004.

Author's Address

   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva  49130
   Israel

   EMail: [email-masked]

Even                     Expires July 28, 2005                 [Page 13]

Internet-Draft                Media Server                  January 2005

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 (2005).  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.

Even                     Expires July 28, 2005                 [Page 14]

---

From: "Dave Burke" <[email-masked]>
Date: Sun, 21 May 2006 15:10:19 +0100

I just want to echo my support for the approach of defining a 
new protocol in line with firm requirements (although note we also have 
draft-dolly-xcon-mediacntrlframe so some clarification of which is authoriative 
would be useful). I too agree that there is good support for the 
draft-boulton-sip-control-framework approach for a dedicated control channel. 

As for the protocol's message formats and exchange 
patterns, I find the choose one of MSML vs 
MSCML debate as not terribly constructive if the presumed goal of creating an 
industry standard, vendor independent, protocol is to be attained. 
Rather, I'd like to see the group cherry pick (at a granular level) the best 
approaches from the pre-existing solutions.
 
I think some formalism associated with a WG will 
ultimately help this group.
 
Dave
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  ----- Original Message ----- 
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From: 
  Even, 
  Roni 
  To: <A rel="nofollow" title=[email-masked] 
  href="mailto:[email-masked]">Chris Boulton ; <A rel="nofollow" 
  title=[email-masked] href="mailto:[email-masked]">Adnan Saleem 
  ; Cullen Jennings 
  ; <A rel="nofollow" title=[email-masked] 
  href="mailto:[email-masked]">[email-masked] 
  
  Cc: <A rel="nofollow" title=[email-masked] 
  href="mailto:[email-masked]">Burger, Eric 
  Sent: Sunday, May 21, 2006 1:49 PM
  Subject: RE: [mediactrl] How to get this 
  work into a WG

  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">During the last 
  meeting I mentioned the requirement document I wrote when we started the work. 
  It is attached here; I thought it will be added to the list of document in 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><A rel="nofollow" 
  href="http://flyingfox.cantata.com/i-d/mediactrl/">http://flyingfox.cantata.com/i-d/mediactrl/ 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">BTW: I agree with 
  Chris answers about the work and want to mention that MSML and MSCML are not 
  the only proprietary protocols that support this interface. Polycom has its 
  XML API that supports this functionality and MS has proposed CCCP for the 
  protocol.
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think that the 
  consensus was to define a protocol that will be inline with the requirements 
  and the framework and not to point at some vendors 
  implementations.
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Of course we can 
  leverage the knowledge that was learnt by the manufacturers to create a good 
  solution as fast as we can.
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regards
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Roni 
  Even
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  
  <FONT 
  face="Times New Roman" size=3>

  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:<FONT 
  face=Tahoma size=2> 
  [email-masked] 
  [mailto:[email-masked]] <SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of Chris Boulton<SPAN 
  style="FONT-WEIGHT: bold">Sent: Tuesday, May 09, 2006 3:40 
  PMTo: Adnan Saleem; Cullen 
  Jennings; [email-masked]<SPAN 
  style="FONT-WEIGHT: bold">Cc: Burger, Eric<SPAN 
  style="FONT-WEIGHT: bold">Subject: RE: [mediactrl] How to get this 
  work into a WG
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 10pt">Cullen,I want to point out that we have rough 
  consensus (imho) on the "control framework" ID (<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt), 
  from an architectural perspective and the direction this is 
  going.
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">[Chris 
  Boulton] That?s really good to hear.
  
  <FONT face="Times New Roman" 
  size=2>However, there is no consensus on the 
  remaining IDs identified below.
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">[Chris 
  Boulton] I?m not sure consensus was at all proposed ? certainly not by 
  me.  That?s jumping the gun a little.  I was just pointing out that 
  we have current examples of how Control Packages are written in-line with the 
  framework.
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
  
  <FONT face="Times New Roman" 
  size=2>Convedia in particular objects to the 
  "extension" IDs listed below, covering IVR and conference 
  control.
  
  <FONT face="Times New Roman" 
  size=3> 
  
  <FONT face="Times New Roman" 
  size=2>      - (<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0" 
  target=_blank><A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt">http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).
  
  <FONT face="Times New Roman" 
  size=2>      - (<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack" 
  target=_blank><A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt">http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).
  
  <FONT face="Times New Roman" 
  size=2>      - (<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa" 
  target=_blank><A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt">http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).
  
  <FONT face="Times New Roman" 
  size=3> 
  
  <FONT face="Times New Roman" 
  size=2>The above <FONT 
  face="Times New Roman">new IDs essentially provide a 
  subset and duplication of the what MSML, and MSCML to a good extent, have 
  already provided for years.
  
  <FONT face="Times New Roman" 
  color=navy size=3><SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy"> 
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">[Chris 
  Boulton] Totally understand your position.  All I will say is 
  that:-
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial"> 
  <FONT 
  face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">-<FONT 
  color=navy size=1><SPAN 
  style="FONT-SIZE: 7pt; COLOR: navy">          
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">yes, 
  you are correct in that this does provide duplication of MSML and MSCML.  
  The intention was to use and build on the experiences gained from such 
  languages to provide a solution that architecturally fits with the new Control 
  Framework.
  <FONT 
  face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">-<FONT 
  color=navy size=1><SPAN 
  style="FONT-SIZE: 7pt; COLOR: navy">          
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">Yes 
  it provides subsets of functionality.  This again was the intention to 
  provide a modular approach.  We are thinking (and received quite a large 
  amount of feedback from media control group) from the agnostic point of view 
  that not everyone wants to implement a large scripting language for simple IVR 
  interactions.  It should be possible to select exactly what you need to 
  fit your requirements.
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">If 
  you have got any more detail on your technical objections I think it would be 
  great to have some discussion.
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">Best 
  Regards,
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">Chris.
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial"> 
  <FONT face="Times New Roman" 
  size=3> 
  
  <FONT face="Times New Roman" 
  size=3> 
  
  <st1:place 
  w:st="on"><SPAN 
  style="FONT-SIZE: 10pt">Garland<FONT 
  size=2> / 
  Adnan
  <SPAN 
  style="FONT-SIZE: 10pt">-----Original Message-----From: 
  [email-masked][<A rel="nofollow" 
  href="mailto:[email-masked]">mailto:[email-masked]]On 
  Behalf Of ChrisBoultonSent: May 8, 2006 2:36 AMTo: Cullen 
  Jennings; MixerControlCc: Burger, EricSubject: RE: [mediactrl] How to 
  get this work into a WGHi Cullen (donning AD cap),We are 
  still very much actively discussing this work and have met atevery IETF 
  since Paris (I 
  think) - including a Beer BOF and a Meal 
  BOF:-).        A long time ago, 
  we had talked about asking the SpeachSC 
  chairsif         that WG might 
  take on this work. Is there still interest 
  inthat?        Very much 
  so - we have been discussing this regularly and I think we hadhoped (Eric 
  will confirm but I know he is snowed under at the moment) tomove towards 
  IETF working group towards the end of this year/maybe 
  earlynext.        PS - A short 
  summary of the status of where we are, what wehave, 
  and         where various parties 
  might want to eventually get to might 
  bereally         helpful for 
  me.We are at the point where we have a Control Framework which has 
  beendiscussed at length at previous meetings(<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt) 
  which aims to fulfill the detail outlined in the 
  Requirementsdocument(<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01.txt).  
  This is an agnostic approach that is not 'Media Server' specificand aims 
  to provide a core connection management system using SIP.The authors 
  of the Framework have also created a number of extensions tothe Control 
  Framework that provides modules for achieving various levelsof Media 
  Server Control.- First extension provides simple IVR 
  functionality(<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).- 
  There is an extension to the SIMPLE IVR functionality for the purposeof 
  using VXML(<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).- 
  This extensions provides conferencing capabilities(<A rel="nofollow" 
  href="http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).If 
  you need anymore information then give me a shout.Best 
  Regards,Chris.-----Original Message-----From: 
  [email-masked][<A rel="nofollow" 
  href="mailto:[email-masked]">mailto:[email-masked]] 
  On Behalf Of Cullen<st1:place 
  w:st="on">JenningsSent: 07 May 2006 16:11To: 
  MixerControlSubject: [mediactrl] How to get this work into a WGA 
  long time ago, we had talked about asking the SpeachSC chairs if that 
  WG might take on this work. Is there still interest in that? With my 
  AD hat on, I have no idea what is the best way to do this yet but I 
  am looking for input on what the next logical steps are with all the 
  work that has been happing here.Thanks, CullenPS - A short 
  summary of the status of where we are, what we have, and where 
  various parties might want to eventually get to might be 
  really helpful for me.--------------------------Ubiquity 
  Software does not control or endorse the content, messages orinformation 
  found in this mail list and it specifically disclaims anyliability with 
  regard to these communications.Ubiquity Software reserves the right the 
  restrict access to anycommunications in violation of the Terms and 
  Conditions of Use for thiswebsite or as otherwise deemed 
  improper.Information contained in this e-mail and any attachments 
  are intended for the use of the addressee only, and may contain confidential 
  information of Ubiquity Software Corporation.  All unauthorized use, 
  disclosure or distribution is strictly prohibited.  If you are not the 
  addressee, please notify the sender immediately and destroy all copies of this 
  email.  Unless otherwise expressly agreed in writing signed by an officer 
  of Ubiquity Software Corporation, nothing in this communication shall be 
  deemed to be legally binding.  Thank 
  you.--------------------------Ubiquity Software does not 
  control or endorse the content, messages or information found in this mail 
  list and it specifically disclaims any liability with regard to these 
  communications.Ubiquity Software reserves the right the restrict access to 
  any communications in violation of the Terms and Conditions of Use for this 
  website or as otherwise deemed 
  improper.

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Sun, 21 May 2006 16:30:58 +0100

<SPAN 
class=140053015-21052006>Roni,
<SPAN 
class=140053015-21052006> 
<SPAN 
class=140053015-21052006>Requirements in this document are included in the 
current framework document. As discuss, many times, if you feel that some of the 
requirements in your document are not covered, then please highlight those and 
they will be added.
<SPAN 
class=140053015-21052006> 
<SPAN 
class=140053015-21052006>Cheers,
<SPAN 
class=140053015-21052006> 
<SPAN 
class=140053015-21052006>Martin

From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Even, 
RoniSent: Sunday, May 21, 2006 8:49 AMTo: Chris Boulton; 
Adnan Saleem; Cullen Jennings; 
[email-masked]: Burger, 
EricSubject: RE: [mediactrl] How to get this work into a 
WG

<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">During the last meeting 
I mentioned the requirement document I wrote when we started the work. It is 
attached here; I thought it will be added to the list of document in 

<SPAN 

<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">BTW: I agree with Chris 
answers about the work and want to mention that MSML and MSCML are not the only 
proprietary protocols that support this interface. Polycom has its XML API that 
supports this functionality and MS has proposed CCCP for the 
protocol.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think that the 
consensus was to define a protocol that will be inline with the requirements and 
the framework and not to point at some vendors 
implementations.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Of course we can 
leverage the knowledge that was learnt by the manufacturers to create a good 
solution as fast as we can.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regards
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Roni 
Even
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">

<FONT 

<SPAN 

<FONT face="Times New Roman" 
size=2>However, there is no consensus on the 
remaining IDs identified below.
<SPAN 
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: italic; FONT-FAMILY: Arial">[Chris 
Boulton] I’m not sure consensus was at all proposed – certainly not by me.  
That’s jumping the gun a little.  I was just pointing out that we have 
current examples of how Control Packages are written in-line with the 
framework.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 

The intention was to use and build on the experiences gained from such languages 
to provide a solution that architecturally fits with the new Control 
interactions.  It should be possible to select exactly what you need to fit 
your requirements.

<st1:place 
w:st="on"><SPAN 
style="FONT-SIZE: 10pt">Garland<FONT 
size=2> / Adnan
<SPAN 
style="FONT-SIZE: 10pt">-----Original Message-----From: 
[email-masked][<A rel="nofollow" 
href="mailto:[email-masked]">mailto:[email-masked]]On 
Behalf Of ChrisBoultonSent: May 8, 2006 2:36 AMTo: Cullen Jennings; 
MixerControlCc: Burger, EricSubject: RE: [mediactrl] How to get this 
work into a WGHi Cullen (donning AD cap),We are still very 
much actively discussing this work and have met atevery IETF since <st1:City 
w:st="on">Paris (I think) - 
including a Beer BOF and a Meal 
BOF:-).        A long time ago, 
we had talked about asking the SpeachSC 
chairsif         that WG might 
take on this work. Is there still interest 
inthat?        Very much so 
- we have been discussing this regularly and I think we hadhoped (Eric will 
confirm but I know he is snowed under at the moment) tomove towards IETF 
working group towards the end of this year/maybe 
earlynext.        PS - A short 
summary of the status of where we are, what wehave, 
and         where various parties 
might want to eventually get to might 
bereally         helpful for 
me.We are at the point where we have a Control Framework which has 
beendiscussed at length at previous meetings(<A rel="nofollow" 
href="http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework" 
target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-02.txt) 
which aims to fulfill the detail outlined in the Requirementsdocument(<A rel="nofollow" 
href="http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01" 
target=_blank>http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-01.txt).  
This is an agnostic approach that is not 'Media Server' specificand aims to 
provide a core connection management system using SIP.The authors of the 
Framework have also created a number of extensions tothe Control Framework 
that provides modules for achieving various levelsof Media Server 
Control.- First extension provides simple IVR functionality(<A rel="nofollow" 
href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-0" 
target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-01.txt).- 
There is an extension to the SIMPLE IVR functionality for the purposeof 
using VXML(<A rel="nofollow" 
href="http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-pack" 
target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-ivr-vxml-control-package-00.txt).- 
This extensions provides conferencing capabilities(<A rel="nofollow" 
href="http://www.ietf.org/internet-drafts/draft-boulton-conference-control-pa" 
target=_blank>http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-00.txt).If 
you need anymore information then give me a shout.Best 
Regards,Chris.-----Original Message-----From: 
[email-masked][<A rel="nofollow" 
href="mailto:[email-masked]">mailto:[email-masked]] 
On Behalf Of Cullen<st1:place 
w:st="on">JenningsSent: 07 May 2006 16:11To: 
MixerControlSubject: [mediactrl] How to get this work into a WGA 
long time ago, we had talked about asking the SpeachSC chairs if that 
WG might take on this work. Is there still interest in that? With my AD 
hat on, I have no idea what is the best way to do this yet but I am 
looking for input on what the next logical steps are with all the work 
that has been happing here.Thanks, CullenPS - A short summary of 
the status of where we are, what we have, and where various parties 
might want to eventually get to might be really helpful for 
me.--------------------------Ubiquity Software does not control or 
endorse the content, messages orinformation found in this mail list and it 
specifically disclaims anyliability with regard to these 
communications.Ubiquity Software reserves the right the restrict access to 
anycommunications in violation of the Terms and Conditions of Use for 
thiswebsite or as otherwise deemed improper.Information 
contained in this e-mail and any attachments are intended for the use of the 
addressee only, and may contain confidential information of Ubiquity Software 
Corporation.  All unauthorized use, disclosure or distribution is strictly 
prohibited.  If you are not the addressee, please notify the sender 
immediately and destroy all copies of this email.  Unless otherwise 
expressly agreed in writing signed by an officer of Ubiquity Software 
Corporation, nothing in this communication shall be deemed to be legally 
binding.  Thank you.--------------------------Ubiquity 
Software does not control or endorse the content, messages or information found 
in this mail list and it specifically disclaims any liability with regard to 
these communications.Ubiquity Software reserves the right the restrict 
access to any communications in violation of the Terms and Conditions of Use for 
this website or as otherwise deemed 
improper.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 05:31:23 +0100

On May 21, 2006, at 7:12 AM, Dave Burke wrote:I find the choose one of MSML vs MSCML debate as not terribly constructive if the presumed goal of creating an industry standard, vendor independent, protocol is to be attained. Telling a working group that they have to choose A or B and are not allowed to make what the WG thinks is best is almost always doomed for failure. The goal would be to great a good protocol that had consensus - clearly it would leverage much that has been done but I would not be telling the group to pick A or B. Cullen