Subject: Which Came First? (was RE: [mediactrl] SIP Control Framework and IVR Package)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 14 Feb 2006 18:23:29 GMT

I would offer that CCXML was influenced more by MSCML and MSML than the other way around.  MSCML predates CCXML by two years, and MSML-00 was about 6 months after the first CCXML draft.  Both were shown to the VBWG CCSG and discussed there.

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shtirmer, Gene
Sent: Saturday, February 04, 2006 10:49 PM
To: McGlashan, Scott; Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package

Scott, thanks!!!  We are quickly getting to the core of the issues.  I've addressed your questions/comments inline...
 
Best Regards,
Gene
________________________________________
From: McGlashan, Scott [mailto:[email-masked]] 
Sent: Saturday, February 04, 2006 6:12 PM
To: Shtirmer, Gene; Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package
Hi Gene,
 
Thanks for your detailed response - apologies if I mis-understood your position.
 
I definitely agree that the VoiceXML and CCXML components can be separated from low-level media operations and that we want to focus on the Mr interface, not the Mp interface (H.248 and its packages). 
 
[Gene Shtirmer] I would characterize my intent a bit differently, namely, wanting to focus on the Mr interface, rather than interfaces that may exist between various application servers - for example, VoiceXML/CCXML over HTTP interface between a Web Application Server and a SIP application server.  I have not touched on, or acknowledged the Mp interface in my previous e-mail.   I will address Mp and H.248 further down in this e-mail.
 
The Mr interface should be based on an XML language which expresses the necessary media and conference operations, and we may want to take the best from the M* proposals. 
 
What I don't yet understand is how you can reconcile the location of the VoiceXML interpreter in the application layer and the M* proposals which consistently allow VoiceXML scripts to be passed through the Mr interface.  For example, 
 
MSCP: <dialogstart type="application/vxml+xml" src="http://server.example.com/scripts/foo.vxml"/>
MSML: <dialogstart type="application/vxml+xml" src="http://server.example.com/scripts/foo.vxml"/>
 
If the VoiceXML scripts references are passed through the Mr interface, then surely the VoiceXML interpreter is in the media server layer (e.g. MRFC) not the application layer. That seems to be the consensus of the M* proposals, including MSML. It has the benefit that VoiceXML is already a standard: i.e. we build the Mr interface from existing standards when they are fit for purpose, extensively deployed and interoperable.    
 
[Gene Shtirmer] As I mentioned in my previous e-mail, I don't believe that the precedent of VoiceXML coexisting or forming the basis of various M* protocols should necessarily influence the choice of an Mr protocol as we move forward.  The reason we have this soup of protocols today, which mixes in VoiceXML into M* protocols, has less to do with merit, but is rather largely rooted in historic and legacy considerations, and the evolutionary nature of these protocols' and products' that implement them coming into being.  We now have the opportunity to hash out what makes sense and what doesn't - to take a critical look at what are the logical and sensible separations/boundaries between various functional blocks and protocols by which they interconnect to each other.  
 
I have nothing against VoiceXML or CCXML, I just don't believe they belong at the Mr interface.  These standards should continue to be heavily used and relied upon in the services plane.
 
The alternative, as you say, is that we use a protocol/syntax that was designed from the ground up with granular control of media resources/objects as its sole intended purpose. However, isn't that the province of the Mp interface - i.e. a low level protocol to media functionality - where there is already an established protocol, H.248?  Of course we could use H.248 packages in XML format. Or we could use/develop another XML language (you suggest MOML) which isn't as high level as VoiceXML nor as low-level as H.248, but something in between.  I don't yet see the advantage of trying to standardizing that approach for the Mr interface if there are existing high-level (VoiceXML) or low-level (H.248) standards which are fit for purpose.   
 
[Gene Shtirmer] Firstly, I don't believe H.248 is truly built for purpose, except for its granularity, when it comes to controlling rich media resources (it is built for purpose wrt media gateways, but not media servers).  Secondly, I am questioning the entire premise of MRF decomposition.  MRF in my view is the MRFP.  The Mp interface along with MRFC are superfluous (except for maybe a media resource broker function, but that could live on the app server end of the Mr interface).  As such, I am envisioning the Mr media server control protocol being closer to H.248 wrt granularity, but also being SIP and XML based, and tailored to rich media control.  Hence my strong preference for the MxML type syntax on top of SIP Framework for Control.
 
