Subject: [MEDIACTRL] Proposed updates on Basic IVR package

From: "McGlashan, Scott" <[email-masked]>
Date: Fri, 7 Dec 2007 13:15:33 +0000

Below are the proposed changes to the Basic IVR packages arising out of discussion on remaining issues at the main MediaCtrl meeting (2007-12-03) and the IVR Design team meeting (2007-12-04). If you have input, issues or questions on any of the points please share with the list - we welcome early feedback before the changes are incorporated into the next version.

Items [1] - [3] were discussed in the mediaCtrl meeting, others in IVR Design team meeting. Let me know if there any errors in the reported discussion.

[1] Add text clarify motivation for this package, especially how it relates to
VoiceXML (already separate proposed IVR package), and what features are out of scope.

[2] Clarify how dialogprepare and dialogstart are different, and how a prepared dialog can be started using dialogstart. NEW ISSUE: can the same prepared dialog be started multiple times? [current approach: no].

[3] <stream> element. Proposed to retain it as currently specified.

[4] Scope of media support - should video, text, etc be allowed in addition to audio? Proposal is to ensure that the package is agnostic in terms of which mediatypes/codecs need to be supported. A package implementation could support only video (or text) for input and output for example. Text will clarify (a) how media types are specified (including that additional parameter-value pairs as part of the media type definition), and (b) behavior if a specified media type is not supported by the MS.

[5] Currently, we generally don't think that additional video support needs to be added to the spec. We discussed

(a) Requesting generation of I-Frame for video recording, and a timeout for generation of the I-Frame. If I-Frame not generated, then either recording starts anyway, or an error is generated. It is clear that a MS platform may address recording from the I-Frame, but it is unclear whether there is a need for this to be visible to developers.

(b) Parameters for controlling video playback. These may be specified as part of the mediatype (e.g. RFC4181 for 3gpp files), assuming this is adequate.

We are actively soliciting input on these issue, especially other uses cases where explicit video (or text?) support in the spec may be required.

[6] Add optional recording parameters "beep" and "destination" (see description in last table of section 5.3). If a destination parameter is not specified, then the URI in a successful recording is local to the MS (i.e. temporary, transient recording) but can be referenced in a subsequent prompt. The recording URI is available until the associated connection or conference is destroyed.

[7] Custom DTMF grammar Format. Our proposal is the KPML format - basically H.248.1 DRegex format with KPML fixes. Eric will provide guidance on how to describe this format (RFC4730).

[8] promptandcollect - add 'escapechar' parameter - see last table in section 5.2.

[9] promptandcollect - 'termchar' (terminating character) is current a single character, but due to new some use cases (one SP using '**' as a terminator) we propose that termchar should now be a string (with appropriate name change!).

[10] It is proposed that the package will provide support for DTMF generation but not tone generation nor tone detection.

[11] Support for variable (dates, amounts, etc) prompts is proposed. We will look at MSCML, MSML, etc for an appropriate syntax.

[12] In addition to the 'seek' VCR control, we will also add 'volume', 'speed' and 'pause'/'resume' controls. Each will be modelled on the seek control with a parameter indicating an interval (a maximum pause interal in the case of 'pause').

[13] Syntax: it is proposed to add a 'type' attribute to identify the dialog type - so freeing the src attribute to reference external dialogs.

[14] Syntax: it is proposed to add container elements for each dialog type - this allows individual property values to be validated by an XML validator.

[15] Syntax: it is proposed to create a single <prompt> element which is re-used by each dialog type.

[16] 'speed' paramater for prompts. We propose to remove this - any objections?

Scott

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

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 16 Dec 2007 12:30:59 +0200

Hi,

I did not attend the ad-hoc due to time conflicts.

Some comments on the proposed updates are inline.

Roni Even

> -----Original Message-----

> From: McGlashan, Scott [mailto:[email-masked]]

> Sent: Friday, December 07, 2007 3:16 PM

> To: [email-masked]

> Subject: [MEDIACTRL] Proposed updates on Basic IVR package

> Below are the proposed changes to the Basic IVR packages arising out
of

> discussion on remaining issues at the main MediaCtrl meeting
(2007-12-03)

> and the IVR Design team meeting (2007-12-04). If you have input,
issues or

> questions on any of the points please share with the list - we welcome

> early feedback before the changes are incorporated into the next
version.

> Items [1] - [3] were discussed in the mediaCtrl meeting, others in IVR

> Design team meeting. Let me know if there any errors in the reported

> discussion.

