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

From: "Shtirmer, Gene" <[email-masked]>
Date: Fri, 3 Feb 2006 22:21:17 GMT

<FONT face=Arial 
color=#0000ff size=2>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.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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.  
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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.
<FONT face=Arial color=#0000ff 
size=2> 
<FONT face=Arial color=#0000ff 
size=2>Regards,
Gene 
Shtirmer

From: Chris Boulton 
[mailto:[email-masked]] Sent: Friday, December 23, 2005 7:23 
AMTo: Shtirmer, GeneSubject: FW: [mediactrl] SIP Control 
Framework and IVR Package

<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">FYI.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original 
Message-----From: 
[email-masked] 
[mailto:[email-masked]] <SPAN 
style="FONT-WEIGHT: bold">On Behalf Of Chris Boulton<SPAN 
style="FONT-WEIGHT: bold">Sent: <FONT face=Tahoma 
size=2>23 December 
2005<SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> <FONT face=Tahoma 
size=2><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">11:06<FONT 
face=Tahoma size=2><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><SPAN 
style="FONT-WEIGHT: bold">To: 
[email-masked]<SPAN 
style="FONT-WEIGHT: bold">Cc: McGlashan, Scott; Tim Melanchuk; Asher 
Shiratzky; Eric Burger; [email-masked]; Dolly, Martin C, ALABS<SPAN 
style="FONT-WEIGHT: bold">Subject: [mediactrl] SIP Control Framework 
and IVR Package
<SPAN 
style="FONT-SIZE: 12pt"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi All,
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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:-
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">- A <SPAN 
style="FONT-WEIGHT: bold">Control Framework for the Session Initiation Protocol 
(SIP)
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Abstract
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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.
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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.
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">- <SPAN 
style="FONT-WEIGHT: bold">An Interactive Voice (IVR) Control Package for the 
Session Initiation Protocol (SIP)
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Abstract
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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].
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Until the drafts appear in the 
archives, they will be available from the following links:-
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
href="http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.txt">http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.txt
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
href="http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.html">http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.html
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">and
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
href="http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.txt">http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.txt
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
href="http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.html">http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.html
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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).
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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. 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Seasons Greetings to 
all,
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The Authors.
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 12pt"><FONT face=Verdana size=1 
colour="#cccccc"><SPAN 
style="FONT-SIZE: 7.5pt; FONT-FAMILY: Verdana">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

---

From: "McGlashan, Scott" <[email-masked]>
Date: Sat, 4 Feb 2006 16:23:35 GMT

<FONT face=Arial 
color=#0000ff size=2>Hi Gene,
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>thanks for your comments. 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>[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.  
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>[2] The use of VoiceXML for interactive IVR dialogs is 
recognized by MSCP, MSML, MSCML and netann (<SPAN 
class=190241914-04022006>MSCP and MSML use 
the dialogstart concept to invoke dialogs where the script language can be 
any dialog language): 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>MSCP: "IVR dialogs can be specified in 
VoiceXML."
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>MSCML: "for complex IVR it may be more appropriate to 
employ a full IVR markup language such as VoiceXML"
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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." 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>netann: "dialog service takes a parameter, voicexml=, 
indicating the URI of the VoiceXML script to   
execute."
<FONT face=Arial 
color=#0000ff size=2>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. 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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: 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2><dialogstart 
src="">
<FONT face=Arial 
color=#0000ff size=2>  <namelist>
<FONT face=Arial 
color=#0000ff size=2>   <name="iterations" 
value="2"/>
<FONT face=Arial 
color=#0000ff size=2>   <name="timeout" 
value="5000ms"/>
<FONT face=Arial 
color=#0000ff size=2> </namelist>
<FONT face=Arial 
color=#0000ff size=2></dialogstart>
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>where the parameter set is similar to those used in 
H.248.7 IVR packages, MSCML, MOML, etc. 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>[3]  <FONT color=#0000ff 
size=2>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). 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT 
color=#0000ff size=2>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. 

<FONT 
color=#0000ff size=2> 
<FONT 
color=#0000ff size=2>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. 

<FONT face=Arial 
color=#0000ff size=2> 
<SPAN 
class=190241914-04022006><FONT color=#0000ff 
size=2>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.  
<FONT 
color=#0000ff size=2> 
<FONT 
color=#0000ff size=2>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.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>[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. 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>thanks
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Scott
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2> 

From: [email-masked] 
[mailto:[email-masked]] On Behalf Of 
Shtirmer, GeneSent: Friday, February 03, 2006 23:29To: 
Chris Boulton; [email-masked]: RE: 
[mediactrl] SIP Control Framework and IVR Package

<FONT face=Arial 

From: Chris Boulton 

<SPAN

---

From: "Shtirmer, Gene" <[email-masked]>
Date: Sat, 4 Feb 2006 18:31:03 GMT

<FONT face=Arial 
color=#0000ff size=2>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.  

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>So, the model I am using is as follows (please also 
see the simplified diagram below):
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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.  

<FONT face=Arial 
color=#0000ff size=2><FONT 
face=Arial color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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 <FONT 
color=#0000ff>OCMP Base and OCMP 
BRE, not between OCMP BRE and "Applications".  

<SPAN 
class=475173716-04022006> 
<SPAN 
class=475173716-04022006>Please see a few additional comments 
inline.
<SPAN 
class=475173716-04022006> 
<SPAN 
class=475173716-04022006>Regards,
<SPAN 
class=475173716-04022006>Gene.
<SPAN 
class=475173716-04022006> 
<SPAN 
class=475173716-04022006><IMG 
src="jpgwoO5J2Oe7d.jpg">

From: McGlashan, Scott 
[mailto:[email-masked]] Sent: Saturday, February 04, 2006 
11:31 AMTo: Shtirmer, Gene; Chris Boulton; 
[email-masked]: RE: [mediactrl] SIP 
Control Framework and IVR Package

<FONT face=Arial 
color=#0000ff>[1] On the use of CCXML, none of the current draft 
directly.  <SPAN 
class=475173716-04022006> 
color=#0000ff><SPAN 
class=475173716-04022006> 
face=Arial>[Gene 
Shtirmer]  I will defer to authors of the MSML syntax to comment 
on this point. 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT 

<FONT 
color=#0000ff size=2> 
<FONT 

<FONT face=Arial 
color=#0000ff size=2> 
<SPAN 
class=475173716-04022006>[Gene Shtirmer] I 
don't envision TDM connections being in scope of a media server.  That's a 
media gateway function.
class=475173716-04022006><FONT face=Arial color=#0000ff 

<FONT face=Arial 

From: Chris Boulton 

<SPAN

---

From: "McGlashan, Scott" <[email-masked]>
Date: Sat, 4 Feb 2006 23:03:32 GMT

<FONT face=Arial 
color=#0000ff size=2>Hi Gene,
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Thanks for your detailed response - apologies if I 
mis-understood your position.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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). 
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. 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>What I don't yet understand is how you can 
reconcile the location of the VoiceXML interpreter in the application 
layer and the<FONT face=Arial 
color=#0000ff size=2> M* proposals which consistently allow VoiceXML 
scripts to be passed through the Mr interface<SPAN 
class=518165420-04022006>.  For 
example, 
<FONT face=Arial 
color=#0000ff size=2> 
<SPAN 
class=518165420-04022006>MSCP: <SPAN 
class=518165420-04022006><dialogstart 
type="application/vxml+xml" src=""/'>http://server.example.com/scripts/foo.vxml"/>
<FONT face=Arial 
color=#0000ff size=2>MSML: 
<dialogstart type="application/vxml+xml" src=""/'>http://server.example.com/scripts/foo.vxml"/>
<FONT face=Arial 
color=#0000ff size=2> 
<SPAN 
class=518165420-04022006>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. 
<SPAN 
class=518165420-04022006> 
<SPAN 
class=518165420-04022006>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?  <FONT 
face=Arial color=#0000ff size=2>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.  
<SPAN 
class=518165420-04022006> 
<SPAN 
class=518165420-04022006>thanks
<SPAN 
class=518165420-04022006> 
<SPAN 
class=518165420-04022006>Scott
<SPAN 
class=518165420-04022006><SPAN 
class=518165420-04022006> 

From: Shtirmer, Gene 
[mailto:[email-masked]] Sent: Saturday, February 04, 2006 
19:39To: McGlashan, Scott; Chris Boulton; 
[email-masked]: RE: [mediactrl] SIP 
Control Framework and IVR Package

<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 

<FONT face=Arial 

<SPAN 
src="jpg9zIc1C676s.jpg">

From: McGlashan, Scott 

<FONT face=Arial 
size=+0>[Gene 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT 

<FONT 
color=#0000ff size=2> 
<FONT 

<FONT face=Arial 
color=#0000ff size=2> 
<SPAN 

<FONT face=Arial 

From: Chris Boulton 

<SPAN

---

From: "Shtirmer, Gene" <[email-masked]>
Date: Sun, 5 Feb 2006 03:41:04 GMT

<FONT face=Arial 
color=#0000ff size=2>Scott, thanks!!!  We are quickly getting to the core 
of the issues.  I've addressed your questions/comments 
inline...
 
<FONT 
color=#0000ff>Best 
Regards,
<SPAN 
class=712062001-05022006>Gene

From: McGlashan, Scott 
[mailto:[email-masked]] Sent: Saturday, February 04, 2006 
6:12 PMTo: Shtirmer, Gene; Chris Boulton; 
[email-masked]: RE: [mediactrl] SIP 
Control Framework and IVR Package

<FONT face=Arial 
color=#0000ff size=2>Hi Gene,
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Thanks for your detailed response - apologies if I 
mis-understood your position.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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).<FONT 
color=#000000> 
<FONT face=Arial 
color=#000000 size=2><SPAN 
class=712062001-05022006> 
<FONT face=Arial 
color=#800000 size=2>[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.
<FONT face=Arial 
color=#0000ff size=2><SPAN 
class=712062001-05022006> 
<FONT face=Arial 
color=#0000ff size=2>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. 
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>What I don't yet understand is how you can 
reconcile the location of the VoiceXML interpreter in the application 
layer and the<FONT face=Arial 
color=#0000ff size=2> M* proposals which consistently allow VoiceXML 
scripts to be passed through the Mr interface<SPAN 
class=518165420-04022006>.  For 
example, 
<FONT face=Arial 
color=#0000ff size=2> 
<SPAN 
class=518165420-04022006>MSCP: <SPAN 
class=518165420-04022006><dialogstart 
type="application/vxml+xml" src=""/'>http://server.example.com/scripts/foo.vxml"/>
<FONT face=Arial 
color=#0000ff size=2>MSML: 
<dialogstart type="application/vxml+xml" src=""/'>http://server.example.com/scripts/foo.vxml"/>
<FONT face=Arial 
color=#0000ff size=2> 
<FONT 
face=Arial>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. <SPAN 
class=712062001-05022006>  
 
