Re: [MEDIACTRL] Questions ondraft-ietf-mediactrl-ivr-control-package

["Henry Lum" <[e-mail]>]

Hi Scott,

 

Please see my responses below.

 

Thanks

Henry

 

[SMCG] The group had discussed this behavior in the past and agreed that
it was important that <dialogexit> is always the last event sent when a
started dialog is terminated by the MS for whatever reason. I believe
the group discussed whether we should also have <dialogexit> event when
the AS explicitly terminates the dialog but we thought this introduced
additional protocol traffic and the AS would already know which dialog
it was terminating.  

 

[[hlum]] Okay, I accept the shortcut with the 410 response to optimize
the need for <dialogexit>. However, in the PREPARED state, when
<dialogterminate> is called and 200 response is received, shall I expect
a <dialogexit> in this state?

 

 

[SMCG] I thought this was clear - the paragraph references 'retrieving
external .. resources'  and a <prompt> is a one or more (media)
resources. In <media> definition, the loc attribute says 'If the
resource is to be retrieved but the MS cannot retrieve it within the
timeout interval, the MS sends a <response> with a 409 status code.' If
you have a specific suggestion, please send. 

 

[[hlum]] I got confused about the differences between VXML (external)
and resources (<media> tag). Can we modify the wording in
<dialogprepare/start> to:

Dialog preparation consists of (a) retrieving external dialog document
and/or resources referenced by the <dialog> IVR dialog elements, and (b)
validating the dialog document syntactically and semantically.

 

 

[SMCG] Previously we've taken multiple prompt support as outside the
requirements scope of the dialog language in this spec (trying to keep
it simple). I'd have a concern that adding it at this stage would
require multiple changes in the syntax and semantics including dialog
execution model. The bargein on/off use case can be addressed already
with a VoiceXML dialog type, so I'd be reluctant to add it at this late
stage. 

 

[[hlum]] Okay this is fine. Let's keep it simple.





[SMCG] Right - it is the responsibility of the MS to map the <media>
playback to the appropriate media streams. The package is agnostic to
the mechanism used in the MS implementation.
[HL]  Okay this is fine - shall we add a short statement at the end of
4.3.1.1.3 to mention this?

[SMCG] Do you have a specific suggestion?

 

[[hlum]] Let's add to the <media> element referenced in this section:

<media>:  specifies a media resource (see Section 4.3.1.5
<http://tools.ietf.org/html/draft-ietf-mediactrl-ivr-control-package-07#
section-4.3.1.5> ) to play; it is up to the media server to assign the
<media> playback to the appropriate media stream when multiple media
types are used. The element is optional. 

 





[SMCG] Fine with maxdigits clarification - added to spec. But I'm having
trouble with your escapekey modification since (a) I thought it simply
takes priority over the characters in the internal or custom grammar
(i.e. it doesn't override the custom grammar) and (b) your modification
introduces the idea of clearing the digit buffer which isn't part of the
<collect> execution model description (i.e. escaping simply restarts the
collection without clearing the buffer). 

 

[[hlum]] For (a), if we don't override the grammar, then what happens if
this digits happens to match both the escapekey and the grammar at the
same time? I think we need to assign a priority of matching when this
scenario happens. For (b), I think it's debatable since it's a concept
that is outside of the scope of VXML. What I mean is that If the
<collect> already sets cleardigitbuffer to true, shall escape
automatically clear the digit buffer again as if <collect> is executed
again?





[SMCG] If you have specific wording suggestions, please send. We don't
have any existing conditional expressions - beyond exact matching - in
the language at the moment, so I'm not sure whether this will be a
simple fix. 

 

[[hlum]] Shall we add a Boolean attribute in <collect> called
"finishonmatch" so that the dialog will automatically treated as
finished and will treat step #5 of <dialog> as the last iteration of the
execution cycle. We should also add a similar attribute for <record> so
that the dialog won't end up looping when a recording is collected
(finish on stopped, dtmf, maxtime, finalsilence). I think these are
relatively simple fixes to the markups that can make the dialog more
useful without resorting to micromanagement of dialogs or requiring the
use of VXML.


					
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.