[RE:] Item 4 was also discussed in the meeting (see Spencer's Summary)

> [1] Add text clarify motivation for this package, especially how it

> relates to

> VoiceXML (already separate proposed IVR package), and what features
are

> out of scope.

> [2] Clarify how dialogprepare and dialogstart are different, and how a

> prepared dialog can be started using dialogstart. NEW ISSUE: can the
same

> prepared dialog be started multiple times? [current approach: no].

> [4] Scope of media support - should video, text, etc be allowed in

> addition to audio? Proposal is to ensure that the package is agnostic
in

> terms of which mediatypes/codecs need to be supported. A package

> implementation could support only video (or text) for input and output
for

> example. Text will clarify (a) how media types are specified
(including

> that additional parameter-value pairs as part of the media type

> definition), and (b) behavior if a specified media type is not
supported

> by the MS.

[RE:] The current draft can support any media using the media attribute
in the stream element. Section 5 has some non-normative text
recommending audio only support. BTW: the request was for real-time
text!!

> [5] Currently, we generally don't think that additional video support

> needs to be added to the spec. We discussed

[RE:] I think that this should be based on the flows. Currently the text
mandate G.711 audio format support for audio and there is a need to
specify the format for the other media types.

> (a) Requesting generation of I-Frame for video recording, and a
timeout

> for generation of the I-Frame. If I-Frame not generated, then either

> recording starts anyway, or an error is generated. It is clear that a
MS

> platform may address recording from the I-Frame, but it is unclear
whether

> there is a need for this to be visible to developers.

> (b) Parameters for controlling video playback. These may be specified
as

> part of the mediatype (e.g. RFC4181 for 3gpp files), assuming this is

> adequate.

[RE:] Are you sure about RFC 4181 (Guidelines for Authors and Reviewers
of MIB Documents)

> We are actively soliciting input on these issue, especially other uses

> cases where explicit video (or text?) support in the spec may be
required.

[RE:] I am not sure what you mean by other uses ( what uses are not the
other)

> [6] Add optional recording parameters "beep" and "destination" (see

> description in last table of section 5.3). If a destination parameter
is

> not specified, then the URI in a successful recording is local to the
MS

> (i.e. temporary, transient recording) but can be referenced in a

> subsequent prompt. The recording URI is available until the associated

> connection or conference is destroyed.

> [7] Custom DTMF grammar Format. Our proposal is the KPML format -

> basically H.248.1 DRegex format with KPML fixes. Eric will provide

> guidance on how to describe this format (RFC4730).

> [8] promptandcollect - add 'escapechar' parameter - see last table in

> section 5.2.

> [9] promptandcollect - 'termchar' (terminating character) is current a

> single character, but due to new some use cases (one SP using '**' as
a

> terminator) we propose that termchar should now be a string (with

> appropriate name change!).

> [10] It is proposed that the package will provide support for DTMF

> generation but not tone generation nor tone detection.

> [11] Support for variable (dates, amounts, etc) prompts is proposed.
We

> will look at MSCML, MSML, etc for an appropriate syntax.

> [12] In addition to the 'seek' VCR control, we will also add 'volume',

> 'speed' and 'pause'/'resume' controls. Each will be modelled on the
seek

> control with a parameter indicating an interval (a maximum pause
interal

> in the case of 'pause').

[RE:] What is the use case here, I thought that the current consensus is
to use the recording only for "role call" implementation.

> [13] Syntax: it is proposed to add a 'type' attribute to identify the

> dialog type - so freeing the src attribute to reference external
dialogs.

> [14] Syntax: it is proposed to add container elements for each dialog
type

> - this allows individual property values to be validated by an XML

> validator.

> [15] Syntax: it is proposed to create a single <prompt> element which
is

> re-used by each dialog type.

> [16] 'speed' paramater for prompts. We propose to remove this - any

> objections?

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 17 Dec 2007 15:00:01 +0000

Hi Roni,

A few comments inline. Thanks for the input!

Scott

________________________________
From: Even, Roni [mailto:[email-masked]]
Sent: Sunday, December 16, 2007 11:31
To: McGlashan, Scott; [email-masked]
Subject: RE: [MEDIACTRL] Proposed updates on Basic IVR package

Hi,

Roni Even

> Below are the proposed changes to the Basic IVR packages arising out of

> discussion on remaining issues at the main MediaCtrl meeting (2007-12-03)

> and the IVR Design team meeting (2007-12-04). If you have input, issues or

> early feedback before the changes are incorporated into the next version.

[scott] Right - it was discussed in both, but in the design team meeting we looked into the details.

> VoiceXML (already separate proposed IVR package), and what features are

> prepared dialog can be started using dialogstart. NEW ISSUE: can the same

> addition to audio? Proposal is to ensure that the package is agnostic in

> implementation could support only video (or text) for input and output for

> example. Text will clarify (a) how media types are specified (including

> definition), and (b) behavior if a specified media type is not supported

> by the MS.

[RE:] The current draft can support any media using the media attribute in the stream element. Section 5 has some non-normative text recommending audio only support. BTW: the request was for real-time text!!

[scott] Does real-time text have any special requirements which aren't covered in the spec? i.e. if you play real-time text as a prompt - e.g. rtsp://example.org/media/commentary.rt<http://example.org/media/commentary.rt> - is there anything special we need to control? If you have a pointer to real-time text media and its typical uses, please forward.

> needs to be added to the spec. We discussed

[RE:] I think that this should be based on the flows. Currently the text mandate G.711 audio format support for audio and there is a need to specify the format for the other media types.

[scott] The requirement for G.711 media type will be removed so the package is agnostic to media types. The intention is not to specify any required media types.

> (a) Requesting generation of I-Frame for video recording, and a timeout

> recording starts anyway, or an error is generated. It is clear that a MS

> platform may address recording from the I-Frame, but it is unclear whether

> (b) Parameters for controlling video playback. These may be specified as

> adequate.

[RE:] Are you sure about RFC 4181 (Guidelines for Authors and Reviewers of MIB Documents)

[scott] Sorry, I meant RFC 4281 ...

> cases where explicit video (or text?) support in the spec may be required.

[RE:] I am not sure what you mean by other uses ( what uses are not the other)

[scott] Which elements or attributes - other than those provided by the current spec - might be necessary to use the package for video and/or text playback/record?

> description in last table of section 5.3). If a destination parameter is

