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

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Feb 2010 10:57:21 -0600

This draft has now completed IETF Last Call. Robert has asked the authors to respond to Henry's comments on the working group mailing list as if they were IETF Last Call comments.

This is the last step before Robert puts this draft on an IESG agenda for balloting, but we need to have responses before Robert does that.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Henry Lum 
  To: [email-masked] 
  Sent: Friday, January 08, 2010 2:25 PM
  Subject: [MEDIACTRL] Questions on draft-ietf-mediactrl-ivr-control-package

  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. 

------------------------------------------------------------------------------

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

---

From: Scott McGlashan <[email-masked]>
Date: Thu, 18 Feb 2010 19:57:50 +0100

Hi Henry,

thanks for the comments and apologies for my delay in responding. 

The chairs are treating these as IETF Last Call Comments and after satisfactory resolution, we can move onto the next stage.

My response is marked as [SMCG]. For the WG, I've marked proposed spec changes with *** PROPOSED CHANGE. 

Let me know if you need further information or have an issue with a response.

Scott

On 8 Jan 2010, at 21:25, Henry Lum wrote:

> --_004_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintgene_
> Content-Type: multipart/alternative;
> 	boundary="_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintgene_"
> 
> --_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintgene_
> Content-Type: text/plain; charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
> 
> 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=92t <dialogterminate> result in an <dialogexit> event fo=
> r PREPARED and STARTING state while this is done for STARTED state only? If=
> PREPARED state can generate dialogexit from a timeout, why can=92t it gene=
> rate a dialogexit from a dialogterminate?
> 

[SMCG]  The <dialogexit> is a notification event from MS to AS, i.e. it is not a response to an AS request. You're right that we could add a <dialogexit> payload to the 410 response when the AS terminates the dialog, but I'm not clear it adds anything to the current design. 

> -          Can the preparation duration for a prepared dialog be set in dia=
> logprepare? The recommended value of 30s seems to be fairly short to me, an=
> d CCXML does not have this kind of arbitrary timeout as well. If I am writi=
> ng 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=92s very likel=
> y by the time the user answers and call progress detection is completed, 30=
> s would have been passed and the prepared dialog would be terminated by thi=
> s timer. Why do we need this timeout anyways?
> 

[SMCG] The timeout was added because there was a group concern about tying up resources for an indefinite amount of time. I agree that 30s is probably too small and could be increased to 300s. 

**** PROPOSED CHANGE: Please let me know asap if anyone objects to increasing the recommended maximum dialog preparation duration from 30s to 300s. ***

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

[SMCG] Multiple user SIP dialogs can be controlled through the same control channel. So I'm not sure how your proposal would work.

>     <dmtfnotify matchmode=3D"control"/>  -- should be dtmfsub instead
>    </subscribe>
> ...
> 

[SMCG] Good catch! Fixed in next version. 

> 
> -          Can a dialog prefetch all the media prompts inside the dialog an=
> d 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, thu=
> s 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 af=
> ter playing the fifth wav file.
> 

[SMCG] With a <dialogprepare> command, any fetch failures can be reported using a 409 error response code.  If the resource fails during executing, the MS sends a <dialogexit> with a 4 status. In both cases the MS can provide more detail on the error in the reason attribute. If you need automatic prompt fallback, then this capability is covered in the VoiceXML dialog type. 

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

[SMCG] The text says the <prompt> is optional, so maximum of one. XML schema in Section 5 is even clearer:

<xsd:element ref="prompt" minOccurs="0"
      maxOccurs="1" /

> -          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 the=
> re is no target, then how does MS know which stream it should place the out=
> put or the MS makes a best-effort decision on this?
> 

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

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

[SMCG] Depends - bargein behavior is controlled by <prompt> and not <control>.. If the input matches an active control then prompt is terminated. If the input doesn't match an active control, then bargein depends on the attribute of the <prompt> element. 

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

[SMCG] The spec doesn't detail the lifetime of a digit buffer, [But I'd say, yes, at least the lifetime of a <dialog>; preferably the lifetime of the attached connection or conference otherwise the concept of clearing the buffer between dialog cycles is pretty weak.] 

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