<SPAN 
class=518165420-04022006> 
<SPAN 
class=518165420-04022006>[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.  
<SPAN 
class=518165420-04022006><SPAN 
class=712062001-05022006> 
<SPAN 
class=518165420-04022006>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.
<SPAN 
class=518165420-04022006><SPAN 
class=712062001-05022006> 
<SPAN 
class=518165420-04022006>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?  <FONT 
color=#0000ff>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.  <FONT 
color=#000000> 
<SPAN 
class=518165420-04022006><SPAN 
class=712062001-05022006> 
<SPAN 
class=518165420-04022006>[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.
<SPAN 
class=518165420-04022006><SPAN 
class=712062001-05022006> 
<SPAN 
class=518165420-04022006>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.
<SPAN 
class=518165420-04022006> 
<SPAN 
class=518165420-04022006>thanks
<SPAN 
class=518165420-04022006> 
<SPAN 
class=518165420-04022006>Scott
<SPAN 
class=518165420-04022006><FONT 
face=Arial size=2> 

From: Shtirmer, Gene 

<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 

<FONT face=Arial 

<SPAN 
src="jpgUd6mZ8zMpQ.jpg">

From: McGlashan, Scott 

<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT 

<FONT 
color=#0000ff size=2> 
<FONT 

<FONT face=Arial 
color=#0000ff size=2> 
<SPAN 

<FONT face=Arial 

From: Chris Boulton 

<SPAN

---

From: "McGlashan, Scott" <[email-masked]>
Date: Sun, 5 Feb 2006 19:48:40 GMT

<FONT face=Arial 
color=#0000ff size=2>Good discussion Gene. See my points 
inline.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>thanks
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Scott

From: Shtirmer, Gene 
[mailto:[email-masked]] Sent: Sunday, February 05, 2006 
04:49To: McGlashan, Scott; Chris Boulton; 
[email-masked]: RE: [mediactrl] SIP 
Control Framework and IVR Package

<FONT face=Arial 
 
<FONT 
color=#0000ff>Best 
Regards,
<SPAN 

From: McGlashan, Scott 

<FONT face=Arial 
color=#0000ff size=2>Hi Gene,
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Thanks for your detailed response - apologies if I 
mis-understood your position.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>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).<FONT 
color=#000000> 
<FONT face=Arial 
color=#000000 size=2><SPAN 
class=712062001-05022006> 
<SPAN 
class=712062001-05022006>[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.<FONT 
color=#0000ff> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006> 
<FONT 
size=+0><SPAN 
class=487380618-05022006>[Scott McGlashan] Reasonable intent but I still 
don't accept that a VoiceXML component is part of the application layer - 
for me it is part of the media server, providing a standard for 
interactive media dialogs. The HTTP protocol also needs to be supported by media 
servers if, as most do, they allow media resources to be fetched using HTTP. Nor 
is HTTP necessary for VoiceXML scripts: M* specs allow VoiceXML to be 
transported inline over SIP/dedicated control channel. However, 
a<FONT 
size=+0><SPAN 
class=487380618-05022006>t the heart of this is 'What is a Media 
Server?". Difficult to tackle head-on, but the requirements spec 
is making some progress on the nature of the media control protocol <A 
href="http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.txt. ">http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.txt. 
<SPAN 
class=518165420-04022006><SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006>(to be updated 
with changes discussed at the Vancouver meeting. Martin is about to 
update the document real soon now!). We still need to address requirements on 
how IVR dialogs are specified - or better: whatever the format, the requirements 
they must satisfy. 

<FONT face=Arial 
 
<SPAN 
class=518165420-04022006> 
<SPAN 
class=518165420-04022006>[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.  
<SPAN 
class=518165420-04022006><SPAN 
class=712062001-05022006> 
<SPAN 
class=712062001-05022006>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.<FONT 
color=#0000ff> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006><SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006>[Scott McGlashan] I certainly agree that we should 
take a critical look at layers, functional entities, protocols, etc. One of the 
things l see is that the use of VoiceXML to specify interactive media dialogs is 
'shared ground' for many media servers, and that the motivation is, in part, 
driven by customers and application developers wanting to use an existing IVR 
standard where its fulfils their 
requirements.  
<SPAN 
class=518165420-04022006><SPAN 
class=712062001-05022006> 
<SPAN 
class=518165420-04022006>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?  <FONT 
color=#0000ff>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.  <FONT 
color=#000000> 
<SPAN 
class=518165420-04022006><SPAN 
class=712062001-05022006> 
<SPAN 
class=712062001-05022006>[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.<SPAN 
class=487380618-05022006><FONT 
color=#0000ff> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006><SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006><SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006>[Scott McGlashan] In a later version of IMS, the 
architecture may change. Right now, I need to deal with what is 
currently specified in 3GPP - and that includes a low-level Mp interface based 
on H.248 which I don't think is going to change in the short term.  I 
believe we have the opportunity to align the Mr interface of the MRF towards an 
IETF media control language which is service-oriented rather than low-level, and 
I see VoiceXML playing a role defining IVR dialogs within this 
language. I'm certainly open to later revision of the Mp interface along 
the lines of a low-level XML language over a dedicated control channel. 

<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006><SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006><SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006><SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006> 

From: Shtirmer, Gene 

<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 

<FONT face=Arial 

<SPAN 
src="jpgHnibCF05at.jpg">

From: McGlashan, Scott 

<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 

<FONT face=Arial 
color=#0000ff size=2> 
<FONT 

<FONT 
color=#0000ff size=2> 
<FONT 

<FONT face=Arial 
color=#0000ff size=2> 
<SPAN 

<FONT face=Arial 

From: Chris Boulton 

<SPAN

---

From: "Shtirmer, Gene" <[email-masked]>
Date: Mon, 6 Feb 2006 16:00:17 GMT

<FONT face=Arial 
color=#0000ff size=2>Dave, great to hear from you.  I am out of breath 
after sparring with Scott all weekend - fantastic discussion, 
Scott!
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Your suggestion regarding the packages/modules approach is 
a constructive one.  However, there is a danger that we would not 
really be consolidating the different types of protocols - the protocol 
soup is what I called it earlier.  We'd simply create as many packages as 
there are opposing views in this group.  How would that help our cause in 
3GPP, for example.  Which package would we push, or would you be ok with 
the MSML/MOML type package specifically for the Mr IMS 
interface?
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Rgds,
<FONT face=Arial 
color=#0000ff size=2>gene

From: Dave Burke 
[mailto:[email-masked]] Sent: Monday, February 06, 2006 
5:38 AMTo: Shtirmer, Gene; McGlashan, Scott; Chris Boulton; 
[email-masked]: Re: [mediactrl] SIP 
Control Framework and IVR Package

Interesting conversation. 
 
The crux of the problem is, as Scott said, 
"What is a media server?". <FONT 
face=Arial size=2>I see both viewpoints though I weigh in on the 
VoiceXML-enabled MRF (and of course my company's product line at least partly 
influences that decision). 
 
Are we expecting to address all of the following: 
(1) What is a media server?, (2) How can we fix IMS viz-a-viz media server 
architecture?, (3) Standardise a "good" media server control protocol? 

While "IP Mobile Billing System (IMBS)", oops 
- I meant IP Multimedia Subsystem (IMS), is an important 
architecture,  we ought 
to consider standardising a protocol that while applicable to IMS, is 
also suitable for other architectures. Now, I know there was little support for 
this but the idea of packages/profiles still seems like a reasonable solution - 
e.g. a package for low-level stuff, a package for dialog, a package for 
conferencing. Different architectures will use different packages. This 
flexibility will allow some freedom (and maintain the protocol's applicability) 
in IMS architectures as it inevitably evolves.
 
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: 
  <A title=[email-masked] 
  href="mailto:[email-masked]">Shtirmer, Gene 
  To: <A title=[email-masked] 
  href="mailto:[email-masked]">McGlashan, Scott ; <A 
  title=[email-masked] href="mailto:[email-masked]">Chris 
  Boulton ; <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked] 
  
  Sent: Monday, February 06, 2006 4:51 
  AM
  Subject: RE: [mediactrl] SIP Control 
  Framework and IVR Package
  
  <SPAN 
  class=994430920-05022006>Scott, thanks again for the great discussion.  
  I've responded to your latest arguments in line, but I think at this point we 
  understand each of our respective positions rather well.  Let's 
  continue the dialog.  I'd also love to hear what others in this 
  group think about these issues.
  <SPAN 
  class=994430920-05022006> 
  <SPAN 
  class=994430920-05022006>Regards,
  <SPAN 
  class=994430920-05022006>Gene

  From: McGlashan, Scott 
  [mailto:[email-masked]] Sent: Sunday, February 05, 2006 
  2:57 PMTo: Shtirmer, Gene; Chris Boulton; <A 
  href="mailto:[email-masked]">[email-masked]: 
  RE: [mediactrl] SIP Control Framework and IVR Package
  
  <FONT face=Arial 

  From: Shtirmer, Gene 
  
  <FONT face=Arial 
   
  <FONT 
  color=#0000ff>Best 
  Regards<SPAN 
  class=712062001-05022006>,
  <SPAN 
  class=712062001-05022006>Gene

  From: McGlashan, Scott 
  
  <FONT face=Arial 
  color=#0000ff size=2>Hi Gene,
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>Thanks for your detailed response - apologies if I 
  mis-understood your position.
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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).<FONT 
  color=#000000> 
  <FONT face=Arial 
  color=#000000 size=2><SPAN 
  class=712062001-05022006> 
  <FONT 
  color=#800000><FONT 
  size=2>[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.<SPAN 
  class=487380618-05022006><FONT 
  color=#0000ff> 
  <FONT 
  color=#800000><FONT 
  size=2><SPAN 
  class=487380618-05022006> 
  <SPAN 
  class=518165420-04022006><FONT face=Arial 
  size=2>[Scott McGlashan] Reasonable intent 
  but I still don't accept that a VoiceXML component is part of the 
  application layer - for me it is part of the media server, 
  providing a standard for interactive media dialogs.<SPAN 
  class=994430920-05022006><FONT 
  color=#0000ff> 
  <SPAN 
  class=518165420-04022006><FONT face=Arial 
  size=2><SPAN 
  class=994430920-05022006> 
  <SPAN 
  class=712062001-05022006><SPAN 
  class=487380618-05022006>[Gene Shtirmer] 
  I believe we are reaching a stalemate on this point.  I'd like to 
  see others chime in here...
  <SPAN 
  class=518165420-04022006><FONT face=Arial 
  size=2><SPAN 
  class=994430920-05022006> 
  <SPAN 
  class=518165420-04022006><FONT face=Arial 
  size=2>The HTTP protocol also needs to be 
  supported by media servers if, as most do, they allow media resources to be 
  fetched using HTTP. <FONT 
  color=#0000ff> 
  <SPAN 
  class=518165420-04022006><FONT face=Arial 
  size=2><SPAN 
  class=994430920-05022006> 
  <SPAN 
  class=712062001-05022006><SPAN 
  class=487380618-05022006>[Gene Shtirmer] Agreed 
  - media servers typically do need to have an HTTP client and possibly an 
  RTSP client, but that's not the issue in my 
  view.
  <SPAN 
  class=518165420-04022006><FONT face=Arial 
  size=2><SPAN 
  class=994430920-05022006> 
  <SPAN 
  class=518165420-04022006><FONT face=Arial 
  size=2>Nor is HTTP necessary for VoiceXML 
  scripts: M* specs allow VoiceXML to be transported inline over SIP/dedicated 
  control channel. However, a<SPAN 
  class=518165420-04022006><FONT 
  face=Arial>t the heart of this 
  is 'What is a Media Server?". Difficult to tackle head-on, 
  but the requirements spec is making some progress on the nature of 
  the media control protocol <A 
  href="http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.txt. ">http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.txt. 
  <SPAN 
  class=518165420-04022006><SPAN 
  class=712062001-05022006><SPAN 
  class=487380618-05022006>(to be 
  updated with changes discussed at the Vancouver meeting. Martin is 
  about to update the document real soon now!). We still need to address 
  requirements on how IVR dialogs are specified - or better: whatever the 
  format, the requirements they must satisfy. 
  
  <FONT face=Arial 
  color=#0000ff size=2><SPAN 
  class=712062001-05022006> 
  <FONT face=Arial 
  color=#0000ff size=2>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. 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>What I don't yet understand is how you can 
  reconcile the location of the VoiceXML interpreter in the application 
  layer and the<FONT 
  face=Arial color=#0000ff size=2> M* proposals which consistently allow 
  VoiceXML scripts to be passed through the Mr interface<SPAN 
  class=518165420-04022006>.  For 
  example, 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT 
  color=#0000ff>MSCP: 
  <FONT face=Arial 
  color=#0000ff size=2><dialogstart type="application/vxml+xml" src=""/'>http://server.example.com/scripts/foo.vxml"/>
  <FONT face=Arial 
  color=#0000ff size=2>MSML: 
  <dialogstart type="application/vxml+xml" src=""/'>http://server.example.com/scripts/foo.vxml"/>
  <FONT face=Arial 
  color=#0000ff size=2> 
  <SPAN 
  class=518165420-04022006>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. <FONT 
  color=#000000>   
  <SPAN 
  class=518165420-04022006> 
  <SPAN 
  class=518165420-04022006>[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.  
  <SPAN 
  class=518165420-04022006><SPAN 
  class=712062001-05022006> 
  <SPAN 
  class=518165420-04022006><FONT 
  size=2>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.<SPAN 
  class=487380618-05022006><FONT 
  color=#0000ff> 
  <SPAN 
  class=518165420-04022006><FONT 
  size=2><SPAN 
  class=487380618-05022006> 
  <SPAN 
  class=712062001-05022006><SPAN 
  class=518165420-04022006><FONT 
  color=#008080><FONT 
  size=2>[Scott McGlashan] I certainly agree that we should take a critical 
  look at layers, functional entities, protocols, etc. One of the things l see 
  is that the use of VoiceXML to specify interactive media dialogs is 'shared 
  ground' for many media servers, and that the motivation is, in part, driven by 
  customers and application developers wanting to use an existing IVR standard 
  where its fulfils their requirements.  <SPAN 
  class=994430920-05022006><FONT 
  color=#0000ff> 
  <SPAN 
  class=712062001-05022006><SPAN 
  class=518165420-04022006><FONT 
  color=#008080><FONT 
  size=2><SPAN 
  class=994430920-05022006> 
  <SPAN 
  class=712062001-05022006><SPAN 
  class=518165420-04022006><SPAN 
  class=487380618-05022006><SPAN 
  class=994430920-05022006>[Gene Shtirmer]  This is exactly where we differ 
  - what you call media server with VoiceXML interface, I call a media server 
  plus an application server with VoiceXML (and CCXML) interpreter(s).  My 
  goal is to define an interface between this app server and the media 
  server.
  <SPAN 
  class=518165420-04022006><SPAN 
  class=712062001-05022006> 
  <FONT 
  color=#0000ff>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?  <FONT 
  color=#0000ff>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.  <FONT 
  color=#000000> 
  <FONT 
  color=#0000ff><SPAN 
  class=712062001-05022006> 
  <SPAN 
  class=518165420-04022006><FONT 
  size=2>[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.<SPAN 
  class=487380618-05022006><FONT 
  color=#0000ff> 
  <SPAN 
  class=518165420-04022006><FONT 
  size=2><SPAN 
  class=487380618-05022006> 
  <SPAN 
  class=518165420-04022006><SPAN 
  class=487380618-05022006><SPAN 
  class=712062001-05022006><SPAN 
  class=518165420-04022006><FONT 
  color=#008080><FONT 
  size=2>[Scott McGlashan] In a later version of IMS, the architecture 
  may change. Right now, I need to deal with what is currently 
  specified in 3GPP - and that includes a low-level Mp interface based on H.248 
  which I don't think is going to change in the short term.  I believe 
  we have the opportunity to align the Mr interface of the MRF towards an IETF 
  media control language which is service-oriented rather than low-level, and I 
  see VoiceXML playing a role defining IVR dialogs within this 
  language. I'm certainly open to later revision of the Mp interface along 
  the lines of a low-level XML language over a dedicated control 
  channel. <FONT 
  color=#0000ff> 
  <SPAN 
  class=518165420-04022006><SPAN 
  class=487380618-05022006><SPAN 
  class=712062001-05022006><SPAN 
  class=518165420-04022006><FONT 
  color=#008080><FONT 
  size=2><SPAN 
  class=994430920-05022006> 
  <SPAN 
  class=712062001-05022006><SPAN 
  class=518165420-04022006><SPAN 
  class=487380618-05022006><SPAN 
  class=712062001-05022006><FONT 
  size=2>[Gene Shtirmer] Just 
  because it's currently part of 3GPP IMS definition, doesn't mean we should 
  embrace this architecture with all its faults "word-for-word".  By 
  backing into existing architectural mistakes we will only exacerbate the 
  problems, that many in this industry have voiced, for example, wrt H.248 
  protocol's choice at the Mp interface.   Mp interface is 
  optional anyway, as the MRF does not have to be decomposed per the IMS 
  spec.  After all, even though based on your arguments I should infer that 
  both OCMP Base and OCMP BRE are part of media server, you do not use H.248 
  between OCMP Base and OCMP BRE.  At the same time, the Mr 
  interface is open to interpretation for the most part.  Let's 
  capitalize on this fact and do what makes 
  sense.
  <SPAN 
  class=518165420-04022006><FONT 
  size=2><SPAN 
  class=712062001-05022006><SPAN 
  class=487380618-05022006><SPAN 
  class=712062001-05022006><SPAN 
  class=487380618-05022006> 
  <SPAN 
  class=518165420-04022006><FONT 
  size=2>[Gene Shtirmer] 
  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.
  <SPAN 
  class=518165420-04022006><SPAN 
  class=712062001-05022006><SPAN 
  class=487380618-05022006><SPAN 
  class=712062001-05022006><SPAN 
  class=487380618-05022006> 
  <SPAN 
  class=518165420-04022006> 
  <SPAN 
  class=518165420-04022006>thanks
  <SPAN 
  class=518165420-04022006> 
  <SPAN 
  class=518165420-04022006>Scott
  <SPAN 
  class=518165420-04022006><FONT 
  face=Arial size=2> 

  From: Shtirmer, Gene 
  
  <FONT face=Arial 
  color=#0000ff size=2>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.  
  
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>So, the model I am using is as follows (please also 
  see the simplified diagram below):
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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.
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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.
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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.  
  <FONT face=Arial 
  color=#0000ff size=2><FONT 
  face=Arial color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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 <FONT 
  color=#0000ff>OCMP Base and OCMP 
  BRE, not between OCMP BRE and "Applications".  
  
  <FONT 
  size=2> 
  <FONT 
  size=2>Please see a few additional comments 
  inline.
  <FONT 
  size=2> 
  <FONT 
  size=2><SPAN 
  class=475173716-04022006>Regards,
  <FONT 
  size=2>Gene.
  <FONT 
  size=2> 
  <FONT 
  size=2><IMG 
  src="jpgDKoULyiGYV.jpg">

  From: McGlashan, Scott 
  
  <FONT face=Arial 
  color=#0000ff size=2>Hi Gene,
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>thanks for your comments. 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT 
  color=#0000ff>[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.  <SPAN 
  class=475173716-04022006> 
  <FONT 
  color=#0000ff><SPAN 
  class=475173716-04022006> 
  <FONT 
  size=+0>[Gene 
  Shtirmer]  I will defer to authors of the MSML syntax to 
  comment on this point. 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>[2] The use of VoiceXML for interactive IVR dialogs 
  is recognized by MSCP, MSML, MSCML and netann (<SPAN 
  class=190241914-04022006>MSCP and MSML 
  use the dialogstart concept to invoke dialogs where the script language can be 
  any dialog language): 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>MSCP: "IVR dialogs can be specified in 
  VoiceXML."
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>MSCML: "for complex IVR it may be more appropriate 
  to employ a full IVR markup language such as VoiceXML"
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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." 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>netann: "dialog service takes a parameter, voicexml=, 
  indicating the URI of the VoiceXML script to   
  execute."
  <FONT face=Arial 
  color=#0000ff size=2>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. 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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: 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2><dialogstart 
  src="">
  <FONT face=Arial 
  color=#0000ff size=2>  <namelist>
  <FONT face=Arial 
  color=#0000ff size=2>   <name="iterations" 
  value="2"/>
  <FONT face=Arial 
  color=#0000ff size=2>   <name="timeout" 
  value="5000ms"/>
  <FONT face=Arial 
  color=#0000ff size=2> </namelist>
  <FONT face=Arial 
  color=#0000ff size=2></dialogstart>
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>where the parameter set is similar to those used in 
  H.248.7 IVR packages, MSCML, MOML, etc. 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>[3]  <FONT 
  color=#0000ff size=2>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). 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT 
  color=#0000ff size=2>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. 
  
  <FONT 
  color=#0000ff size=2> 
  <FONT 
  color=#0000ff size=2>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. 
  
  <FONT face=Arial 
  color=#0000ff size=2> 
  <SPAN 
  class=190241914-04022006><FONT color=#0000ff 
  size=2>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.  
  <FONT 
  color=#0000ff size=2> 
  <FONT 
  color=#0000ff size=2>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.
  <FONT face=Arial 
  color=#0000ff size=2> 
  <SPAN 
  class=475173716-04022006>[Gene Shtirmer] 
  I don't envision TDM connections being in scope of a media server.  
  That's a media gateway function.
  <SPAN 
  class=475173716-04022006><FONT face=Arial color=#0000ff 
  size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>[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. 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>thanks
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>Scott
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2> 

  From: 
  Shtirmer, GeneSent: Friday, February 03, 2006 
  23:29To: Chris Boulton; 
  
  <FONT face=Arial 
  color=#0000ff size=2>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.
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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.  
  <FONT face=Arial 
  color=#0000ff size=2> 
  <FONT face=Arial 
  color=#0000ff size=2>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.
  <FONT face=Arial color=#0000ff 
  size=2> 
  <FONT face=Arial color=#0000ff 
  size=2>Regards,
  Gene 
  Shtirmer
  <FONT face=Arial color=#0000ff 
size=2>

  From: Chris Boulton 

  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">FYI.
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original 
  Message-----From: 
  [email-masked] 
  [mailto:[email-masked]] <SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of Chris Boulton<SPAN 
  style="FONT-WEIGHT: bold">Sent: <FONT face=Tahoma 
  size=2>23 December 
  2005<SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> <FONT face=Tahoma 
  size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">11:06<FONT 
  face=Tahoma size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><SPAN 
  style="FONT-WEIGHT: bold">To: 
  [email-masked]<SPAN 
  style="FONT-WEIGHT: bold">Cc: McGlashan, Scott; Tim Melanchuk; 
  Asher Shiratzky; Eric Burger; [email-masked]; Dolly, Martin C, 
  ALABSSubject: [mediactrl] 
  SIP Control Framework and IVR Package
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi All,
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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:-
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">- A <SPAN 
  style="FONT-WEIGHT: bold">Control Framework for the Session Initiation 
  Protocol (SIP)
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Abstract
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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.
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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.
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">- <SPAN 
  style="FONT-WEIGHT: bold">An Interactive Voice (IVR) Control Package for the 
  Session Initiation Protocol (SIP)
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Abstract
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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].
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Until the drafts appear in the 
  archives, they will be available from the following links:-
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
  href="http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.txt">http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.txt
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
  href="http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.html">http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.html
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">and
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
  href="http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.txt">http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.txt
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A 
  href="http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.html">http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.html
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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).
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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. 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Seasons Greetings to 
  all,
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The Authors.
  <SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"><FONT face=Verdana size=1 
  colour="#cccccc"><SPAN 
  style="FONT-SIZE: 7.5pt; FONT-FAMILY: Verdana">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

---

From: "Mark Scott" <[email-masked]>
Date: Tue, 7 Feb 2006 06:12:35 GMT

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>This has certainly been a very interesting
E-mail thread to read through.

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>As I think Dave’s message implies, we’re
really dealing with two separate issues – (1) what the appropriate logical
architecture is for delivering VoiceXML/CCXML services in NGN/IMS
architectures, and (2) how do we draw boxes labeled “application server”
and “media server” around the elements of those architectures, and
put labels like “Mp” and “Mr”.

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Gene’s diagram from Saturday was
useful to me in that it delineated VoiceXML/CCXML interpretation and processing
from the media processing resources used to realize those applications. 
This is a model that we strongly believe in; our view is that the companies and
technologies best suited to building “soft or hard DSP”
functionality and associated packaging are very different from the companies
that are best at VoiceXML/CCXML interpreter technology.  Furthermore, the
ideal computing platforms for “hard DSP” and for HTTP/XML/ECMAScript-centric
languages like VoiceXML/CCXML are inherently different – which is likely
why embedded web servers don’t handle the majority of online transactions
today.

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>As an industry, we have certainly
demonstrated that these are not hard lines; many hardware-centric media server
companies have put VoiceXML implementations on their products which work fine
(as long as it’s VoiceXML 1.0), just as a number of VoiceXML platform
companies have embedded lightweight, software-based media servers that work fine
too (as long as it’s G.711).  I’m exaggerating somewhat, but I
think that a line drawn with DOM-enabled VoiceXML 2.1 + speech on one side, and
high-density complex codec transcoding on the other is a fairly clear and
straight line.

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Getting back to the original two issues,
Scott’s statement that he agrees with separation of VoiceXML/CCXML from low-level
media operations, coupled with Gene’s diagram showing this (albeit with
somewhat different boxes) implies to me that we collectively seem to agree on
(1) – though not without a few subtle nuances – but not on (2).

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Our view on (2) is that with the exception
of H.248 for Mp, and the absence of any consideration of VoiceXML in current
specifications, the IMS architecture with the separation of MRFC and MRFP
elements is a good one.  Notionally, MRFP seems to correspond quite
clearly to “Soft or Hard DSPs” with some low-level interface protocol;
MRFC seems to match the nature of a VoiceXML interpreter quite well.  This
seems particularly true to us when you consider additional speech resources
such as ASR servers and TTS servers, which are in essence additional kinds of
MRFPs.  It seems logically sound for an MRFC (VoiceXML) to orchestrate a
heterogeneous collection of MRFP resources in the execution of a VoiceXML
page.  Indeed, when you consider the operation of speech recognition or
speech synthesis, the notion of H.248 as the sole protocol for interacting with
the MRFP becomes increasingly problematic – as it seems beyond doubt that
MRCPv1/2 will be the protocol of choice for interacting with ASR, TTS, SI/SV,
and other such services at least for the near future.

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>While the apparent firmness of H.248 as
the Mp protocol unfortunately seems to prevent the IMS MRFC/MRFP separation
from being applied exactly as it is described here, it is our belief that the
separation describes above will ultimately prove to be the correct one,
regardless of where exactly the lines are drawn.  But is it really a
deal-breaker if the best IMS MRF implementations are distributed solutions of
multiple elements that co-ordinate using standards-based protocols like
MSML/MSCML/MSCP/MRCPv2?

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>In terms of where we’d draw various
lines, in our view, the nature of the interaction between VoiceXML and the
resources it uses make VoiceXML existing purely at an application server level somewhat
problematic.  This might work reasonably if VoiceXML could be implemented
using a straightforward set of primitives exposed via some fine-grained M*
protocol, but it cannot use this exclusively if it also incorporates speech processing
via MRCPv1/2 – as we believe many compelling applications will.  Proxying
MRCPv1/2 via the media server doesn’t seem like a particularly attractive
option.  If a VoiceXML “application server” was in fact doing
complex low-level control of a media server, while simultaneously orchestrating
similarly low-level MRCPv1/2 based control of both speech recognition and speech
synthesis resources, the coupling between these elements would likely be such
that we’d essentially wind up arriving in the camp that I think we’re
trying to avoid – media servers being “built into”
application servers.  The sheer amount of messaging and interaction in
such an ASR/TTS-enabled case would certainly prevent the application servers
from living outside the core network, as Scott alludes to.

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Another key reason that we see VoiceXML as
an application server being challenging is that this will invariably give the
impression that people are intended to express application logic in VoiceXML,
and that it is an alternative kind of application server.  What may be
less clear is that chains of application servers are quite permissible (i.e. a
VoiceXML AS is not a substitute for other kinds of application servers) –
and that in fact, the services offered by VoiceXML are quite desirable to
application servers.  It’s one thing for an application server to
make use of some SIP-based protocol to have a media server play a prompt. 
When that application server tries to play synthesized speech while collecting
input using both DTMF and ASR simultaneously and also allowing mixed initiative
to fill multiple slots with a single utterance, VoiceXML is going to start
looking like a very attractive alternative to directly controlling multiple
media processing elements.

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>This view of VoiceXML as a service that is
used primarily by application servers, and the need for a protocol that
supports this effectively by building further semantics beyond those in NETANN,
is the primary motivation behind our participation in draft-burke-vxml-00. 
This isn’t inconsistent at all in our minds with a VoiceXML
implementation offering draft-burke-vxml-00 on one interface, but using
lower-level M* (or other) protocols in addition to MRCP on another to control
underlying resources.  In fact, we’ve done and are continuing to do
exactly this with some of our partners.

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>I’m hopeful that the above is useful
in some way beyond being sufficiently long winded so as to increase quarterly
revenues for the storage companies.  I do think the issues we’re
discussing here are particularly crucial, but I’m also optimistic that
our views differ mostly in nomenclature as opposed to intent.

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

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

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

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

<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]]
On Behalf Of Dave Burke
Sent: Monday, February 06, 2006
5:38 AM
To: Shtirmer, Gene; McGlashan,
Scott; Chris Boulton; [email-masked]
Subject: Re: [mediactrl] SIP
Control Framework and IVR Package

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

<span style='font-size:10.0pt;
font-family:Arial'>Interesting conversation. 

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

<span style='font-size:10.0pt;
font-family:Arial'>The crux of the problem is, as Scott said, "What is a
media server?". I see both viewpoints though I weigh in on the
VoiceXML-enabled MRF (and of course my company's product line at least partly
influences that decision). 

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

<span style='font-size:10.0pt;
font-family:Arial'>Are we expecting to address all of the following: (1) What
is a media server?, (2) How can we fix IMS viz-a-viz media server
architecture?, (3) Standardise a "good" media server control
protocol? 

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

<span style='font-size:10.0pt;
font-family:Arial'>While "IP Mobile Billing System (IMBS)", oops
- I meant IP Multimedia Subsystem (IMS), is an important
architecture,  we ought to consider standardising a protocol
that while applicable to IMS, is also suitable for other architectures. Now, I
know there was little support for this but the idea of packages/profiles still
seems like a reasonable solution - e.g. a package for low-level stuff, a
package for dialog, a package for conferencing. Different architectures will
use different packages. This flexibility will allow some freedom (and maintain
the protocol's applicability) in IMS architectures as it inevitably evolves.

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

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

<blockquote style='border:none;border-left:solid black 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'>----- Original Message ----- 

<span
style='font-size:10.0pt;font-family:Arial;font-weight:bold'>From:<font
size=2 face=Arial> <a
href="mailto:[email-masked]" title="[email-masked]">Shtirmer,
Gene 

<span style='font-size:10.0pt;
font-family:Arial;font-weight:bold'>To:<font size=2
face=Arial> <a
href="mailto:[email-masked]" title="[email-masked]">McGlashan,
Scott ; Chris
Boulton ; <a href="mailto:[email-masked]"
title="[email-masked]">[email-masked]

<span style='font-size:10.0pt;
font-family:Arial;font-weight:bold'>Sent:<font size=2
face=Arial> Monday, February
06, 2006 4:51 AM

<span style='font-size:10.0pt;
font-family:Arial;font-weight:bold'>Subject:<font size=2
face=Arial> RE: [mediactrl]
SIP Control Framework and IVR Package

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>Scott, thanks again for the great
discussion.  I've responded to your latest arguments in line, but I think
at this point we understand each of our respective positions rather
well.  Let's continue the dialog.  I'd also love to
hear what others in this group think about these issues.

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

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

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

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

<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>
McGlashan, Scott [mailto:[email-masked]] 
Sent: Sunday, February 05, 2006
2:57 PM
To: Shtirmer, Gene; Chris Boulton;
[email-masked]
Subject: RE: [mediactrl] SIP
Control Framework and IVR Package

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>Good discussion Gene. See my points
inline.

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

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

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

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

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

<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> Shtirmer,
Gene [mailto:[email-masked]] 
Sent: Sunday, February 05, 2006
04:49
To: McGlashan, Scott; Chris
Boulton; [email-masked]
Subject: RE: [mediactrl] SIP
Control Framework and IVR Package

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>Scott, thanks!!!  We are quickly
getting to the core of the issues.  I've addressed your questions/comments
inline...

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

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

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

<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>
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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>Thanks for your detailed response -
apologies if I mis-understood your position.

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

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

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:teal'>[Scott McGlashan] Reasonable intent
but I still don't accept that a VoiceXML component is part of the
application layer - for me it is part of the media server, providing a
standard for interactive media dialogs.<font size=2 color=blue
face=Arial> 

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

<span style='font-size:
10.0pt;font-family:Arial;color:red'>[Gene Shtirmer] I believe we are
reaching a stalemate on this point.  I'd like to see others chime in
here...

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

<span style='font-size:
10.0pt;font-family:Arial;color:teal'>The HTTP protocol also needs to be
supported by media servers if, as most do, they allow media resources to be
fetched using HTTP. <span
style='font-size:10.0pt;font-family:Arial;color:blue'> 

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

<span style='font-size:
10.0pt;font-family:Arial;color:red'>[Gene Shtirmer] Agreed - media
servers typically do need to have an HTTP client and possibly an RTSP
client, but that's not the issue in my view.

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

<span style='font-size:
10.0pt;font-family:Arial;color:teal'>Nor is HTTP necessary for VoiceXML
scripts: M* specs allow VoiceXML to be transported inline over SIP/dedicated
control channel. However, at the heart of this is 'What is a Media
Server?". Difficult to tackle head-on, but the
requirements spec is making some progress on the nature of the media
control protocol <a
href="http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.txt.%20">http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.txt.
(to be updated with changes discussed at the <st1:place
 w:st="on">Vancouver meeting. Martin is about to update
the document real soon now!). We still need to address requirements on how IVR
dialogs are specified - or better: whatever the format, the requirements they
must satisfy.<span
style='font-size:10.0pt;font-family:Arial;color:blue'> 

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

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

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>MSCP: <dialogstart
type="application/vxml+xml" src=""
href="http://server.example.com/scripts/foo.vxml">http://server.example.com/scripts/foo.vxml"/>

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>MSML: <dialogstart type="application/vxml+xml" src=""
href="http://server.example.com/scripts/foo.vxml">http://server.example.com/scripts/foo.vxml"/>

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

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

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

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

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:teal'>[Scott McGlashan] I certainly agree
that we should take a critical look at layers, functional entities, protocols,
etc. One of the things l see is that the use of VoiceXML to specify interactive
media dialogs is 'shared ground' for many media servers, and that the
motivation is, in part, driven by customers and application developers wanting
to use an existing IVR standard where its fulfils their
requirements.  <span
style='font-size:10.0pt;font-family:Arial;color:blue'> 

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

<span style='font-size:
10.0pt;font-family:Arial;color:red'>[Gene Shtirmer]  This is exactly where
we differ - what you call media server with VoiceXML interface, I call a media
server plus an application server with VoiceXML (and CCXML)
interpreter(s).  My goal is to define an interface between this app server
and the media server.

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>[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.<font size=2 color=blue
face=Arial> 

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

<span style='font-size:
10.0pt;font-family:Arial;color:teal'>[Scott McGlashan] In a later version
of IMS, the architecture may change. Right now, I need to deal
with what is currently specified in 3GPP - and that includes a low-level Mp
interface based on H.248 which I don't think is going to change in the
short term.  I believe we have the opportunity to align the Mr interface
of the MRF towards an IETF media control language which is service-oriented
rather than low-level, and I see VoiceXML playing a role defining IVR dialogs
within this language. I'm certainly open to later revision of the Mp
interface along the lines of a low-level XML language over a dedicated control
channel. <span
style='font-size:10.0pt;font-family:Arial;color:blue'> 

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

<span style='font-size:10.0pt;
font-family:Arial'>[Gene Shtirmer] Just
because it's currently part of 3GPP IMS definition, doesn't mean we should
embrace this architecture with all its faults
"word-for-word".  By backing into existing architectural
mistakes we will only exacerbate the problems, that many in this industry
have voiced, for example, wrt H.248 protocol's choice at the Mp
interface.   Mp interface is optional anyway, as the MRF does not
have to be decomposed per the IMS spec.  After all, even though based on
your arguments I should infer that both OCMP Base and OCMP BRE are part of
media server, you do not use H.248 between OCMP Base and OCMP
BRE.  At the same time, the Mr interface is open to
interpretation for the most part.  Let's capitalize on this fact and
do what makes sense.

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

<span style='font-size:
10.0pt;font-family:Arial;color:black'>[Gene Shtirmer] <font
size=2 color=maroon face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:maroon'>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.

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

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

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

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

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

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

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

<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> 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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>So, the model I am using is as
follows (please also see the simplified diagram below):

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

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

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

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

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

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

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>Please see a few additional comments
inline.

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

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'><img border=0 width=800 height=593
id="_x0000_i1029" src="jpgexe7dtvBwF.jpg">

<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>
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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>thanks for your comments. 

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>[Gene Shtirmer]  I will defer
to authors of the MSML syntax to comment on this point. 

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>MSCP: "IVR dialogs can be
specified in VoiceXML."

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>MSCML: "for complex IVR it may be
more appropriate to employ a full IVR markup language such as VoiceXML"

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>netann: "dialog service takes a
parameter, voicexml=, indicating the URI of the VoiceXML script to
   execute."

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

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'><dialogstart
src="">

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>  
<name="iterations" value="2"/>

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>   <name="timeout"
value="5000ms"/>

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>where the parameter set is similar to
those used in H.248.7 IVR packages, MSCML, MOML, etc. 

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

<span style='font-size:
10.0pt;font-family:Arial;color:blue'>[3]  <font size=2
color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>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). 

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

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

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

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

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

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

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

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

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

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>[Gene Shtirmer] I don't envision TDM
connections being in scope of a media server.  That's a media gateway
function.

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

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

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

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

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

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

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

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

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

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

<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 Shtirmer, Gene
Sent: Friday, February 03, 2006
23:29
To: Chris Boulton;
[email-masked]
Subject: RE: [mediactrl] SIP
Control Framework and IVR Package

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

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

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

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

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

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

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

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

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

<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> 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

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

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

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

<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 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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>Hi All,

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>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:-

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>- A Control
Framework for the Session Initiation Protocol (SIP)

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>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.

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>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.

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>- An Interactive
Voice (IVR) Control Package for the Session Initiation Protocol (SIP)

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>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].

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>Until the drafts appear in the archives, they will be
available from the following links:-

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'><a
href="http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.txt">http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.txt

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'><a
href="http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.html">http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework-00.html

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>and

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'><a
href="http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.txt">http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.txt

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'><a
href="http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.html">http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-00.html

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>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).

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>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. 

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>Seasons Greetings to all,

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>The Authors.

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

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

<span
style='font-size:7.5pt;font-family:Verdana'>Information contained in this

---

From: "Shtirmer, Gene" <[email-masked]>
Date: Thu, 9 Feb 2006 20:24:26 GMT

<FONT face=Arial 
color=#0000ff size=2>Mark, thanks for your e-mail.  I commented 
inline...
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>I am still thinking about Dave Burke's comment earlier this 
week regarding modularizing the media server control protocol.  In general, 
I like the idea of having packages: some could be mandatory, others could 
be optional.  So, VoiceXML syntax could be defined as a package (as it was 
started to in the IVR package), as well as MxML type syntax could be defined as 
one or more additional packages.  But it seems that making VoiceXML package 
a mandatory part of a media control protocol would be 
an overkill, since it is rather complex and heavy-footed and actually 
has significant gaps in some media control areas.  
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Of course, posing the question this way would 
re-focus our discussion from the question of where a VoiceXML 
Interpreter belongs, on the media server or app server, to which packages in the 
media control protocol should be mandatory and which ones could be 
optional.  Maybe this is better way to go forward from 
here.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Regards,
<FONT face=Arial 
color=#0000ff size=2>Gene

From: Mark Scott [mailto:[email-masked]] 
Sent: Tuesday, February 07, 2006 1:19 AMTo: Dave Burke; 
Shtirmer, Gene; McGlashan, Scott; Chris Boulton; 
[email-masked]: RE: [mediactrl] SIP 
Control Framework and IVR Package

<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This has certainly been 
a very interesting E-mail thread to read through.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As I think Dave’s 
message implies, we’re really dealing with two separate issues – (1) what the 
appropriate logical architecture is for delivering VoiceXML/CCXML services in 
NGN/IMS architectures, and (2) how do we draw boxes labeled “application server” 
and “media server” around the elements of those architectures, and put labels 
like “Mp” and “Mr”.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Gene’s diagram from 
Saturday was useful to me in that it delineated VoiceXML/CCXML interpretation 
and processing from the media processing resources used to realize those 
applications.  This is a model that we strongly believe in; our view is 
that the companies and technologies best suited to building “soft or hard DSP” 
functionality and associated packaging are very different from the companies 
that are best at VoiceXML/CCXML interpreter technology.  Furthermore, the 
ideal computing platforms for “hard DSP” and for HTTP/XML/ECMAScript-centric 
languages like VoiceXML/CCXML are inherently different – which is likely why 
embedded web servers don’t handle the majority of online transactions 
today.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As an industry, we have 
certainly demonstrated that these are not hard lines; many hardware-centric 
media server companies have put VoiceXML implementations on their products which 
work fine (as long as it’s VoiceXML 1.0), just as a number of VoiceXML platform 
companies have embedded lightweight, software-based media servers that work fine 
too (as long as it’s G.711).  I’m exaggerating somewhat, but I think that a 
line drawn with DOM-enabled VoiceXML 2.1 + speech on one side, and high-density 
complex codec transcoding on the other is a fairly clear and straight 
line.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Getting back to the 
original two issues, Scott’s statement that he agrees with separation of 
VoiceXML/CCXML from low-level media operations, coupled with Gene’s diagram 
showing this (albeit with somewhat different boxes) implies to me that we 
collectively seem to agree on (1) – though not without a few subtle nuances – 
but not on (2).
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Our view on (2) is that 
with the exception of H.248 for Mp, and the absence of any consideration of 
VoiceXML in current specifications, the IMS architecture with the separation of 
MRFC and MRFP elements is a good one.  Notionally, MRFP seems to correspond 
quite clearly to “Soft or Hard DSPs” with some low-level interface protocol; 
MRFC seems to match the nature of a VoiceXML interpreter quite well.  This 
seems particularly true to us when you consider additional speech resources such 
as ASR servers and TTS servers, which are in essence additional kinds of 
MRFPs.  It seems logically sound for an MRFC (VoiceXML) to orchestrate a 
heterogeneous collection of MRFP resources in the execution of a VoiceXML 
page.  Indeed, when you consider the operation of speech recognition or 
speech synthesis, the notion of H.248 as the sole protocol for interacting with 
the MRFP becomes increasingly problematic – as it seems beyond doubt that 
MRCPv1/2 will be the protocol of choice for interacting with ASR, TTS, SI/SV, 
and other such services at least for the near 
future.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">While the apparent 
firmness of H.248 as the Mp protocol unfortunately seems to prevent the IMS 
MRFC/MRFP separation from being applied exactly as it is described here, it is 
our belief that the separation describes above will ultimately prove to be the 
correct one, regardless of where exactly the lines are drawn.  But is it 
really a deal-breaker if the best IMS MRF implementations are distributed 
solutions of multiple elements that co-ordinate using standards-based protocols 
like MSML/MSCML/MSCP/MRCPv2?
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In terms of where we’d 
draw various lines, in our view, the nature of the interaction between VoiceXML 
and the resources it uses make VoiceXML existing purely at an application server 
level somewhat problematic.  This might work reasonably if VoiceXML could 
be implemented using a straightforward set of primitives exposed via some 
fine-grained M* protocol, but it cannot use this exclusively if it also 
incorporates speech processing via MRCPv1/2 – as we believe many compelling 
applications will.  Proxying MRCPv1/2 via the media server doesn’t seem 
like a particularly attractive option.  <SPAN 
class=403033919-09022006><FONT 
color=#0000ff> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN 
class=403033919-09022006>[Gene Shtirmer]  I would not 
necessarily accept the notion that "proxying MRCP via the media server" is 
never an attractive option.  The MOML spec does have speech primitives 
defined for example (via an optional speech package) and I see nothing 
wrong with, in some cases, putting an MRCP client in the MSML/MOML media 
server.  The application server, whether driven by the VoiceXML script or a 
service script built using, for example, Ubiquity's ACE, could, in turn, control 
the MSML/MOML media server, which, in turn, would pull in speech resources via 
MRCP, if they do not reside on the media server proper.  As long as the 
barge-in event is handled at the MRCP client level, i.e. on the media server, 
and does not have to propagate up to the application server for TTS to be 
interrupted, the barge-in response time would not suffer from this 
"proxying".
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">If a VoiceXML 
“application server” was in fact doing complex low-level control of a media 
server, while simultaneously orchestrating similarly low-level MRCPv1/2 based 
control of both speech recognition and speech synthesis resources, the coupling 
between these elements would likely be such that we’d essentially wind up 
arriving in the camp that I think we’re trying to avoid – media servers being 
“built into” application servers.  The sheer amount of messaging and 
interaction in such an ASR/TTS-enabled case would certainly prevent the 
application servers from living outside the core network, as Scott alludes 
to.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN 
class=403033919-09022006>[Gene Shtirmer] I agree that the outcome 
you just described is not a desirable one.  If the application server has 
both MSML/MOML client and MRCP client, it most likely is not a good candidate 
for moving outside the core network.  But, then, in that case I would 
rely on MOML to MRCP conversion in the media server, to abstract the app 
server from having to do the speech server 
brokering.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Another key reason that 
we see VoiceXML as an application server being challenging is that this will 
invariably give the impression that people are intended to express application 
logic in VoiceXML, and that it is an alternative kind of application 
server.  What may be less clear is that chains of application servers are 
quite permissible (i.e. a VoiceXML AS is not a substitute for other kinds of 
application servers) – and that in fact, the services offered by VoiceXML are 
quite desirable to application servers.  It’s one thing for an application 
server to make use of some SIP-based protocol to have a media server play a 
prompt.  When that application server tries to play synthesized speech 
while collecting input using both DTMF and ASR simultaneously and also allowing 
mixed initiative to fill multiple slots with a single utterance, VoiceXML is 
going to start looking like a very attractive alternative to directly 
controlling multiple media processing elements.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This view of VoiceXML 
as a service that is used primarily by application servers, and the need for a 
protocol that supports this effectively by building further semantics beyond 
those in NETANN, is the primary motivation behind our participation in 
draft-burke-vxml-00.  This isn’t inconsistent at all in our minds with a 
VoiceXML implementation offering draft-burke-vxml-00 on one interface, but using 
lower-level M* (or other) protocols in addition to MRCP on another to control 
underlying resources.  In fact, we’ve done and are continuing to do exactly 
this with some of our partners.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I’m hopeful that the 
above is useful in some way beyond being sufficiently long winded so as to 
increase quarterly revenues for the storage companies.  I do think the 
issues we’re discussing here are particularly crucial, but I’m also optimistic 
that our views differ mostly in nomenclature as opposed to 
intent.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regards,
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Mark.
<SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> 
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; 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 Dave Burke<SPAN 
style="FONT-WEIGHT: bold">Sent: Monday, February 06, 2006 5:38 
AMTo: Shtirmer, Gene; 
McGlashan, Scott; Chris Boulton; 
[email-masked]<SPAN 
style="FONT-WEIGHT: bold">Subject: Re: [mediactrl] SIP Control 
Framework and IVR Package
<SPAN 
style="FONT-SIZE: 12pt"> 

<SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Interesting conversation. 

<SPAN 
style="FONT-SIZE: 12pt"> 

<SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The crux of the problem is, as Scott 
said, "What is a media server?". I see both viewpoints though I weigh in on the 
VoiceXML-enabled MRF (and of course my company's product line at least partly 
influences that decision). 

<SPAN 
style="FONT-SIZE: 12pt"> 

<SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Are we expecting to address all of 
the following: (1) What is a media server?, (2) How can we fix IMS viz-a-viz 
media server architecture?, (3) Standardise a "good" media server control 
protocol? 

<SPAN 
style="FONT-SIZE: 12pt"> 

<SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">While "IP Mobile Billing System 
(IMBS)", oops - I meant IP Multimedia Subsystem (IMS), is an important 
architecture,  we ought to consider standardising a protocol that 
while applicable to IMS, is also suitable for other architectures. Now, I know 
there was little support for this but the idea of packages/profiles still seems 
like a reasonable solution - e.g. a package for low-level stuff, a package for 
dialog, a package for conferencing. Different architectures will use different 
packages. This flexibility will allow some freedom (and maintain the protocol's 
applicability) in IMS architectures as it inevitably 
evolves.

<SPAN 
style="FONT-SIZE: 12pt"> 

<SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Dave
<BLOCKQUOTE 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: black 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
  
  <SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">----- Original Message ----- 

  <FONT face=Arial 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial">From:<FONT 
  face=Arial size=2> <A 
  title=[email-masked] href="mailto:[email-masked]">Shtirmer, 
  Gene 
  
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial">To:<FONT 
  face=Arial size=2> <A 
  title=[email-masked] href="mailto:[email-masked]">McGlashan, 
  Scott ; <A title=[email-masked] 
  href="mailto:[email-masked]">Chris Boulton ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">[email-masked] 

  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial">Sent:<FONT 
  face=Arial size=2> Monday, 
  February 06, 2006 4:51 AM
  
  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial">Subject:<FONT 
  face=Arial size=2> RE: 
  [mediactrl] SIP Control Framework and IVR 
  Package
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Scott, thanks again 
  for the great discussion.  I've responded to your latest arguments in 
  line, but I think at this point we understand each of our respective 
  positions rather well.  Let's continue the 
  dialog.  I'd also love to hear what others in this group think 
  about these issues.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Regards,
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Gene
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <FONT 
  face="Times New Roman" size=3>

  <FONT face=Tahoma 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:<FONT 
  face=Tahoma size=2> 
  McGlashan, Scott [mailto:[email-masked]] <SPAN 
  style="FONT-WEIGHT: bold">Sent: Sunday, February 05, 2006 2:57 
  PMTo: Shtirmer, Gene; Chris 
  Boulton; <A 
  href="mailto:[email-masked]">[email-masked]<SPAN 
  style="FONT-WEIGHT: bold">Subject: RE: [mediactrl] SIP Control 
  Framework and IVR Package
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Good discussion Gene. 
  See my points inline.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">thanks
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Scott
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <FONT 
  face="Times New Roman" size=3>

  <FONT face=Tahoma 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:<FONT 
  face=Tahoma size=2> 
  Shtirmer, Gene [mailto:[email-masked]] <SPAN 
  style="FONT-WEIGHT: bold">Sent: Sunday, February 05, 2006 
  04:49To: McGlashan, Scott; 
  Chris Boulton; [email-masked]<SPAN 
  style="FONT-WEIGHT: bold">Subject: RE: [mediactrl] SIP Control 
  Framework and IVR Package
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Scott, 
  thanks!!!  We are quickly getting to the core of the issues.  I've 
  addressed your questions/comments inline...
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Best 
  Regards,
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Gene
  <FONT 
  face="Times New Roman" size=3>

  <FONT face=Tahoma 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:<FONT 
  face=Tahoma size=2> 
  McGlashan, Scott [mailto:[email-masked]] <SPAN 
  style="FONT-WEIGHT: bold">Sent: Saturday, February 04, 2006 6:12 
  PMTo: Shtirmer, Gene; Chris 
  Boulton; [email-masked]<SPAN 
  style="FONT-WEIGHT: bold">Subject: RE: [mediactrl] SIP Control 
  Framework and IVR Package
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi 
  Gene,
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Thanks for your 
  detailed response - apologies if I mis-understood your 
  position.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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).<FONT face=Arial 
  color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">[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.<SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: Arial">[Scott 
  McGlashan] Reasonable intent but I still don't accept that a VoiceXML 
  component is part of the application layer - for me it is part of 
  the media server, providing a standard for interactive media 
  dialogs.<SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: red; FONT-FAMILY: Arial">[Gene Shtirmer] 
  I believe we are reaching a stalemate on this point.  I'd like to 
  see others chime in here...
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: Arial">The HTTP protocol 
  also needs to be supported by media servers if, as most do, they allow media 
  resources to be fetched using HTTP. <FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: red; FONT-FAMILY: Arial">[Gene Shtirmer] Agreed 
  - media servers typically do need to have an HTTP client and possibly an 
  RTSP client, but that's not the issue in my view.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: Arial">Nor is HTTP necessary 
  for VoiceXML scripts: M* specs allow VoiceXML to be transported inline over 
  SIP/dedicated control channel. However, at the heart of this is 'What is 
  a Media Server?". Difficult to tackle head-on, but the 
  requirements spec is making some progress on the nature of the media 
  control protocol <A 
  href="http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.txt.%20">http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.txt. 
  (to be updated with changes discussed at the <st1:City 
  w:st="on">Vancouver meeting. 
  Martin is about to update the document real soon now!). We still need to 
  address requirements on how IVR dialogs are specified - or better: whatever 
  the format, the requirements they must satisfy.<FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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. 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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, 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">MSCP: <dialogstart 
  type="application/vxml+xml" src=""http://server.example.com/scripts/foo.vxml">http://server.example.com/scripts/foo.vxml"/>
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">MSML: 
  <dialogstart type="application/vxml+xml" src=""http://server.example.com/scripts/foo.vxml">http://server.example.com/scripts/foo.vxml"/>
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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. <FONT 
  face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">  
   
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">[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.  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">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.<FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: Arial">[Scott 
  McGlashan] I certainly agree that we should take a critical look at 
  layers, functional entities, protocols, etc. One of the things l see is that 
  the use of VoiceXML to specify interactive media dialogs is 'shared ground' 
  for many media servers, and that the motivation is, in part, driven by 
  customers and application developers wanting to use an existing IVR standard 
  where its fulfils their requirements.  <FONT 
  face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: red; FONT-FAMILY: Arial">[Gene Shtirmer]  
  This is exactly where we differ - what you call media server with VoiceXML 
  interface, I call a media server plus an application server with VoiceXML (and 
  CCXML) interpreter(s).  My goal is to define an interface between this 
  app server and the media server.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">[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.<SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: Arial">[Scott 
  McGlashan] In a later version of IMS, the architecture may change. 
  Right now, I need to deal with what is currently specified in 3GPP - 
  and that includes a low-level Mp interface based on H.248 which I 
  don't think is going to change in the short term.  I believe we have 
  the opportunity to align the Mr interface of the MRF towards an IETF media 
  control language which is service-oriented rather than low-level, and I see 
  VoiceXML playing a role defining IVR dialogs within this language. I'm 
  certainly open to later revision of the Mp interface along the lines of a 
  low-level XML language over a dedicated control 
  channel. <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">[<SPAN 
  style="COLOR: red">Gene Shtirmer] Just because it's currently part of 3GPP IMS 
  definition, doesn't mean we should embrace this architecture with all its 
  faults "word-for-word".  By backing into existing architectural 
  mistakes we will only exacerbate the problems, that many in this industry 
  have voiced, for example, wrt H.248 protocol's choice at the Mp 
  interface.   Mp interface is optional anyway, as the MRF does not 
  have to be decomposed per the IMS spec.  After all, even though based on 
  your arguments I should infer that both OCMP Base and OCMP BRE are part of 
  media server, you do not use H.248 between OCMP Base and OCMP 
  BRE.  At the same time, the Mr interface is open to 
  interpretation for the most part.  Let's capitalize on this fact and 
  do what makes sense.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">[Gene Shtirmer] 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">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.
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">thanks
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Scott
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <FONT 
  face="Times New Roman" size=3>

  <FONT face=Tahoma 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:<FONT 
  face=Tahoma size=2> 
  Shtirmer, Gene [mailto:[email-masked]] <SPAN 
  style="FONT-WEIGHT: bold">Sent: Saturday, February 04, 2006 
  19:39To: McGlashan, Scott; 
  Chris Boulton; [email-masked]<SPAN 
  style="FONT-WEIGHT: bold">Subject: RE: [mediactrl] SIP Control 
  Framework and IVR Package
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.  
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">So, the model I 
  am using is as follows (please also see the simplified diagram 
  below):
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.  
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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".  
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please see a few 
  additional comments inline.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Regards,
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Gene.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><IMG id=_x0000_i1029 
  height=593 src="jpg6tQUc7jvp5.jpg" width=800 
  border=0>
  <FONT 
  face="Times New Roman" size=3>

  <FONT face=Tahoma 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:<FONT 
  face=Tahoma size=2> 
  McGlashan, Scott [mailto:[email-masked]] <SPAN 
  style="FONT-WEIGHT: bold">Sent: Saturday, February 04, 2006 11:31 
  AMTo: Shtirmer, Gene; Chris 
  Boulton; [email-masked]<SPAN 
  style="FONT-WEIGHT: bold">Subject: RE: [mediactrl] SIP Control 
  Framework and IVR Package
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi 
  Gene,
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">thanks for your 
  comments. 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">[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.   
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">[Gene 
  Shtirmer]  I will defer to authors of the MSML syntax to 
  comment on this point. 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">[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): 
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">MSCP: "IVR dialogs 
  can be specified in VoiceXML."
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">MSCML: "for complex 
  IVR it may be more appropriate to employ a full IVR markup language such 
  as VoiceXML"
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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." 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">netann: "dialog 
  service takes a parameter, voicexml=, indicating the URI of the VoiceXML 
  script to   execute."
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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. 
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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: 
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><dialogstart 
  src="">
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">  
  <namelist>
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">   
  <name="iterations" value="2"/>
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">   
  <name="timeout" value="5000ms"/>
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> </namelist>
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"></dialogstart>
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">where the parameter 
  set is similar to those used in H.248.7 IVR packages, MSCML, MOML, 
  etc. 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">[3]  <FONT 
  face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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). 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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. 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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. 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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. 
   
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">[Gene Shtirmer] I 
  don't envision TDM connections being in scope of a media server.  That's 
  a media gateway function.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">[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. 
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">thanks
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Scott
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <FONT 
  face="Times New Roman" size=3>

  <FONT face=Tahoma 
  size=2><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 Shtirmer, Gene<SPAN 
  style="FONT-WEIGHT: bold">Sent: Friday, February 03, 2006 
  23:29To: Chris Boulton; 
  [email-masked]<SPAN 
  style="FONT-WEIGHT: bold">Subject: RE: [mediactrl] SIP Control 
  Framework and IVR Package
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Regards,
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Gene 
  Shtirmer
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  <FONT 
  face="Times New Roman" size=3>

  <FONT face=Tahoma 
  size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:<FONT 
  face=Tahoma size=2> Chris 
  Boulton [mailto:[email-masked]] <SPAN 
  style="FONT-WEIGHT: bold">Sent: Friday, December 23, 2005 7:23 
  AMTo: Shtirmer, 
  GeneSubject: FW: [mediactrl] 
  style="FONT-WEIGHT: bold">Sent: 23 December 2005 11:06<SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi 
  All,
  technology contained within the two 
  specifications:-
  de-coupled control architectures between network 
  entities.
  archives, they will be available from the following 
  links:-
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The 
  Authors.