I also favor a notion offered recently by Convedia, suggesting that Mr interface be based on simple SIP (no REFER, although you still may need P-Headers, since you could have the MRF in the core network, and the Application Server inside an enterprise), media server be used by application server(s) only, and the media server be a slave of application server(s), meaning INVITEs to the media server would come only from the application server.  My hope is that we can eventually come to an agreement on these type of IMS spec shortcomings and inconsistencies and their remedies, and bring them to the attention of and action by the appropriate 3GPP standardization bodies.
 
thanks
 
Scott

________________________________________
From: Shtirmer, Gene [mailto:[email-masked]] 
Sent: Saturday, February 04, 2006 19:39
To: McGlashan, Scott; Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package
Scott, thanks for your detailed comments.  Firstly, I think a clarification is in order.  I am not arguing for eliminating VoiceXML and CCXML from the application.  My argument is that these interpretive languages belong entirely in the Application Services space (IMS Services plane), and should not be used to control a media server.  
 
So, the model I am using is as follows (please also see the simplified diagram below):
 
A SIP application server receives an INVITE from the far end (through CSCF); fetches CCXML and/or VoiceXML scripts over HTTP from a Web Application Server - CSCF could even use NETANN in the INVITE to specify a CCXML or VoiceXML starting page(s), based on HSS look-up for example.  As CCXML/VoiceXML scripts are being interpreted on the app server, a need arises for various media resources, whether it's conferencing, video, fax, voice, etc.  The app server will exercise a media resource broker function of sorts at this point: it will identify the needed and available resources, and will establish media control session(s) to the media server(s) hosting these needed resources.  The syntax of controlling these media resources is in my view what we are discussing here, and would be an MSML/MOML type syntax.
 
To summarize, I am proposing that we not "adapt" VoiceXML and CCXML to "wireline" protocols, but let them remain intact in the Web/HTTP model as originally intended by W3C, and be used between various app servers in the IMS Services plane.  That's what these scripting/rendering languages were designed and optimized for.  Instead of adapting, I am suggesting we use a protocol/syntax that was designed from the ground up with granular control of media resources/objects as its sole intended purpose.
 
You cite a number of different M* protocols as establishing a precedent in allowing for VoiceXML to coexist with or form the basis of their syntax.  My understanding of this group's objective is that it's to reconcile the multitude of differing approaches to the same problem, and come up with a commonly agreed upon framework/syntax that makes sense.  I am completely open to taking the best elements of the M* protocols you cite, such as MScML and MSCP (at least its media sessions syntax, not the dialog syntax) and MSML/MOML.  I just don't think we should inject VoiceXML/CCXML in that control path.  
 
Finally, if I am to roughly map the model I just described to your OCMP software architecture, I would say that the OCMP Base is the Media Server (MRF), while the OCMP BRE and everything above it is Application Services.  OCMP BRE continues to use VoiceXML and CCXML over http facing northward, while it uses a media control protocol facing southward.  In my view, the protocol/syntax we are discussing is roughly between your OCMP Base and OCMP BRE, not between OCMP BRE and "Applications".  
 
Please see a few additional comments inline.
 
Regards,
Gene.

________________________________________
From: McGlashan, Scott [mailto:[email-masked]] 
Sent: Saturday, February 04, 2006 11:31 AM
To: Shtirmer, Gene; Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package
Hi Gene,
 
thanks for your comments. 
 
[1] On the use of CCXML, none of the current draft specifications use it directly but both MSCP and MSML are, to varying degrees, modeled on CCXML's method of invoking dialogs (dialogstart, etc) and share its general conferencing methods (createconference, join,etc). These approaches can be seen as adapting CCXML for use as a  'wire protocol', but they do not use it directly.   
 
[Gene Shtirmer]  I will defer to authors of the MSML syntax to comment on this point. 
 
[2] The use of VoiceXML for interactive IVR dialogs is recognized by MSCP, MSML, MSCML and netann (MSCP and MSML use the dialogstart concept to invoke dialogs where the script language can be any dialog language): 
 
MSCP: "IVR dialogs can be specified in VoiceXML."
 
MSCML: "for complex IVR it may be more appropriate to employ a full IVR markup language such as VoiceXML"
 
MSML: "Dialogs may be specified in different languages depending on application requirements.  VoiceXML allows complete single-party application interfaces to be executed by a media server." 
 
netann: "dialog service takes a parameter, voicexml=, indicating the URI of the VoiceXML script to
   execute."
One of the key reasons for the use of VoiceXML is that it is an internationally recognized and widely implemented standard for interactive media dialogs from W3C (Jim Larson, Intel, is my co-chair in the working group). If Media Servers are to be interoperable then there must at least one dialog language which is mandatory. This is the motivation for the IVR package requiring that VoiceXML is mandatory. 
 