[SMCG] Implementation issue on which the spec is (currently) agnostic. [But I'd associate the digit buffer with each connection/conference, and the buffer would be shared between multiple active dialogs.]  

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

[SMCG] Not necessarily - <control>s match against the first DTMF in the buffer. If there are multiple DTMFs in the buffer, then only the consumed ones would be removed. I agree that 3rd paragraph of 4.3.1.2 should be clarified.

 *** PROPOSED CHANGE: Please let me know asap if anyone objects to replacing in 4.3.1.2: 

If incoming DTMF matches a specified runtime control, then the DTMF is not available to the <collect> operation, including its digit buffer.

with 

If an incoming DTMF character matches a specified runtime control, then the DTMF character is consumed: it is not added to digit buffer and so not available to the <collect> operation. 

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

[SMCG] This version doesn't support multiple <prompt> elements per <dialog>. 

> 
> -          In my opinion, I think a better way to express <control> is to a=
> llow a set of generic grammar to trigger events on <control>, which then se=
> nds a control action to a specified <prompt>, rather than having a prescrib=
> ed 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>.

[SMCG] I agree in theory. However, the event-based model can get complex. Characterizing <control> as grammars (allowing complex DTMF/ASR sequences) leads to some complex timing issues when <collect> is also active. I think that the current model is sufficient for the use cases - real time controls of prompt playback. But definitely a great topic for a later mediaCtrl package. 

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

[SMCG] Not escapekey - it applies whether or not <grammar> is specified. But termchar and maxdigits only apply when a custom <grammar> is not specified. If you think we should clarify this more, please propose some wording changes (I think all the constraints are mentioned but clearer text is always good!). 

> 
> -          In the DTMF collection execution, noinput, nomatch, and match al=
> l results in a termination of collection execution. Does this imply that di=
> alog continue execution on step 5 of section 4.3.1?

[SMCG] Yes. 

> If the dialog defines a=
> repeatCount, then does it mean that the dialog repeats the collection agai=
> n?

[SMCG] Yes. 

> How do I model a different prompt for noinput and nomatch without having=
> the control client to request for a new dialog?

[SMCG] The <dialog> language doesn't support this feature (although you could use <media> src URI manipulation!). It has been discussed in the group and if I remember correctly VoiceXML dialogs were recommended if you want this feature within a single dialog cycle. 

> For a match, I can see tha=
> t 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.
> 

[SMCG] Very much depends on your MS implementation. I don't remember any of the current implementations raising this as an issue, but I see your point. 

> -          I have a concern with <record> that I also have with MSCML and M=
> SML is that it allows record to specify a destination (loc attribute in <me=
> dia>). 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-depend=
> ent. I actually like the way VXML defines it with a record item variable; y=
> ou can reuse it later in the markup and you can also submit it with the <su=
> bmit> tag. This makes the VXML implementation platform-independent and ther=
> e is no need to worry about security concerns inherited by exposing potenti=
> al system structure to the control client.

[SMCG] We've had an IETF security review and they didn't raise this issue. I understand the benefit  in vxml of being able to play a <record> variable directly, and that in both languages a URI is used to (a) locate the recording, or (b) locate the submission target. If your security concern is that the URI structure exposes system structure, then there are ways of addressing this (virtual URIs, let alone system authorization/security). Let me know if I've missed your point.  

> 
> -          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 el=
> ements in order in the session variable.

[SMCG] I'm happy to make this change since our goal was to be aligned with RFC5552 on vxml mapping. Can you confirm that the RFC5552 errata has been accepted (e.g. are Mark and/or Dave ok with it)? 

** PROPOSED CHANGE: Please let me know asap if anyone objects to replacing in 12.2.1: 

session.connection.redirect
This array is populated by information contained in the History-Info ([RFC4244]) header in the initial INVITE or is otherwise undefined. Each entry (hi-entry) in the History-Info header is mapped, in reverse order, into an element of the session.connection.redirect array.

with 

session.connection.redirect
This array is populated by information contained in the History-Info ([RFC4244]) header in the initial INVITE or is otherwise undefined. Each entry (hi-entry) in the History-Info header is mapped, in the order it appeared in the History-Info header, into an element of the session.connection.redirect array.

> 
> -          When conferenceid attribute is used for a VXML dialog, will sess=
> ion.connection evaluate to null?

[SMCG] Evaluates to undefined. 

> 
> Sorry for inflicting a pile of questions =96 I plan to read up on the mixer=
> package and I=92ll probably have even more questions/comments :)

No apology necessary. It is great to know people read the spec at this level of detail, Henry. 