---

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

No.

See the other messages for why this model is wrong Computer Science (which we directly care about) and does not work for the IMS (which we indirectly might be influenced by).

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shtirmer, Gene
Sent: Saturday, February 04, 2006 1:39 PM
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: "Burger, Eric" <[email-masked]>
Date: Tue, 14 Feb 2006 18:23:26 GMT

I would offer one review RFC 4240.

VoiceXML, simple announcement services, and enhanced conference control already have a standard mechanism for invocation and transfer between modes.  The work is done, complete, published, and fielded for five years.

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of McGlashan, Scott
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). 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. 
 
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.  
 
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.  

 

 
 
Regards,
Gene.

 

 

 

 

 

 

thanks
 
Scott

 
 
Regards,
Gene Shtirmer

-----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.

---

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

I would NOT be happy with MSML/MOML, but that is another story for another day :)

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shtirmer, Gene
Sent: Monday, February 06, 2006 11:08 AM
To: Dave Burke; McGlashan, Scott; Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package

Dave, great to hear from you.  I am out of breath after sparring with Scott all weekend - fantastic discussion, Scott!
 
Your suggestion regarding the packages/modules approach is a constructive one.  However, there is a danger that we would not really be consolidating the different types of protocols - the protocol soup is what I called it earlier.  We'd simply create as many packages as there are opposing views in this group.  How would that help our cause in 3GPP, for example.  Which package would we push, or would you be ok with the MSML/MOML type package specifically for the Mr IMS interface?
 