> not specified, then the URI in a successful recording is local to the MS

> single character, but due to new some use cases (one SP using '**' as a

> [11] Support for variable (dates, amounts, etc) prompts is proposed. We

> 'speed' and 'pause'/'resume' controls. Each will be modelled on the seek

> control with a parameter indicating an interval (a maximum pause interal

> in the case of 'pause').

[RE:] What is the use case here, I thought that the current consensus is to use the recording only for "role call" implementation.

[scott] One use of recording is for conferencing - but the intention of the Basic IVR package is that it covers other typical IVR use cases.  VCR controls are typically required for a voicemail, for example: MS plays prompts and messages, and user can navigate around them using DTMF.

> dialog type - so freeing the src attribute to reference external dialogs.

> [14] Syntax: it is proposed to add container elements for each dialog type

> [15] Syntax: it is proposed to create a single <prompt> element which is

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 17 Dec 2007 17:17:49 +0200

Scott,

About real-time text look at
http://tools.ietf.org/html/draft-ietf-sipping-toip-08

About [12] In addition to the 'seek' VCR control, we will also add
'volume',

in the case of 'pause').

[scott] One use of recording is for conferencing - but the intention of
the Basic IVR package is that it covers other typical IVR use cases.
VCR controls are typically required for a voicemail, for example: MS
plays prompts and messages, and user can navigate around them using
DTMF. 

[RE:] I still do not understand, this is an IVR package and not a
voicemail playback. Do I need in the IVR to control the flow of the IVR
session?

 I thought this is supposed to be a basic IVR package; it looks like you
start to address general recording and playback.

Roni

---

From: "Steve Buko" <[email-masked]>
Date: Mon, 17 Dec 2007 10:26:52 -0500

In my opinion voicemail is the "application" and is fairly basic.  It
will utilize the IVR package which I agree should contain the basic
record and playback definitions.

Maybe the term "Basic IVR" is misleading as a package name.

From: Even, Roni [mailto:[email-masked]] 
Sent: Monday, December 17, 2007 10:18 AM
To: McGlashan, Scott; [email-masked]
Subject: RE: [MEDIACTRL] Proposed updates on Basic IVR package

Scott,

 

in the case of 'pause').

Roni

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 17 Dec 2007 15:29:16 +0000

Thanks for real-time text pointer.

The second issue is one of the scope of the Basic IVR package. It is certainly the case the package need to cover the requirements for IVR within a conferencing use case. However, my understanding is that it would cover typical use cases for interactive voice response involving playing prompts, prompt and collect, and prompt and record. The design team discussions indicated that we want to cover VCR controls over prompt playback and a typical - but not exclusive use case - is voicemail.