> 
> Thanks!
> Henry
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf=
> idential and proprietary information of Alcatel-Lucent and/or its affiliate=
> d entities. Access by the intended recipient only is authorized. Any liabil=
> ity arising from any party acting, or refraining from acting, on any inform=
> ation contained in this e-mail is hereby excluded. If you are not the inten=
> ded recipient, please notify the sender immediately, destroy the original t=
> ransmission and its attachments and do not disclose the contents to any oth=
> er 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-Luc=
> ent and/or its affiliated entities.
> 
> --_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintgene_
> Content-Type: text/html; charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
> 
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
> osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
> icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
> :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
> uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
> t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
> m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
> t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
> :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
> soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
> xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
> icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
> schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
> point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
> /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
> =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
> schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
> .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
> /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
> ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
> repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
> xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
> schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
> /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
> ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
> p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
> /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
> mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
> crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
> s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
> ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
> om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
> ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
> partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
> 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
> 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
> deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
> Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
> st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"><head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
> 252">
> <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
> <style>
> <!--
> /* Font Definitions */
> @font-face
> 	{font-family:Wingdings;
> 	panose-1:5 0 0 0 0 0 0 0 0 0;}
> @font-face
> 	{font-family:Wingdings;
> 	panose-1:5 0 0 0 0 0 0 0 0 0;}
> @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:11.0pt;
> 	font-family:"Calibri","sans-serif";}
> a:link, span.MsoHyperlink
> 	{mso-style-priority:99;
> 	color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{mso-style-priority:99;
> 	color:purple;
> 	text-decoration:underline;}
> pre
> 	{mso-style-priority:99;
> 	mso-style-link:"HTML Preformatted Char";
> 	margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:10.0pt;
> 	font-family:"Courier New";}
> p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
> 	{mso-style-priority:34;
> 	margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	font-size:11.0pt;
> 	font-family:"Calibri","sans-serif";}
> span.HTMLPreformattedChar
> 	{mso-style-name:"HTML Preformatted Char";
> 	mso-style-priority:99;
> 	mso-style-link:"HTML Preformatted";
> 	font-family:"Courier New";}
> span.EmailStyle20
> 	{mso-style-type:personal-compose;
> 	font-family:"Calibri","sans-serif";
> 	color:windowtext;
> 	font-weight:normal;
> 	font-style:normal;
> 	text-decoration:none none;}
> .MsoChpDefault
> 	{mso-style-type:export-only;
> 	font-size:10.0pt;}
> @page Section1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.0in 1.0in 1.0in;}
> div.Section1
> 	{page:Section1;}
> /* List Definitions */
> @list l0
> 	{mso-list-id:2127846407;
> 	mso-list-type:hybrid;
> 	mso-list-template-ids:634840108 -1943750804 67698691 67698693 67698689 676=
> 98691 67698693 67698689 67698691 67698693;}
> @list l0:level1
> 	{mso-level-start-at:0;
> 	mso-level-number-format:bullet;
> 	mso-level-text:-;
> 	mso-level-tab-stop:none;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;
> 	font-family:"Calibri","sans-serif";
> 	mso-fareast-font-family:Calibri;
> 	mso-bidi-font-family:"Times New Roman";}
> @list l0:level2
> 	{mso-level-tab-stop:1.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level3
> 	{mso-level-tab-stop:1.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level4
> 	{mso-level-tab-stop:2.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level5
> 	{mso-level-tab-stop:2.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level6
> 	{mso-level-tab-stop:3.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level7
> 	{mso-level-tab-stop:3.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level8
> 	{mso-level-tab-stop:4.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level9
> 	{mso-level-tab-stop:4.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> ol
> 	{margin-bottom:0in;}
> ul
> 	{margin-bottom:0in;}
> -->
> </style>
> <!--[if gte mso 9]><xml>
> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
> <o:shapelayout v:ext=3D"edit">
>  <o:idmap v:ext=3D"edit" data=3D"1" />
> </o:shapelayout></xml><![endif]-->
> </head>
> 
> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
> 
> <div class=3D"Section1">
> 
> <p class=3D"MsoNormal">Hi,<o:p></o:p></p>
> 
> <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
> 
> <p class=3D"MsoNormal">This is the first time I have carefully read through=
> the
> draft, and I have a bunch of questions for the IVR control package:<o:p></o=
> :p></p>
> 
> <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
> 
> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
> 1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
> =3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;
> </span></span><![endif]>Why can=92t &lt;dialogterminate&gt; result in an
> &lt;dialogexit&gt; event for PREPARED and STARTING state while this is done=
> for
> STARTED state only? If PREPARED state can generate dialogexit from a timeou=
> t,
> why can=92t it generate a dialogexit from a dialogterminate?<o:p></o:p></p>
> 
> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
> 1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
> =3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;
> </span></span><![endif]>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=92s 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?<o:p></o:p></p>
> 
> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
> 1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
> =3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;
> </span></span><![endif]>Section 4.2.2 =96 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=92t work if the control channel is a dedicated one
> =96 I think it would be a syntactic sugar to have such a shortcut.<o:p></o:=
> p></p>
> 
> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
> 1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
> =3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;
> </span></span><![endif]>There is a typo in the example of section 4.2.2.1.1=
> :<o:p></o:p></p>
> 
> <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
> 
> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
> urier New&quot;">...<o:p></o:p></span></p>
> 
> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
> urier New&quot;">&nbsp;&nbsp;&nbsp;
> &lt;subscribe&gt;<o:p></o:p></span></p>
> 
> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
> urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;
> &lt;dmtfnot

---

From: Scott McGlashan <[email-masked]>
Date: Fri, 19 Feb 2010 19:55:23 +0100

Hi Henry,

Thanks for the quick turn-around. I've responded below to your comments which require further discussion. I've removed issues which don't require further discussion to keep the email shorter and clear!

thanks

Scott

> [HL] I understand that <dialogexit> is a notification event, and I think this should always be the last event AS should receive to note that a dialog is being terminated, rather than having AS to determine when a dialog is terminated based on the context of the state machine

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

> [HL] Does <dialogprepare> go and fetch all the external prompts defined inside <dialog> and return 409 if fetching fails? The first paragraph in 4.2.1 is a bit unclear about this.

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

> [HL] So the answer is no. Would be it better to remove maxOccurs=”1” so that I can control which part of the prompt can be barged in?

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

> [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?

> [HL] I don’t think active control always terminate a prompt. An example is speedup/volumeupkey – you want to continue with the prompt with faster speed or higher volume. Perhaps a better definition is to say that when input matches an active control, then the control overrides the bargein attribute of the <prompt> element.

[SMCG] Sorry, I missed a 'not':  If the input matches an active control then prompt is NOT terminated. I think we're in agreement on this one. 

> [HL] How about clarifying the wording for escapekey and maxdigits:
>   escapekey:  specifies a DTMF key that indicates the DTMF collection
>      is to be re-initiated. This key overrides the custom grammar and clears the digit
>      buffer. A valid value is a DTMF Character (see
>      Section 4.6.2<http://tools.ietf.org/html/draft-ietf-mediactrl-ivr-control-package-07#section-4.6.2>).  The attribute is optional.  There is no default
>      value.
> 
>   maxdigits:  The maximum number of digits to collect using an internal
>      digits (0-9 only) grammar. It is ignored with custom grammar is used.
>      A valid value is a positive integer (see Section 4.6.5<http://tools.ietf.org/html/draft-ietf-mediactrl-ivr-control-package-07#section-4.6.5>).  The
>      attribute is optional.  The default value is 5.
> 

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

> [HL] Ouch, then the <dialog> language is not very useful if you need the app server to micro-manage even for a simple dialog to repeat noinput. Can we at least fix the main loop in 4.3.1 to take care of this (to only repeat if certain condition applies).
> 

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

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 19 Feb 2010 12:54:55 -0800

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?

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

---

From: Scott McGlashan <[email-masked]>
Date: Wed, 24 Feb 2010 21:32:18 +0100

Hi Henry,

I think we are almost there on the IVR.

thanks

Scott

On 19 Feb 2010, at 21:54, Henry Lum wrote:

> [[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]  Not according to the current spec wording and state machine. <dialogexit> would only follow <dialogterminate> when the dialog is in the started state.  

> [[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]  Ok. Done. 

> [[hlum]] Let’s add to the <media> element referenced in this section:
> <media>:  specifies a media resource (see 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] Ok. Done. 

> [[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] (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]] 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.
>  
> 

[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?

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 24 Feb 2010 13:30:25 -0800

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

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:

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.

---

From: Scott McGlashan <[email-masked]>
Date: Thu, 25 Feb 2010 15:19:47 +0100

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:

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

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

[SMCG] Done - I clarified these points. 

>    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
>      <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,
>       <dialogexit status=”1”>
>         <promptinfo duration=”3654” termmode=”bargein”/>
>         <collectinfo dtmf=”1234” termmode=”match”>
>       </dialogexit>
>     </event>
>    </mscivr>
>  
> [SMCG] thanks. Added.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 25 Feb 2010 08:53:48 -0600

to the working group,

i am loath to even think the words "another WGLC" to myself, much less say them out loud to eric, but please remember that we are making changes to a document that has already been through WGLC, and we thought we had consensus on.

it's ok to make changes, but if we don't have consensus on the changes, that's a problem.

If you have any concerns about the changes Scott and Henry have been discussing, either now or when Scott submits a revision, please say so - we need to have consensus in the working group when we're looking at any comments that come back from IESG evaluation, when Robert puts our documents on a telechat agenda.

("ya know, we were wondering about that ourselves" is NOT the response Robert will be looking for!)

thanks,

spencer
  ----- Original Message ----- 
  From: Scott McGlashan 
  To: Henry Lum 
  Cc: [email-masked] 
  Sent: Thursday, February 25, 2010 8:19 AM
  Subject: Re: [MEDIACTRL] Questions ondraft-ietf-mediactrl-ivr-control-package

  Scott

    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] thanks. Added.

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 25 Feb 2010 09:45:50 -0800

Thanks Scott, all looks good to me.

Henry

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

Scott

Hi Scott,

3 items left J

Thanks

Henry

 

 

 

      <prompt bargein="true">

      </prompt>

      <collect maxdigits="4"/>

     </dialog>

    </dialogstart>

   </mscivr>

    <event dialogid="vxi81">

      <dialogexit status="1">

      </dialogexit>

    </event>

   </mscivr>

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