[MEDIACTRL] Questions on draft-ietf-mediactrl-ivr-control-package

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

Hi,

 

This is the first time I have carefully read through the draft, and I
have a bunch of questions for the IVR control package:

 

-          Why can't <dialogterminate> result in an <dialogexit> event
for PREPARED and STARTING state while this is done for STARTED state
only? If PREPARED state can generate dialogexit from a timeout, why
can't it generate a dialogexit from a dialogterminate?

-          Can the preparation duration for a prepared dialog be set in
dialogprepare? The recommended value of 30s seems to be fairly short to
me, and CCXML does not have this kind of arbitrary timeout as well. If I
am writing an outbound calling application (with CCXML), I would first
prepare the dialog to make sure the dialog is ready to go (and making
sure a VXML page is well formed) and then I would place the outbound
call. It's very likely by the time the user answers and call progress
detection is completed, 30s would have been passed and the prepared
dialog would be terminated by this timer. Why do we need this timeout
anyways?

-          Section 4.2.2 - would it be more convenient that if neither
connectionid and conferenceid is defined, it would take the connection
from the current SIP dialog associated with this control channel? Of
course this wouldn't work if the control channel is a dedicated one - I
think it would be a syntactic sugar to have such a shortcut.

-          There is a typo in the example of section 4.2.2.1.1:

 

...

    <subscribe>

     <dmtfnotify matchmode="control"/>  -- should be dtmfsub instead

    </subscribe>

...   

 

-          Can a dialog prefetch all the media prompts inside the dialog
and then report an error when any of the fetch fails? This is one thing
I am having problem with MSML is that you can only fail during execution
and the control client have to intelligently resume where the failure
happens, thus adding complexity to the control client. If the control
client knows one of the prompts fail to fetch, it would be easier for
the control client to try an alternate prompt altogether rather than
having the prompt to fail after playing the fifth wav file. 

-          Am I allowed to define more than one <prompt> inside <dialog>
so that I can define the first <prompt> to be bargein=false, and the
second one with bargin=true? The execution model for <dialog> (#4 in
4.3.1) is a bit unclear on this.

-          The definition of <par> is a bit sketchy here. Should the
child elements of <par> target which <stream> it can target the output
on? If there is no target, then how does MS know which stream it should
place the output or the MS makes a best-effort decision on this? 

-          If <control> is active for a <prompt>, does it mean bargein
has no effect for the <prompt>?

-          Does the DTMF digit buffer last over the lifetime of a
<dialog>?

-          If I start two simultaneous <dialog> on a connection, then I
assume we send the DTMF digits to both dialogs, however, does media
server keep a single digit buffer for both dialogs?

-          Does <control> automatically consume the entire digit buffer?
The third paragraph of 4.3.1.2 seems to imply this.

-          If I am allowed to have multiple <prompt> elements, does
<control> take effect to all the <prompt> elements? Does that mean I
can't just use <control> on a <prompt> element and then not use it for
the next <prompt>?

-          In my opinion, I think a better way to express <control> is
to allow a set of generic grammar to trigger events on <control>, which
then sends a control action to a specified <prompt>, rather than having
a prescribed set of attributes that define both the event and the
action. In a way a <prompt> is an event-based element where it can take
events sent from other controls such as the <control> element. I think
this is more in line with the SMIL model as this spec is borrowing some
parts of the event sequencing with <par> and <seq> anyways. This can
make extensions simpler if someone wants to build a speech based control
and send actions to a <prompt>.

-          Just to be clear when <grammar> is defined in <collect>, does
it override escapekey, termchar, as well as maxdigits?

-          In the DTMF collection execution, noinput, nomatch, and match
all results in a termination of collection execution. Does this imply
that dialog continue execution on step 5 of section 4.3.1? If the dialog
defines a repeatCount, then does it mean that the dialog repeats the
collection again? How do I model a different prompt for noinput and
nomatch without having the control client to request for a new dialog?
For a match, I can see that I can use a dtmfnotify to notify the control
client that a match is made, but I still need the control client to
explicitly terminate the dialog. I worry that there are side effects
with explicitly terminating the dialog on a match when <dialogterminate>
is processed slowly, the user may hear the dialog again if the
repeatCount is greater than one.

-          I have a concern with <record> that I also have with MSCML
and MSML is that it allows record to specify a destination (loc
attribute in <media>). This in a way creates a bunch of related security
issues that needs to be addressed by the system and makes the markup
inherently system-dependent. I actually like the way VXML defines it
with a record item variable; you can reuse it later in the markup and
you can also submit it with the <submit> tag. This makes the VXML
implementation platform-independent and there is no need to worry about
security concerns inherited by exposing potential system structure to
the control client.

-          Section 12.2.1 session.connection.redirect has an errata that
I also sent an email for RFC5552. It should take the History-Info
hi-entry elements in order in the session variable.

-          When conferenceid attribute is used for a VXML dialog, will
session.connection evaluate to null?

 

Sorry for inflicting a pile of questions - I plan to read up on the
mixer package and I'll probably have even more questions/comments J

 

Thanks!

Henry

 


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