Scott

Sent: Monday, December 17, 2007 16:18

Scott,

About real-time text look at http://tools.ietf.org/html/draft-ietf-sipping-toip-08

About [12] In addition to the 'seek' VCR control, we will also add 'volume',

in the case of 'pause').

[RE:] I still do not understand, this is an IVR package and not a voicemail playback. Do I need in the IVR to control the flow of the IVR session?

 I thought this is supposed to be a basic IVR package; it looks like you start to address general recording and playback.

Roni

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 17 Dec 2007 17:32:23 +0200

Scott,

I find this confusing. Now you can use the IVR package to record a
conference and control its play back from a playing application. I
thought this was not in scope

Roni

From: McGlashan, Scott [mailto:[email-masked]] 
Sent: Monday, December 17, 2007 5:29 PM
To: Even, Roni; [email-masked]
Subject: RE: [MEDIACTRL] Proposed updates on Basic IVR package

The second issue is one of the scope of the Basic IVR package. It is
certainly the case the package need to cover the requirements for IVR
within a conferencing use case. However, my understanding is that it
would cover typical use cases for interactive voice response involving
playing prompts, prompt and collect, and prompt and record. The design
team discussions indicated that we want to cover VCR controls over
prompt playback and a typical - but not exclusive use case - is
voicemail. 

Scott

Scott,

 

in the case of 'pause').

Roni

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 17 Dec 2007 16:50:41 +0100

Roni,

yes, you can, as long as the recording is over. Real-time record and playback
would be out of scope, instead.

Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

> thought this was not in scope

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 17 Dec 2007 15:35:45 +0000

Agreed. Calling it 'Basic IVR' was intended to (a) delimit the scope to basic IVR functions (play, collect and record), and (b) distinguish it from more advanced IVR packages like VoiceXML, TTS, ASR, etc.

Suggestions for alternative names are always welcome.

thanks

Scott

________________________________
From: Steve Buko [mailto:[email-masked]]
Sent: Monday, December 17, 2007 16:27
To: Even, Roni; McGlashan, Scott; [email-masked]
Subject: RE: [MEDIACTRL] Proposed updates on Basic IVR package

In my opinion voicemail is the "application" and is fairly basic.  It will utilize the IVR package which I agree should contain the basic record and playback definitions.

Scott,

in the case of 'pause').

Roni

---

From: Diego B <[email-masked]>
Date: Mon, 17 Dec 2007 17:43:22 +0200

Hi;
I agree with Steve
I think that you have to be able to implement, at least, a "basic 
voicemail" application
(playback and record) using the "Basic IVR" package.

Best Regards
Diego Besprosvan (:--:)
MailVision Ltd.

Steve Buko wrote:
>
> In my opinion voicemail is the “application” and is fairly basic. It 
> Maybe the term “Basic IVR” is misleading as a package name.
>
> *From:* Even, Roni [mailto:[email-masked]]
> *Sent:* Monday, December 17, 2007 10:18 AM
> *To:* McGlashan, Scott; [email-masked]
> *Subject:* RE: [MEDIACTRL] Proposed updates on Basic IVR package
>
> Scott,
>
> */ /*
> */[RE:] What is the use case here, I thought that the current 
> consensus is to use the recording only for "role call" 
> implementation./**/ /*
>
> */ /*
>
> */[scott] One use of recording is for conferencing - but the intention 
> of the Basic IVR package is that it covers other typical IVR use 
> cases. VCR controls are typically required for a voicemail, for 
> example: MS plays prompts and messages, and user can navigate around 
> them using DTMF. /*
>
> */ /*
>
> */[RE:] I still do not understand, this is an IVR package and not a 
> voicemail playback. Do I need in the IVR to control the flow of the 
> IVR session?/*
>
> */ I thought this is supposed to be a basic IVR package; it looks like 
> you start to address general recording and playback./*
>
> */ /*
>
> */Roni/*
>
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
>

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 17 Dec 2007 17:42:55 +0200

Hi,
My only point was that once you have these controls you can have general playback applications with this package, not only voice mail.
Roni

> From: Diego B [mailto:[email-masked]]
> Sent: Monday, December 17, 2007 5:43 PM
> To: Steve Buko
> Cc: Even, Roni; McGlashan, Scott; [email-masked]
> Subject: Re: [MEDIACTRL] Proposed updates on Basic IVR package
> 
> Hi;
> I agree with Steve