Subject: Re: [MEDIACTRL] Is "Basic IVR" the right thing to call our XMLvariant?Is it too limiting?

From: Eric Burger <[email-masked]>
Date: Tue, 01 Apr 2008 14:29:49 -0700

In my mind, the most important thing about this thread is clearly if we have
the energy to discuss what to call the basic IVR package, no one has the
energy to propose, write, drive, and shepherd a document about audit.

For that, I will do my best to come well supplied to Dublin :-)

On 3/28/08 4:05 PM, "M. Wayne Wilson" <[email-masked]> wrote:

> Chris, Dan
>  
> I also am not advocating feature creep, but was simply making the point that
> the element name <basicivr> was really just a container for a dialog.
>  
> From a future-proofing perspective, one could choose to use some type of
> container name, <dialog>, <remotedialog>,  whatever (I have no brief for a
> specific name).  At some later point in time, one might then use an attribute
> name (for example, dialogtype = "basicivr" with the currently implied
> specification as the default) and allow the WG or its successor to define some
> other perhaps richer dialog specification.
>  
> Wayne
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dan York
> Sent: Friday, March 28, 2008 2:30 PM
> To: Chris Boulton
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] Is "Basic IVR" the right thing to call our
> XMLvariant?Is it too limiting?
> 
> Chris, 
> 
>>  
>>  
>> -          Initially we really  did concentrate on true IV(oice)R  the scope
>> has slightly expanded since to  include video.
> 
> DY> That was part of my point.  We've added video, so it's a bit beyond what I
> personally think of as "IVR".
>>  
>>  
>> 
>>  
>>  
>> From a procedural  point of view the Œdocument name¹ will need to remain the
>> same as it¹s a WG  item
> 
> DY> Of course. 
> 
>>  
>>  
>> So lets offer a prize  for the participant who comes up with the most
>> appropriate/snazzy title for  the document  I¹m sure Mr Burger will sponsor
>> (There must be boxes of BEA  mugs and polo shirts lying round J).
> 
> DY> Good idea! ;-)
>>  
>>  
>> 
>>  
>>  
>> p.s. I am not sure I  agree with the feature creep comment that we will
>> replicate VXML (in another  post).  It has always been a strong sentiment of
>> the group that this  should not happen.
> 
> DY> I definitely  do not want to see feature creep.
> 
> Regards,
> Dan

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 2 Apr 2008 10:14:21 +0100

In my mind, the most important thing about this thread is clearly if we
have the energy to discuss what to call the basic IVR package, no one
has the energy to propose, write, drive, and shepherd a document about
audit.

[Chris Boulton] Yes folks - come on - this is a Work Group document now.
I plan to start rolling in the changes for the new version next week and
it is then planned for RAI expert review.  We can always punt on this
but I'm not convinced it's the best option (but it's the easiest for me
:-)).  Let's be hearing from you.

Chris.

Chris, Dan

I also am not advocating feature creep, but was simply making the point
that the element name <basicivr> was really just a container for a
dialog.

From a future-proofing perspective, one could choose to use some type of
container name, <dialog>, <remotedialog>,  whatever (I have no brief for
a specific name).  At some later point in time, one might then use an
attribute name (for example, dialogtype = "basicivr" with the currently
implied specification as the default) and allow the WG or its successor
to define some other perhaps richer dialog specification.

Wayne

  _____  

From: [email-masked] [mailto:[email-masked]]
<mailto:[email-masked]%5d>  On Behalf Of Dan York
Sent: Friday, March 28, 2008 2:30 PM
To: Chris Boulton
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Is "Basic IVR" the right thing to call our
XMLvariant?Is it too limiting?

Chris, 

-          Initially we really  did concentrate on true IV(oice)R - the
scope has slightly expanded since to  include video.

DY> That was part of my point.  We've added video, so it's a bit beyond
what I personally think of as "IVR".

From a procedural  point of view the 'document name' will need to remain
the same as it's a WG  item 

DY> Of course. 

So lets offer a prize  for the participant who comes up with the most
appropriate/snazzy title for  the document - I'm sure Mr Burger will
sponsor (There must be boxes of BEA  mugs and polo shirts lying round
:-)).

DY> Good idea! ;-)

p.s. I am not sure I  agree with the feature creep comment that we will
replicate VXML (in another  post).  It has always been a strong
sentiment of the group that this  should not happen.

Regards,
Dan

Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Dan York <[email-masked]>
Date: Wed, 2 Apr 2008 09:20:36 -0400

