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

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

Thanks Scott, all looks good to me.

 

Henry

 

From: Scott McGlashan [mailto:[e-mail]] 
Sent: Thursday, February 25, 2010 9:20 AM
To: Henry Lum
Cc: [e-mail]
Subject: Re: [MEDIACTRL] Questions
ondraft-ietf-mediactrl-ivr-control-package

 

 

All done I think - but correct me if I'm wrong.  

 

I'll send the updated IVR spec to the mailing list later today. 

 

thanks for your input and prompt responses Henry.

 

Scott

 

 

On 24 Feb 2010, at 22:30, Henry Lum wrote:





Hi Scott,

 

3 items left J

 

Thanks

Henry

 

 [SMCG]  Not according to the current spec wording and state machine.
<dialogexit> would only follow <dialogterminate> when the dialog is in
the started state.  

 
[[hlum]] So this is the only exception where you don't get either a
<dialogexit> nor a negative response to a dialogterminate. This is in
contradiction with the wording in 4.2.5.1 for <dialogexit>: 
" The <dialogexit> event indicates that a prepared or active dialog has
exited because it is..."

We should either change the wording for the <dialogexit> event to
indicate only active dialogs, or we change the state machine to fix this
exception. I would vote for the latter.

 

 

[SMCG]  Done - I've changed the state machine. 

 





 

[SMCG] (a) OK. I'll clarify that the escapekey takes priority (just like
termchar). (b) I could go either way on this. Currently there is no
implication that that the digit buffer is cleared. However, I assume
that  current grammar matches are discarded and incoming DTMF (including
any pending in the digit buffer) are matched against the grammar. 

 

[[hlum]] I am fine with your assumption for (b); let's clarify this in
escapekey.

 

 

[SMCG] Done - I clarified these points. 





[SMCG] Ok. How about *** PROPOSED CHANGE: 

 

Add a 'repeatUntilComplete' attribute (boolean value, default false) on
<dialog>  If set to true,  then a dialog repetition cycle is terminated
if a dialog cycle completes without error and one of the following
conditions is true:

 

1. <collect> reports termination status of 'match' or 'stopped'.

2. <record> reports termination status of 'stopped', 'dtmf', 'maxtime'
or 'finalsilence'.

 

Is this sufficient? If so, this is a relatively straightforward change
(it will affect the schema though). Can you write up an example section
similar to Section 6.2.5?

 

[[hlum]] I think this would do. How about the following example?

6.2.6 RepeatUntilComplete usage for <collect>

   This example is a prompt and collect to collect the PIN from the
user.

   RepeatUntilComplete is set to true in this case so that when the
collection

   is matched, the dialog terminates the repeat cycle and will not
repeat the

   prompt for collecting PIN again.

 

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">

    <dialogstart connectionid="7HDY839:HJKSkyHS">

     <dialog repeatCount="3" repeatUntilComplete="true">

      <prompt bargein="true">

        <media loc="http://example.com/please_enter_your_pin.vox"/>

      </prompt>

      <collect maxdigits="4"/>

     </dialog>

    </dialogstart>

   </mscivr>

 

   Whenever the user barges in the prompt and <collect> receives a
matching grammar,

   the dialog cycle is considered complete and returns the following:

 

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">

    <event dialogid="vxi81">

      <dialogexit status="1">

        <promptinfo duration="3654" termmode="bargein"/>

        <collectinfo dtmf="1234" termmode="match">

      </dialogexit>

    </event>

   </mscivr>

 

   If no user input was provided, or the input did not match the

   grammar, the dialog would loop for a maximum of 3 times.

 

[SMCG] thanks. Added. 

 

 


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.

 


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