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

From: "Shtirmer, Gene" <[email-masked]>
Date: Mon, 6 Feb 2006 04:43:33 GMT

<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; 
[email-masked]: RE: [mediactrl] SIP 
Control Framework and IVR Package

<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 
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> 
<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> 
<SPAN 
class=712062001-05022006><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.<FONT 
color=#0000ff> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006><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=712062001-05022006><SPAN 
class=487380618-05022006><SPAN 
class=994430920-05022006> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006>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=712062001-05022006><SPAN 
class=487380618-05022006><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=712062001-05022006><SPAN 
class=487380618-05022006><SPAN 
class=994430920-05022006> 
<SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006>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 
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=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=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.  <FONT 
color=#0000ff> 
<SPAN 
class=712062001-05022006><SPAN 
class=518165420-04022006><FONT 
color=#008080><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> 
<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=518165420-04022006><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. <FONT 
color=#0000ff> 
<SPAN 
class=712062001-05022006><SPAN 
class=518165420-04022006><SPAN 
class=487380618-05022006><SPAN 
class=712062001-05022006><SPAN 
class=487380618-05022006><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=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=994430920-05022006>[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 
[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 
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="jpgNGDFkz6eyF.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 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: [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 
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: "Adnan Saleem" <[email-masked]>
Date: Mon, 6 Feb 2006 09:04:55 GMT

Please see our 
review comments on these two IDs <SPAN 
class=886221106-06022006>(control-framework-00 and 
ivr-control-package-00).
<FONT face=Arial 
size=2> 
 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial 
size=3>draft-boulton-sip-control-framework-00
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>General Comments:

  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    In general we agree with the approach taken in 
  this ID to allow
  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    media control interface to be transport 
  independent. This ID does
  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    seem to support this framework effectively for 
  TCP, however, there
  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    are a few issues we'd like to point out or 
  request clarification with
  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    respect to SIP. These items are 
  identified below.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>1. The control framework focuses on establishing a control 
channel
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    over TCP, however, it does not seem to describe if 
its the intention
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    of this specification to allow SIP to be 
negotiated as the transport as well.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    Ie. using the existing SIP methods for exchange of 
control and events
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    to and from the media server. 

<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>2. This ID defines how to create the intial control channel (tcp), 
and
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    subsequent transaction exchanges are also defined 
above tcp,
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    eg: control cmds, responses, reports, etc. 
However, support for an
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    interface between client and server based on SIP, 
where re-use of
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    of many of the existing SIP methods (such as 
options, subscribe, and
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    notify, etc) is also required. It seems that 
over time, this ID may have
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    to re-invent the mechanisms already available in 
SIP. For this reason
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    alone, allowing SIP as negotiated transport (in 
addition to tcp) should
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    also be supported.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>3. Server capabilities discovery (packages and revisions) requires 

<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    further discussion and updates. Hopefully future 
revisions of this
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    ID can elaborate on this 
aspect.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>4. The ID requires use of SIP extensions (requires header and 
additional
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    SDP parameters), however a SIP service context 
could also be used
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    to establish a control channel. This approach may 
be simpler
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    not requiring sip/sdp extensions. Was this 
approach taken into
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    consideration ?
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>5. Client/Server interfaces may be required in both directions or in 
just a
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">    single 
direction<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">, 
depending <SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">on 
the nature and requirements of the packages 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">    
which use this control <SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">framework. 
The control framework appears not to
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    support such a model of transport negotiation. 
Perhaps I've mis-read
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    this, please clarify.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>(detailed section by section comments on the control framework ID 

<SPAN 
class=886221106-06022006><SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> are 
included <SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">at 
the end of this email)
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> <SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial 
size=3>draft-boulton-ivr-control-package-00
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>General Comments:

  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    The IVR package ID, in its reliance on VoiceXML 
  and parts of CCXML, is
  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    not suitable for media server ivr controls, for 
  several reasons, many of
  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    which have already been discussed in earlier 
  threads on this list.
  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    We'd like to reiterate some of these issues in 
  our review comments
  <SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
  face=Arial>    as well.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>1. The ivr-control-packge (VXML) is very well suited for application 
logic and
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    is not well suited towards providing general 
purpose and granular enough 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    media processing 
controls.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>2. VXML is also quite burdensome, from a processing perspective. Most 
of
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    the application processing logic would still 
reside within the application server.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    So having to carry the burden of VXML but only 
using some small parts of
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    of the language for real media processing does not 
seem to fit the model
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">    requiring 
clear separation between application servers and media 
servers<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>3. The media processing interfaces for IVR and Conferencing have 
already been 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">    
well specified by the <SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">M* 
specifications, so replacing these with VXML, or 
even
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    sub-sections of VXML and CCXML, does not bring any 
new value.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>4. The flexibility in invoking vxml dialogs is also supported by the 
M* specifications,
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    (ie: using application/vxml+xml) where VXML may be 
required for some reason.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">    
However, this does not <SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">imply 
that the standard interface to media server
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    is VXML; ie it's an exception (for sake of 
flexibility) rather than the rule.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>5. The event exchange mechanism (via namelists etc) in VXML is 
between the
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    VXML application and the HTTP servers. However, 
using the ivr control package
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    as media server control language, the event 
exchange and control flow mechanism
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>    is now also between the media server and 
application server, in addition to with
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">    
the HTTP server. This complicates and blurs the architecture <SPAN 
class=886221106-06022006><SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">unnecessarily.
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>Thanks
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>Adnan Saleem
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial> 
<SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>P.S. Specific review comments/questions 
on <SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
color=#000000>draft-boulton-sip-control-framework-00
<SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">
<FONT 
color=#000000>Specific comments<SPAN 
class=886221106-06022006> (mostly questions and 
suggestions), by section:<?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" />
<FONT 
color=#000000> 
<FONT 
color=#000000>Section 3.
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. Client informs 
server of package(s) it supports,<SPAN 
class=886221106-06022006> <SPAN 
lang=EN-US><FONT 
face=Arial>(<example-package>),
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
however, in some cases the server may need to supply supported 
<FONT 
face=Arial>packages
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
to client, and then client selects one. Perhaps both 
mechanisms
<FONT 
face=Arial><SPAN 
style="mso-spacerun: yes">         
should be supported, similar to sdp offer/answer model<SPAN 
class=886221106-06022006> ?
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      2. What happens 
if server does not support supplied 
example-package,
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
ie; is the connection still established and the pacakge can 
be
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
further re-negotiated ? Can packages be added anytime 
during
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
lifetime of connection ?
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      3. Can multiple 
packages be requested by client? I assume 
so,
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
and this mechanism should be 
described.
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      5. A consistent 
package naming scheme along with revisioning 
should
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
be described.
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      4. Is the control 
channel limited to the 'negotiated' package, 
ie
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
if over the established control channel, a request is 
issued
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
for an unstated package which the server supports, then 
should
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
the server reject such requests<FONT 
color=#0000ff> <FONT 
color=#000000>? 
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      5. Q: would it 
not be possible to avoid mandating use of 
SDP.
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
Ie. connection established could be done with or without 
SDP,
<FONT 
face=Arial><SPAN 
style="mso-spacerun: yes">         
by using additional header fields of INV. Avoiding<SPAN 
class=886221106-06022006> a forced SDP
<FONT 
face=Arial><SPAN 
style="mso-spacerun: yes">         <SPAN 
class=886221106-06022006>use would make the connection 
establishment transaction
<FONT 
face=Arial><SPAN 
style="mso-spacerun: yes">         
flow simpler.
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      6. This section 
describes behaviour of client when it receives 
the
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
200 OK from server, but it does not describe the 
expected
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
behaviour when the server receives INV or other SIP 
methods
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
over this SIP dialog.
<FONT 
color=#000000> 
<FONT 
color=#000000>Section 4.
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. Although this 
section is left for future update, using P2P
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
type mechanism might be useful to consider for 
locating
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
external servers
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      2. Also, location 
of external servers should be based on <SPAN 
lang=EN-US><FONT 
face=Arial>capabilities
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
of external servers; ie: locate based on what packages 
are
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
required by client and supported by servers (including 
package
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
version ids).
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">      3. Load related 
server location would be useful also. Ie. 
servers
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
could report load index, and then client could select one 
with
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
lowest current load index.
<FONT 
color=#000000> 
<FONT 
color=#000000>Section 5.
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. <port> 
field indicates which port the client is willing 
to
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
accept a connection, but it's not clear why a "valid port 
range"
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
is required when client does not wish to accept 
incomming
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
connection and why this is a "range" rather then a 
specific
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
port number.<SPAN 
class=886221106-06022006> <SPAN 
class=886221106-06022006>(I guess the 
range could be <FONT 
color=#000000>limited to single 
item)
<FONT 
face=Arial> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      2. Some control 
packages would require the client to accept 
incoming
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
requests or events, while other control packages may 
not.
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
So if the client does not provide appropriate <port> when 
a
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
control package requires it, then there should be 
mechanism
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
to resolve this condition or reject the connection 
setup.
<FONT 
color=#000000> 
<FONT 
color=#000000>Section 5.1
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. not clear what 
is being stated in this section. should be
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
reworded.
<FONT 
color=#000000> 
<FONT 
color=#000000>Section 6.
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. A mechanism 
for defining and registering unique package 
tokens
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
should be described
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      2. Revisions or 
versions of control packages should be taken 
into
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
consideration when client and server are discovering 
package
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
support by the server
<FONT 
color=#000000> 
<FONT 
color=#000000>Section 7.1
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. Not clear on 
what are "all required manditory and 
optional
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
control framework headers" are. Clarification required 
here.
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      2. Content-type 
should be requried specifying a registered
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
MIME type
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      3. 5 sec timeout 
seems too low. Would recommend 15s.
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      4. A transaction 
timeout and retry mechanism is required on 
the
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
client side, with a sequence number to ensure 
transactions
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
are not incorrectly executed multiple times on the 
server
<FONT 
color=#000000> 
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      5. Should 
consider making a statement about transaction 
id
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
uniqueness within the client, size and 
wraparound.
<FONT 
color=#000000> 
<FONT 
color=#000000>Section 7.1.2
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. Not sure but 
is it the purpose of continuous REPORT 
messages
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
(based on server specified timeout values) to ensure 
that
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
server has not encountered an error or to keep the 
session
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
alive in absence of traffic for a long period of time 
?
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
(ie. is this mechanism for keep-alive 
control)
<FONT 
color=#000000> 
<FONT 
color=#000000>Section 7.2
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. As the editor 
note indicates, I agree that ability to 
include
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
message body in Responses is very usefull and should 
be
<FONT 
color=#000000><SPAN 
style="mso-spacerun: yes">         
included.<SPAN 
class=886221106-06022006> 
<FONT 
color=#000000>Section 9.
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. several issues 
with control packages already stated earlier
<FONT 
color=#000000> 
<FONT 
color=#000000>Remaining 
sections:
<FONT 
color=#000000><SPAN 
style="mso-tab-count: 1">      1. no comments, 
as most of them are largely empty or 
incomplete
<SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
<SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
<SPAN 
lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"> 
<SPAN lang=EN-US 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT 
face=Arial>

---

From: "Dave Burke" <[email-masked]>
Date: Mon, 6 Feb 2006 10:30:47 GMT

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 

  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="jpgdnLpOQz1jB.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