Chris,

On Apr 2, 2008, at 5:14 AM, Chris Boulton wrote:

>  [Chris Boulton] Yes folks – come on – this is a Work Group  
> document now.  I plan to start rolling in the changes for the new  
> version next week and it is then planned for RAI expert review.  We  
> can always punt on this but I’m not convinced it’s the best option  
> (but it’s the easiest for me J).  Let’s be hearing from you.
> Chris.

Maybe I need more caffeine this morning, but I'm not clear on what  
you are asking.  Are you asking for more people to chime in on the  
"should we call it something other than <basicivr>?"  And for people  
to come up with a better name?

Off to get some tea,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: "McGlashan, Scott" <[email-masked]>
Date: Wed, 2 Apr 2008 14:01:58 +0000

After the MediaCtrl meeting at the Philadelphia meeting, Roni, Lorenzo, Simon, Steve and myself discussed audit within the control framework document (i.e. issue 'DP12 - Need to include audit template mechanism.'). The main goal was to address Roni's concerns how an AS knows the media capabilities of an MS before the join/dialogstart command is sent. The following is my intrepretation of the discussion  (apologies for any errors) . I hope Roni;s concern is addressed by [2] below, allowing an AS to find MS media capabilites and appropriately modify if necessary the SDP of an UA INVITE before sending to the MS.

The proposal is that the framework adds the following content:

[1]  8.6 Audit: Control Package MUST specify a framework interaction which allows the client to find the entities created by the package. Eg. a conference package would enumerate  conferences and related info, IVR package enumerate dialogs, etc

[2] 8.6 Audit:  Control Package MUST specify a framework interaction which allows the client (AS) to find the media codecs which the MS supports for that package.  Eg.

AS->MS: CONTROL with payload <audit><listCodecs/></audit>

MS->AS: 200 response with payload <codecs> CODECS DESC </codecs>

We can build uopn the XCON data model definitions for exactly how codecs are described. Anyone klnows a spec which already defines codec descriptions?

[3] In appendix 16, add a media profile schema which control packages can use to describe codecs (instead of each package making up its own scheme). The conferenceid and connectionid should be added to this media profile, so there is a single schema for media information.

Looking forward to comments

thanks

Scott

Note that this proposal has nothing to do with a general audit document - this proposal is about audit capability within each package and how it relates to the MCCF as discussed at the March meeting. I would suggest that we drop the general audit document for the reasons Eric provided.

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 2 Apr 2008 15:28:17 +0100

Definitely not enough caffeine :-) - that comment was in response to
Eric:

 

It was in reference to getting the audit problem sorted.

Chris.

  _____  

From: Dan York [mailto:[email-masked]] 
Sent: 02 April 2008 14:21
To: Chris Boulton
Cc: Eric Burger; [email-masked]
Subject: Re: [MEDIACTRL] Is "Basic IVR" the right thing to call our
XMLvariant?Is it too limiting?

Chris,

 [Chris Boulton] Yes folks - come on - this is a Work Group document
now.  I plan to start rolling in the changes for the new version next
week and it is then planned for RAI expert review.  We can always punt
on this but I'm not convinced it's the best option (but it's the easiest
for me :-)).  Let's be hearing from you.

Chris.

Maybe I need more caffeine this morning, but I'm not clear on what you
are asking.  Are you asking for more people to chime in on the "should
we call it something other than <basicivr>?"  And for people to come up
with a better name?

Off to get some tea,

Dan

--

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 2 Apr 2008 17:50:32 +0300

Scott,

This looks reasonable to me. It will be good to have the base audit like
codecs in the draft [3] but it should extensible enabling specific
packages to add other parameters.

As for "Anyone knows a spec which already defines codec descriptions?"
The XCON data model. The codecs names are by their media subtype name.

Roni

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of McGlashan, Scott
Sent: Wednesday, April 02, 2008 5:02 PM
To: [email-masked]
Subject: [MEDIACTRL] Audit in media control channel framework