Rgds,
gene

________________________________________
From: Dave Burke [mailto:[email-masked]] 
Sent: Monday, February 06, 2006 5:38 AM
To: Shtirmer, Gene; McGlashan, Scott; Chris Boulton; [email-masked]
Subject: Re: [mediactrl] SIP Control Framework and IVR Package
Interesting conversation. 
 
The crux of the problem is, as Scott said, "What is a media server?". I see both viewpoints though I weigh in on the VoiceXML-enabled MRF (and of course my company's product line at least partly influences that decision). 
 
Are we expecting to address all of the following: (1) What is a media server?, (2) How can we fix IMS viz-a-viz media server architecture?, (3) Standardise a "good" media server control protocol? 
 
While "IP Mobile Billing System (IMBS)", oops - I meant IP Multimedia Subsystem (IMS), is an important architecture,  we ought to consider standardising a protocol that while applicable to IMS, is also suitable for other architectures. Now, I know there was little support for this but the idea of packages/profiles still seems like a reasonable solution - e.g. a package for low-level stuff, a package for dialog, a package for conferencing. Different architectures will use different packages. This flexibility will allow some freedom (and maintain the protocol's applicability) in IMS architectures as it inevitably evolves.
 
Dave
----- Original Message ----- 
From: Shtirmer, Gene 
To: McGlashan, Scott ; Chris Boulton ; [email-masked] 
Sent: Monday, February 06, 2006 4:51 AM
Subject: RE: [mediactrl] SIP Control Framework and IVR Package

Scott, thanks again for the great discussion.  I've responded to your latest arguments in line, but I think at this point we understand each of our respective positions rather well.  Let's continue the dialog.  I'd also love to hear what others in this group think about these issues.
 
Regards,
Gene

________________________________________
From: McGlashan, Scott [mailto:[email-masked]] 
Sent: Sunday, February 05, 2006 2:57 PM
To: Shtirmer, Gene; Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package
Good discussion Gene. See my points inline.
 
thanks
 
Scott

________________________________________
From: Shtirmer, Gene [mailto:[email-masked]] 
Sent: Sunday, February 05, 2006 04:49
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

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. 
 
[Scott McGlashan] Reasonable intent but I still don't accept that a VoiceXML component is part of the application layer - for me it is part of the media server, providing a standard for interactive media dialogs. 
 
[Gene Shtirmer] I believe we are reaching a stalemate on this point.  I'd like to see others chime in here...
 
The HTTP protocol also needs to be supported by media servers if, as most do, they allow media resources to be fetched using HTTP.  
 
[Gene Shtirmer] Agreed - media servers typically do need to have an HTTP client and possibly an RTSP client, but that's not the issue in my view.
 
Nor is HTTP necessary for VoiceXML scripts: M* specs allow VoiceXML to be transported inline over SIP/dedicated control channel. However, at the heart of this is 'What is a Media Server?". Difficult to tackle head-on, but the requirements spec is making some progress on the nature of the media control protocol http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00txt. (to be updated with changes discussed at the Vancouver meeting. Martin is about to update the document real soon now!). We still need to address requirements on how IVR dialogs are specified - or better: whatever the format, the requirements they must satisfy. 
 
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. 

 
 
[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. 
 
[Scott McGlashan] I certainly agree that we should take a critical look at layers, functional entities, protocols, etc. One of the things l see is that the use of VoiceXML to specify interactive media dialogs is 'shared ground' for many media servers, and that the motivation is, in part, driven by customers and application developers wanting to use an existing IVR standard where its fulfils their requirements.   
 
[Gene Shtirmer]  This is exactly where we differ - what you call media server with VoiceXML interface, I call a media server plus an application server with VoiceXML (and CCXML) interpreter(s).  My goal is to define an interface between this app server and the media server.

[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. 
 
[Scott McGlashan] In a later version of IMS, the architecture may change. Right now, I need to deal with what is currently specified in 3GPP - and that includes a low-level Mp interface based on H.248 which I don't think is going to change in the short term.  I believe we have the opportunity to align the Mr interface of the MRF towards an IETF media control language which is service-oriented rather than low-level, and I see VoiceXML playing a role defining IVR dialogs within this language. I'm certainly open to later revision of the Mp interface along the lines of a low-level XML language over a dedicated control channel.  
 
[Gene Shtirmer] Just because it's currently part of 3GPP IMS definition, doesn't mean we should embrace this architecture with all its faults "word-for-word".  By backing into existing architectural mistakes we will only exacerbate the problems, that many in this industry have voiced, for example, wrt H.248 protocol's choice at the Mp interface.   Mp interface is optional anyway, as the MRF does not have to be decomposed per the IMS spec.  After all, even though based on your arguments I should infer that both OCMP Base and OCMP BRE are part of media server, you do not use H.248 between OCMP Base and OCMP BRE.  At the same time, the Mr interface is open to interpretation for the most part.  Let's capitalize on this fact and do what makes sense.
 
[Gene Shtirmer] 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

 

 

Regards,
Gene.

 

 

 

 

 

 

thanks
 
Scott

 
 
Regards,
Gene Shtirmer

-----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.

---

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

If you like packages, please see RFC 3235.  That has a well defined package mechanism.

PLEASE remember why the IETF protocol suite survives the test of time.  We do NOT create one kitchen-sink protocol (with lots of packages) that does everything.  Rather, we build a set of complementary, simple, interoperable protocols that work together to do everything.

We have SIP-mediated VoiceXML.  See RFC 4240 and draft-burke-voicexml

We have SIP-mediated enhanced conferencing and basic IVR.  See RFC 4240 and MSCML (or others).

Why do we need something that does "everything"?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Burke

 

Dave
----- Original Message ----- 
From: Shtirmer, Gene 
To: McGlashan, Scott ; Chris Boulton ; [email-masked] 
Sent: Monday, February 06, 2006 4:51 AM
Subject: RE: [mediactrl] SIP Control Framework and IVR Package

Regards,
Gene

thanks
 
Scott

Best Regards,
Gene

 

 

 

 

 

 

 

thanks
 
Scott

 

 

Regards,
Gene.

 

 

 

 

 

 

thanks
 
Scott

 
 
Regards,
Gene Shtirmer

-----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.