In terms of functionality, basic IVR functionality - playannouncement, promptandcollect as well as promptandrecord - can be expressed in VoiceXML. It also has the benefit that more complex IVR interaction can be scripted using the same dialog language. There may be issues whether VoiceXML is efficient for simple IVR interactions, but this is largely an internal media server issue. Having said that, we are still looking at whether we should also have a simpler 'builtin' IVR dialog approach where the name of the builtin script is referenced and can be configured using parameters: 
 
<dialogstart src="builtin:promptandcollect">
  <namelist>
   <name="iterations" value="2"/>
   <name="timeout" value="5000ms"/>
 </namelist>
</dialogstart>
 
where the parameter set is similar to those used in H.248.7 IVR packages, MSCML, MOML, etc. 
 
[3]  The functional boundary between an application server and a media server is definitely an issue on which there are a variety of opinons and strategies. A VoiceXML interpreter can be seen as part of the AS or the MS - most implementations today see them in the MS (e.g. in IMS, I've seen approaches where the interpreter is part of the MRFC, and others where it is part of the MRFP - in both cases on the MS side of the AS-MS boundary). 
 
The idea that a media server is a stateless device is not one I'm familar with; for example, the approaches mentioned above are not stateless - even a basic promptandcollect dialog is stateful (e.g. maintain iteration counter, etc). Furthermore, low-level media processors (using soft or hard DSPs) are increasing stateful (e.g. processing MPEG4 video with its I-frames and P-frames). So, completely eliminating state from a media server may be problematic. 
 
Media servers which use MSCP, MSML or MSCML languages have the concept of a call (i.e. SIP dialog). I've heard some interest in eliminating the call aspect from a media server: i.e. like H.248, there is no call (SIP) connection between the AS and MS, but only a dedicated control channel with a package which negotiates media setup and codecs between AS and MS - certainly more radical than our current proposal since it eliminates SIP as the mechanism to negotiate and manage the connection. 
 
CDRs are more of an implementation issue, but most have them (and H.248 has statistics for the session). Introducing a statistics package for media servers is something that may be worth investigating due to interest from operators who want to collect detailed information about the MS session.  
 
I agree that initiating and transfering call is currently out of scope for many media servers. However, we may need to address this functionality in the future if media server need to support SIP and TDM sessions - e.g. add a participant on a TDM connection to conference - I think that TISPAN or ATIS  is looking at such functionality? Note that transfer is not a mandatory feature of VoiceXML and call initiation is not a feature in the current standard.
 
[Gene Shtirmer] I don't envision TDM connections being in scope of a media server.  That's a media gateway function.
 
[4] The extent to which application logic and state is encoded in a VoiceXML script is up to the application developer. In the media server scenario, the VoiceXML is simply a standard way of encoding the presentation layer in an interaction: it carries out the media interaction ordered by the AS and returns its result to the AS which handles flow control and data management. However, if an application wishes to, they can delegate more complex parts of the application flow to VoiceXML. This seems to me to be an advantage of VoiceXML - with a single standard dialog language, you can run it as a media slave for simple operations, or delegate more complex operations to it. 

thanks
 
Scott

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shtirmer, Gene
Sent: Friday, February 03, 2006 23:29
To: Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package
We have reviewed both drafts.  We have no objections to the SIP Framework for establishing and conducting control sessions between the app server and the media server.
 
We are, however, not on board with using/adapting VoiceXML (in the case of IVR package) and possibly CCXML (in the case of upcoming conferencing package) as the syntax for the control messages.  VoiceXML and CCXML scripts carry in them part, if not all, of the application logic.  As such VoiceXML and CCXML interpreters belong on the application server, not a media server.  A media server, when properly separated from the application logic, is a stateless device that presents a pool of media resources to the application server(s) - it does not have a concept of a call, it can't do CDRs, transfers, initiate calls, etc.  
 
We believe a more suitable protocol for the media server control by the application server is MSML/MOML, as it provides lower level, more granular and more complete control over media resources, without requiring the state of the dialog or a conference to reside on the media server.
 
Regards,
Gene Shtirmer

________________________________________
From: Chris Boulton [mailto:[email-masked]] 
Sent: Friday, December 23, 2005 7:23 AM
To: Shtirmer, Gene
Subject: FW: [mediactrl] SIP Control Framework and IVR Package
FYI.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 23 December 2005 11:06
To: [email-masked]
Cc: McGlashan, Scott; Tim Melanchuk; Asher Shiratzky; Eric Burger; [email-masked]; Dolly, Martin C, ALABS
Subject: [mediactrl] SIP Control Framework and IVR Package
 
Hi All,
 
A small group has just submitted two new drafts and would like expert opinion/review from the 'Mediactrl' mailing list.  The following provides a brief introduction to the technology contained within the two specifications:-
 
- A Control Framework for the Session Initiation Protocol (SIP)
 
Abstract
This document describes a Framework and protocol for application deployment where the application logic and processing are distributed.  The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between Application Servers and tightly associated external Servers e.g.Media Server.
 
The motivation for the creation of this Framework is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the XCON work group of the IETF.  It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities.

- An Interactive Voice (IVR) Control Package for the Session Initiation Protocol (SIP)
 
Abstract
This document defines a Session Initiation (SIP) Control Package for Interactive Voice Response (IVR) interaction.  The control of Media Servers and their related resources in decomposed network architectures plays an important role in various Next Generation Networks.  This Control Package aims to fulfill IVR requirements using the SIP Control Framework [7].
 
Until the drafts appear in the archives, they will be available from the following links:-
 
http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.txt
http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.html
 
and
 
http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.txt
http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.html

More packages to follow in the New Year to expand and provide proof points for the Control Framework as well as strengthening the Media Server Control proposal (e.g. package for Conference support).
 
Mr Burger, the authors would be grateful if you could include these drafts on the Media Control web pages and remove Media Server Request Protocol. 

Seasons Greetings to all,
 
The Authors.

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: "McGlashan, Scott" <[email-masked]>
Date: Wed, 15 Feb 2006 09:26:07 GMT

[Apologies in advance if this is off topic for this list. Eric and I can take this up directly.] 

>From the viewpoint of W3C, I would be interesting in some data to back up your statement - do you (or anyone else on this list) know of any email trails, documents, etc which demonstrate that MSCML or MSML influenced the development of of CCXML within the W3C VBWG? - either public lists, W3C members-only or private communications would do. 

The CCXML appendix A describes related work (CPL, CallXML, CSTA, TXML and SIP) but makes no reference to MSCML or MSML. The initial CCXML proposal was distributed to W3C lists in April 2001: it contained the basics of <dialogstart>, <createconference>, <join> as well as the event-driven execution model. First public CCXML draft dates from Feb 2002. The first references to MSCML and MSML I can find were Feb 2004 (W3C member-only mail archive):

MSCML (draft 03) 
  http://lists.w3.org/Archives/Member/w3c-voice-wg/2004Feb/0033

MSML/MOML (draft 01/02)
http://lists.w3.org/Archives/Member/w3c-voice-wg/2004Feb/0062

Snippet from Feb 5 2004 telecom: 
"Discussed conferencing with Eric Burger. Eric agrees with simple basic 
Capabilities described, suggests looking at MSCML for additional attributes that might be useful."

If the 'basic capabilities' of CCXML were influenced by MSCML and/or MSML, then I would like that oversight to be corrected in the next version of the CCXML document.

thanks

Scott 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Burger, Eric
Sent: Tuesday, February 14, 2006 19:33
To: [email-masked]
Subject: Which Came First? (was RE: [mediactrl] SIP Control Framework and IVR Package)

 
Best Regards,
Gene
Subject: RE: [mediactrl] SIP Control Framework and IVR Package Hi Gene,

 

 

 

 
 
thanks
 
Scott

Subject: RE: [mediactrl] SIP Control Framework and IVR Package Scott, thanks for your detailed comments.  Firstly, I think a clarification is in order.  I am not arguing for eliminating VoiceXML and CCXML from the application.  My argument is that these interpretive languages belong entirely in the Application Services space (IMS Services plane), and should not be used to control a media server.  

 

 
 
Regards,
Gene.

Subject: RE: [mediactrl] SIP Control Framework and IVR Package Hi Gene,

 

 

 

 

 

 

thanks
 
Scott

Subject: RE: [mediactrl] SIP Control Framework and IVR Package We have reviewed both drafts.  We have no objections to the SIP Framework for establishing and conducting control sessions between the app server and the media server.

 
Regards,
Gene Shtirmer

________________________________________
From: Chris Boulton [mailto:[email-masked]]
Sent: Friday, December 23, 2005 7:23 AM
To: Shtirmer, Gene
Subject: FW: [mediactrl] SIP Control Framework and IVR Package FYI.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 23 December 2005 11:06
To: [email-masked]
Cc: McGlashan, Scott; Tim Melanchuk; Asher Shiratzky; Eric Burger; [email-masked]; Dolly, Martin C, ALABS
Subject: [mediactrl] SIP Control Framework and IVR Package
 
Hi All,

 
Abstract

 
Abstract

 
and

 

The Authors.