After the MediaCtrl meeting at the Philadelphia meeting, Roni, Lorenzo,
Simon, Steve and myself discussed audit within the control framework
document (i.e. issue 'DP12 - Need to include audit template
mechanism.'). The main goal was to address Roni's concerns how an AS
knows the media capabilities of an MS before the join/dialogstart
command is sent. The following is my intrepretation of the discussion
(apologies for any errors) . I hope Roni;s concern is addressed by [2]
below, allowing an AS to find MS media capabilites and appropriately
modify if necessary the SDP of an UA INVITE before sending to the MS. 

[1]  8.6 Audit: Control Package MUST specify a framework interaction
which allows the client to find the entities created by the package. Eg.
a conference package would enumerate  conferences and related info, IVR
package enumerate dialogs, etc

[2] 8.6 Audit:  Control Package MUST specify a framework interaction
which allows the client (AS) to find the media codecs which the MS
supports for that package.  Eg. 

We can build uopn the XCON data model definitions for exactly how codecs
are described. Anyone klnows a spec which already defines codec
descriptions? 

[3] In appendix 16, add a media profile schema which control packages
can use to describe codecs (instead of each package making up its own
scheme). The conferenceid and connectionid should be added to this media
profile, so there is a single schema for media information.  

thanks

Scott

Note that this proposal has nothing to do with a general audit document
- this proposal is about audit capability within each package and how it
relates to the MCCF as discussed at the March meeting. I would suggest
that we drop the general audit document for the reasons Eric provided.

---

From: Rahul <[email-masked]>
Date: Thu, 03 Apr 2008 20:08:53 +0530

Hi Scott,

               I have some queries and suggestion. 

1. Can we have the capability in AS where it can audit the codecs involved
in some particular conference only?

Something like: <audit><conferenceid>list of codecs</conferenceId></audit>

Though this can be accomplished by storing the negotiated SDP in AS but I
feel it will be better to have that capability built for each conference
also.

2. Can AS register for change of packages on MS so that for any change of
package info on MS, AS gets to know? (Rather than auditing always)

Regards,

Rahul

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of McGlashan, Scott
Sent: Wednesday, April 02, 2008 7:32 PM
To: [email-masked]
Subject: [MEDIACTRL] Audit in media control channel framework

After the MediaCtrl meeting at the Philadelphia meeting, Roni, Lorenzo,
Simon, Steve and myself discussed audit within the control framework
document (i.e. issue 'DP12 - Need to include audit template mechanism.').
The main goal was to address Roni's concerns how an AS knows the media
capabilities of an MS before the join/dialogstart command is sent. The
following is my intrepretation of the discussion  (apologies for any errors)
. I hope Roni;s concern is addressed by [2] below, allowing an AS to find MS
media capabilites and appropriately modify if necessary the SDP of an UA
INVITE before sending to the MS. 

[1]  8.6 Audit: Control Package MUST specify a framework interaction which
allows the client to find the entities created by the package. Eg. a
conference package would enumerate  conferences and related info, IVR
package enumerate dialogs, etc

[2] 8.6 Audit:  Control Package MUST specify a framework interaction which
allows the client (AS) to find the media codecs which the MS supports for
that package.  Eg. 

We can build uopn the XCON data model definitions for exactly how codecs are
described. Anyone klnows a spec which already defines codec descriptions? 

[3] In appendix 16, add a media profile schema which control packages can
use to describe codecs (instead of each package making up its own scheme).
The conferenceid and connectionid should be added to this media profile, so
there is a single schema for media information.  

thanks

Scott

Note that this proposal has nothing to do with a general audit document -
this proposal is about audit capability within each package and how it
relates to the MCCF as discussed at the March meeting. I would suggest that
we drop the general audit document for the reasons Eric provided.

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 7 Apr 2008 09:32:04 +0000

Hi Rahul,

see comments inline.

Scott

________________________________
From: Rahul [mailto:[email-masked]]
Sent: Thursday, April 03, 2008 16:39
To: McGlashan, Scott; [email-masked]
Subject: RE: [MEDIACTRL] Audit in media control channel framework

Hi Scott,

1. Can we have the capability in AS where it can audit the codecs involved in some particular conference only?
Something like: <audit><conferenceid>list of codecs</conferenceId></audit>

Though this can be accomplished by storing the negotiated SDP in AS but I feel it will be better to have that capability built for each conference also.

[scott] Seems reasonable. It would return the complete set of codecs used for all participants in the conference.

2. Can AS register for change of packages on MS so that for any change of package info on MS, AS gets to know? (Rather than auditing always)

[scott] Wasn't planning to do this. It can already be done using the SYNC(H) method at the framework level - initiated by AS or MS. So an MS could re-SYNC if there is a change of packages. If you want to make this mandatory, then we need to change the framework.

Regards,
Rahul

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of McGlashan, Scott
Sent: Wednesday, April 02, 2008 7:32 PM
To: [email-masked]
Subject: [MEDIACTRL] Audit in media control channel framework

thanks

Scott