>=20 >

Hi,

>=20 >

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

>=20 >

1 lfo2">- =3D3D"font:7.0pt "Times New = Roman""> &=3D > nbsp; > Why can=3D92t <dialogterminate> result = in an > <dialogexit> event for PREPARED and STARTING state while this is = done=3D > for > STARTED state only? If PREPARED state can generate dialogexit from a = timeou=3D > t, > why can=3D92t it generate a dialogexit from a = dialogterminate?

>=20 >

1 lfo2">- =3D3D"font:7.0pt "Times New = Roman""> &=3D > nbsp; > Can the preparation duration for a prepared = dialog =3D > be > set in dialogprepare? The recommended value of 30s seems to be fairly = short=3D > 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=3D > the > dialog to make sure the dialog is ready to go (and making sure a VXML = page =3D > is > well formed) and then I would place the outbound call. It=3D92s 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?

>=20 >

1 lfo2">- =3D3D"font:7.0pt "Times New = Roman""> &=3D > nbsp; > Section 4.2.2 =3D96 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=3D > ? Of > course this wouldn=3D92t work if the control channel is a dedicated = one > =3D96 I think it would be a syntactic sugar to have such a = shortcut. p>

>=20 >

1 lfo2">- =3D3D"font:7.0pt "Times New = Roman""> &=3D > nbsp; > There is a typo in the example of section = 4.2.2.1.1=3D > :

>=20 >

urier New"">...

>=20 >

urier New""> > <subscribe>

>=20 >

urier New""> > <dmtfnot --Apple-Mail-8-449461526 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDus= intgene_
Content-Type: multipart/alternative;
= boundary=3D"_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusin= tgene_"

--_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintg= ene_
Content-Type: text/plain; = charset=3D"Windows-1252"
Content-Transfer-Encoding: = quoted-printable

Hi,

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

- = Why can=3D92t = <dialogterminate> result in an <dialogexit> event fo=3D
r = PREPARED and STARTING state while this is done for STARTED state only? = If=3D
PREPARED state can generate dialogexit from a timeout, why = can=3D92t it gene=3D
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=3D
logprepare?= The recommended value of 30s seems to be fairly short to me, an=3D
d = CCXML does not have this kind of arbitrary timeout as well. If I am = writi=3D
ng an outbound calling application (with CCXML), I would = first prepare the =3D
dialog to make sure the dialog is ready to go = (and making sure a VXML page =3D
is well formed) and then I would = place the outbound call. It=3D92s very likel=3D
y by the time the = user answers and call progress detection is completed, 30=3D
s would = have been passed and the prepared dialog would be terminated by = thi=3D
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 =3D96 = would it be more convenient that if neither co=3D
nnectionid and = conferenceid is defined, it would take the connection from t=3D
he = current SIP dialog associated with this control channel? Of course this = =3D
wouldn=3D92t work if the control channel is a dedicated one =3D96 = I think it wo=3D
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.

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

...
=    <subscribe>
=     <dmtfnotify matchmode=3D3D"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=3D
d then report = an error when any of the fetch fails? This is one thing I am =3D
having= problem with MSML is that you can only fail during execution and = the=3D
control client have to intelligently resume where the failure = happens, thu=3D
s adding complexity to the control client. If the = control client knows one =3D
of the prompts fail to fetch, it would = be easier for the control client to =3D
try an alternate prompt = altogether rather than having the prompt to fail af=3D
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=3D
that = I can define the first <prompt> to be bargein=3D3Dfalse, and the = second=3D
one with bargin=3D3Dtrue? The execution model for = <dialog> (#4 in 4.3.1) is =3D
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:


- =
         The definition of =
<par> is a bit sketchy here. Should the child =3D
elements of =
<par> target which <stream> it can target the output on? If =
the=3D
re is no target, then how does MS know which stream it should =
place the out=3D
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 =3D
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=3D
ume we =
send the DTMF digits to both dialogs, however, does media server =
kee=3D
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=3D
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=3D
l> take =
effect to all the <prompt> elements? Does that mean I can=3D92t =
just =3D
use <control> on a <prompt> element and then not =
use it for the next =
<promp=3D
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=3D
llow a set =
of generic grammar to trigger events on <control>, which then =
se=3D
nds a control action to a specified <prompt>, rather than =
having a prescrib=3D
ed set of attributes that define both the event =
and the action. In a way a =3D
<prompt> is an event-based =
element where it can take events sent from other=3D
 controls such as =
the <control> element. I think this is more in line with =3D
the =
SMIL model as this spec is borrowing some parts of the event =
sequencing=3D
 with <par> and <seq> anyways. This can =
make extensions simpler if someone =3D
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=3D
 =
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=3D
l results in =
a termination of collection execution. Does this imply that di=3D
alog =
continue execution on step 5 of section 4.3.1? =

[SMCG] =
Yes. 

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

[SMCG] =
Yes. 

How do I model a =
different prompt for noinput and nomatch without having=3D
 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=3D
t I can use a dtmfnotify to notify the control client that =
a match is made,=3D
 but I still need the control client to =
explicitly terminate the dialog. I =3D
worry that there are side =
effects with explicitly terminating the dialog on=3D
 a match when =
<dialogterminate> is processed slowly, the user may hear the =
=3D
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=3D
SML is that =
it allows record to specify a destination (loc attribute in =
<me=3D
dia>). This in a way creates a bunch of related security =
issues that needs =3D
to be addressed by the system and makes the =
markup inherently system-depend=3D
ent. I actually like the way VXML =
defines it with a record item variable; y=3D
ou can reuse it later in =
the markup and you can also submit it with the <su=3D
bmit> =
tag. This makes the VXML implementation platform-independent and =
ther=3D
e is no need to worry about security concerns inherited by =
exposing potenti=3D
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 =3D
also sent an =
email for RFC5552. It should take the History-Info hi-entry =
el=3D
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: 

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

[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=3D
ion.connection =
evaluate to null?

[SMCG] =
Evaluates to undefined. 


Sorry for inflicting a pile of questions =3D96 I =
plan to read up on the mixer=3D
 package and I=3D92ll 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=3D
idential and proprietary information of Alcatel-Lucent and/or =
its affiliate=3D
d entities. Access by the intended recipient only is =
authorized. Any liabil=3D
ity arising from any party acting, or =
refraining from acting, on any inform=3D
ation contained in this =
e-mail is hereby excluded. If you are not the inten=3D
ded recipient, =
please notify the sender immediately, destroy the original =
t=3D
ransmission and its attachments and do not disclose the contents =
to any oth=3D
er person, use it for any purpose, or store or copy the =
information in any =3D
medium. Copyright in this e-mail and any =
attachments belongs to Alcatel-Luc=3D
ent and/or its affiliated =
entities.

--_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusin=
tgene_
Content-Type: text/html; =
charset=3D"Windows-1252"
Content-Transfer-Encoding: =
quoted-printable

<html =
xmlns:v=3D3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D3D"urn:schemas-micr=3D
osoft-com:office:office" =
xmlns:w=3D3D"urn:schemas-microsoft-com:office:word" =
=3D
xmlns:x=3D3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D3D"urn:schemas-m=3D
icrosoft-com:office:powerpoint" =
xmlns:a=3D3D"urn:schemas-microsoft-com:office=3D
:access" =
xmlns:dt=3D3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D3D"=3D
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D3D"urn:schemas-microsof=3D
t-com:rowset" =
xmlns:z=3D3D"#RowsetSchema" =
xmlns:b=3D3D"urn:schemas-microsoft-co=3D
m:office:publisher" =
xmlns:ss=3D3D"urn:schemas-microsoft-com:office:spreadshee=3D
t" =
xmlns:c=3D3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns=3D
:odc=3D3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D3D"urn:schemas-micro=3D
soft-com:office:activation" =
xmlns:html=3D3D"http://www.w3.org/TR/REC-html40" =3D
xmlns:q=3D3D"http://schemas.xmlsoap.=
org/soap/envelope/" xmlns:rtc=3D3D"http://m=3D
icrosoft.com/officenet=
/conferencing" xmlns:D=3D3D"DAV:" xmlns:Repl=3D3D"http://=3D
schemas.microsoft.com/repl/" xmlns:mt=3D3D"http://schemas.microsoft.co=
m/share=3D
point/soap/meetings/" xmlns:x2=3D3D"http://schemas.micro=
soft.com/office/excel=3D
/2003/xml" xmlns:ppda=3D3D"http://www.passport.com/Nam=
eSpace.xsd" xmlns:ois=3D
=3D3D"http://schemas.=
microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D3D"http://=3D
schemas.m=
icrosoft.com/sharepoint/soap/directory/" xmlns:ds=3D3D"http://www.w3=3D
.org/2000/09/xmldsig#" =
xmlns:dsp=3D3D"http://schemas.microso=
ft.com/sharepoint=3D
/dsp" xmlns:udc=3D3D"http://schemas.microsoft.co=
m/data/udc" xmlns:xsd=3D3D"http=3D
://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D3D"http://schemas.microsoft.com/=
sha=3D
repoint/soap/2002/1/alerts/" xmlns:ec=3D3D"http://www.w3.org/2001/04/xmlen=
c#"=3D
 xmlns:sp=3D3D"http://schemas.microsoft=
.com/sharepoint/" xmlns:sps=3D3D"http://=3D
schemas.microsoft.c=
om/sharepoint/soap/" xmlns:xsi=3D3D"http://www.w3.org/2001=3D
/XMLSc=
hema-instance" xmlns:udcs=3D3D"http://schemas.micros=
oft.com/data/udc/so=3D
ap" xmlns:udcxf=3D3D"http://schemas.micr=
osoft.com/data/udc/xmlfile" xmlns:udc=3D
p2p=3D3D"http://schemas.m=
icrosoft.com/data/udc/parttopart" =
xmlns:wf=3D3D"http:/=3D
/schemas.microsoft.com/sharepoint/soap/workflow=
/" xmlns:dsss=3D3D"http://sche=3D
mas.microsoft.c=
om/office/2006/digsig-setup" xmlns:dssi=3D3D"http://schemas.mi=3D
crosoft.com/office/2006/dig=
sig" xmlns:mdssi=3D3D"http://schemas.openxmlformat=3D
s.org/package/2006/di=
gital-signature" xmlns:mver=3D3D"http://schemas.openxmlf=3D
ormats.org/markup-com=
patibility/2006" xmlns:m=3D3D"http://schemas.microsoft.c=3Dom/office/2004/12/omml" xmlns:mrels=3D3D"http://schemas.openxmlfor=
mats.org/pa=3D
ckage/2006/relationships" xmlns:spwp=3D3D"http://microsoft.com/share=
point/web=3D
partpages" xmlns:ex12t=3D3D"http://schem=
as.microsoft.com/exchange/services/20=3D
06/types" =
xmlns:ex12m=3D3D"http://sche=
mas.microsoft.com/exchange/services/200=3D
6/messages" =
xmlns:pptsl=3D3D"http://schema=
s.microsoft.com/sharepoint/soap/Sli=3D
deLibrary/" =
xmlns:spsl=3D3D"http://micro=
soft.com/webservices/SharePointPortal=3D
Server/PublishedLinksServi=
ce" xmlns:Z=3D3D"urn:schemas-microsoft-com:" xmlns:=3D
st=3D3D"&#1;=
" xmlns=3D3D"http://www.w3.org/TR/REC-html40"><head>
<meta http-equiv=3D3D"Content-Type" =
content=3D3D"text/html; charset=3D3DWindows-1=3D
252">
<meta =
name=3D3D"Generator" content=3D3D"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=3D
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=3D3D"edit" =
spidmax=3D3D"1026" />
</xml><![endif]--><!--[if gte =
mso 9]><xml>
 <o:shapelayout v:ext=3D3D"edit">
 =
 <o:idmap v:ext=3D3D"edit" data=3D3D"1" />
 =
</o:shapelayout></xml><![endif]-->
</head>
<=
br><body lang=3D3D"EN-US" link=3D3D"blue" =
vlink=3D3D"purple">

<div =
class=3D3D"Section1">

<p =
class=3D3D"MsoNormal">Hi,<o:p></o:p></p>

<p=
 =
class=3D3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D3D"MsoNormal">This is the first time I have carefully =
read through=3D
 the
draft, and I have a bunch of questions for =
the IVR control =
package:<o:p></o=3D
:p></p>

<p =
class=3D3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D3D"MsoListParagraph" =
style=3D3D"text-indent:-.25in;mso-list:l0 level=3D
1 =
lfo2"><![if !supportLists]><span =
style=3D3D"mso-list:Ignore">-<span style=3D
=3D3D"font:7.0pt =
&quot;Times New =
Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
;=3D
nbsp;&nbsp;&nbsp;&nbsp;
</span></span>&=
lt;![endif]>Why can=3D92t &lt;dialogterminate&gt; result in =
an
&lt;dialogexit&gt; event for PREPARED and STARTING state =
while this is done=3D
 for
STARTED state only? If PREPARED state =
can generate dialogexit from a timeou=3D
t,
why can=3D92t it =
generate a dialogexit from a =
dialogterminate?<o:p></o:p></p>

<p =
class=3D3D"MsoListParagraph" style=3D3D"text-indent:-.25in;mso-list:l0 =
level=3D
1 lfo2"><![if !supportLists]><span =
style=3D3D"mso-list:Ignore">-<span style=3D
=3D3D"font:7.0pt =
&quot;Times New =
Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
;=3D
nbsp;&nbsp;&nbsp;&nbsp;
</span></span>&=
lt;![endif]>Can the preparation duration for a prepared dialog =
=3D
be
set in dialogprepare? The recommended value of 30s seems to =
be fairly short=3D
 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=3D
 the
dialog to =
make sure the dialog is ready to go (and making sure a VXML page =
=3D
is
well formed) and then I would place the outbound call. =
It=3D92s 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=3D3D"MsoListParagraph" style=3D3D"text-indent:-.25in;mso-list:l0 =
level=3D
1 lfo2"><![if !supportLists]><span =
style=3D3D"mso-list:Ignore">-<span style=3D
=3D3D"font:7.0pt =
&quot;Times New =
Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
;=3D
nbsp;&nbsp;&nbsp;&nbsp;
</span></span>&=
lt;![endif]>Section 4.2.2 =3D96 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=3D
? Of
course this wouldn=3D92t work if the =
control channel is a dedicated one
=3D96 I think it would be a =
syntactic sugar to have such a =
shortcut.<o:p></o:=3D
p></p>

<p =
class=3D3D"MsoListParagraph" style=3D3D"text-indent:-.25in;mso-list:l0 =
level=3D
1 lfo2"><![if !supportLists]><span =
style=3D3D"mso-list:Ignore">-<span style=3D
=3D3D"font:7.0pt =
&quot;Times New =
Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
;=3D
nbsp;&nbsp;&nbsp;&nbsp;
</span></span>&=
lt;![endif]>There is a typo in the example of section =
4.2.2.1.1=3D
:<o:p></o:p></p>

<p =
class=3D3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D3D"MsoNormal"><span =
style=3D3D"font-size:10.0pt;font-family:&quot;Co=3D
urier =
New&quot;">...<o:p></o:p></span></p>
<p class=3D3D"MsoNormal"><span =
style=3D3D"font-size:10.0pt;font-family:&quot;Co=3D
urier =
New&quot;">&nbsp;&nbsp;&nbsp;
&lt;subscribe&=
gt;<o:p></o:p></span></p>

<p =
class=3D3D"MsoNormal"><span =
style=3D3D"font-size:10.0pt;font-family:&quot;Co=3D
urier =
New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;
&lt;dmtf=
not

= --Apple-Mail-8-449461526-- From scott.mcglashan@hp.com Fri Feb 19 10:53:56 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE393A8009 for ; Fri, 19 Feb 2010 10:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.1 X-Spam-Level: X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upPRVg8FVspR for ; Fri, 19 Feb 2010 10:53:55 -0800 (PST) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by core3.amsl.com (Postfix) with ESMTP id B95903A7D7D for ; Fri, 19 Feb 2010 10:53:54 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id ACB912C116; Fri, 19 Feb 2010 18:55:41 +0000 (UTC) Received: from [192.168.0.111] (21.58.227.87.static.ang.siw.siwnet.net [87.227.58.21]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id 29E7F10004; Fri, 19 Feb 2010 18:55:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-3-535715048 From: Scott McGlashan In-Reply-To: <000001cab111$ae4f6680$0aee3380$@com> Date: Fri, 19 Feb 2010 19:55:23 +0100 Message-Id: <37238266-CF4F-49CB-AAF1-341877470AB8@hp.com> References: <059AF07365DC474393A19A3AF187DF74051E1ACA@NAHALD.us.int.genesyslab.com> <000001cab111$ae4f6680$0aee3380$@com> To: Henry Lum X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Cc: "mediactrl@ietf.org" Subject: Re: [MEDIACTRL] Questions on draft-ietf-mediactrl-ivr-control-package X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 18:53:56 -0000 --Apple-Mail-3-535715048 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 >=20 > - Why can=3D92t result in an = event fo=3D > r PREPARED and STARTING state while this is done for STARTED state = only? If=3D > PREPARED state can generate dialogexit from a timeout, why can=3D92t = it gene=3D > rate a dialogexit from a dialogterminate? >=20 > [SMCG] The 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 = payload to the 410 response when the AS terminates the = dialog, but I'm not clear it adds anything to the current design. >=20 > [HL] I understand that 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 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 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. =20 > - Can a dialog prefetch all the media prompts inside the = dialog an=3D > d then report an error when any of the fetch fails? This is one thing = I am =3D > having problem with MSML is that you can only fail during execution = and the=3D > control client have to intelligently resume where the failure happens, = thu=3D > s adding complexity to the control client. If the control client knows = one =3D > of the prompts fail to fetch, it would be easier for the control = client to =3D > try an alternate prompt altogether rather than having the prompt to = fail af=3D > ter playing the fifth wav file. >=20 > [SMCG] With a command, any fetch failures can be = reported using a 409 error response code. If the resource fails during = executing, the MS sends a 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. >=20 > [HL] Does go and fetch all the external prompts = defined inside

Scott

- = Why can=3D92t = <dialogterminate> result in an <dialogexit> event fo=3D
r = PREPARED and STARTING state while this is done for STARTED state only? = If=3D
PREPARED state can generate dialogexit from a timeout, why = can=3D92t it gene=3D
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.

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

- = Can a dialog = prefetch all the media prompts inside the dialog an=3D
d then report = an error when any of the fetch fails? This is one thing I am =3D
having= problem with MSML is that you can only fail during execution and = the=3D
control client have to intelligently resume where the failure = happens, thu=3D
s adding complexity to the control client. If the = control client knows one =3D
of the prompts fail to fetch, it would = be easier for the control client to =3D
try an alternate prompt = altogether rather than having the prompt to fail af=3D
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.

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

- = Am I allowed to = define more than one <prompt> inside <dialog> so=3D
that = I can define the first <prompt> to be bargein=3D3Dfalse, and the = second=3D
one with bargin=3D3Dtrue? The execution model for = <dialog> (#4 in 4.3.1) is =3D
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=3D"prompt" minOccurs=3D"0"

= maxOccurs=3D"1" /

[HL] So the = answer is no. Would be it better to remove maxOccurs=3D=941=94 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.

- = The definition of = <par> is a bit sketchy here. Should the child =3D
elements of = <par> target which <stream> it can target the output on? If = the=3D
re is no target, then how does MS know which stream it should = place the out=3D
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.

[HL] Okay this is fine =96 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?

- = If <control> = is active for a <prompt>, does it mean bargein has =3D
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.

[HL] I don=92t think active = control always terminate a prompt. An example is speedup/volumeupkey =96 = 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.

- =          Just to be clear = when <grammar> is defined in <collect>, does it=3D
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!).

[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-co= ntrol-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-co= ntrol-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).

How do I model a = different prompt for noinput and nomatch without having=3D
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.

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

= --Apple-Mail-3-535715048-- From Scott.McGlashan@hp.com Fri Feb 19 11:28:26 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414C33A7CCD; Fri, 19 Feb 2010 11:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdhzlMpUVN6L; Fri, 19 Feb 2010 11:28:25 -0800 (PST) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by core3.amsl.com (Postfix) with ESMTP id DB4B93A7349; Fri, 19 Feb 2010 11:28:24 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id E13832C0EF; Fri, 19 Feb 2010 19:30:11 +0000 (UTC) Received: from [192.168.0.111] (21.58.227.87.static.ang.siw.siwnet.net [87.227.58.21]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id 95CC610003; Fri, 19 Feb 2010 19:30:10 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-4-537785269 From: Scott McGlashan In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC14DF3715661@EUSAACMS0703.eamcs.ericsson.se> Date: Fri, 19 Feb 2010 20:29:53 +0100 Message-Id: <7AB7F5C8-8F15-45C3-9C4A-9AFC6A5FFC5C@hp.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC14DF3715661@EUSAACMS0703.eamcs.ericsson.se> To: Suresh Krishnan X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Cc: General Area Review Team , draft-ietf-mediactrl-mixer-control-package.all@tools.ietf.org, mediactrl@ietf.org Subject: Re: [MEDIACTRL] Gen-ART review of draft-ietf-mediactrl-mixer-control-package-10.txt X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 19:28:26 -0000 --Apple-Mail-4-537785269 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Suresh, I'm one of the editors of this specification. I've applied your = editorial comments but not your minor comment about the use of the term = 'crop'. The name for these layouts is defined in the XCON data model = specification which the mixer spec normatively references. So while I = can see your point about strict use of the term, I'm reluctant to change = the name in the mixer specification. Let us know if you disagree. thanks again for your review. Scott On 11 Feb 2010, at 23:05, Suresh Krishnan wrote: > I am the assigned Gen-ART reviewer for > draft-ietf-mediactrl-mixer-control-package-10.txt > =20 > For background on Gen-ART, please see the FAQ at = . > =20 > Please resolve these comments along with any other Last Call comments = you may receive. > =20 > Summary: This draft is ready for publication as Proposed Standard but = I have a few editorial comments. > =20 > Minor > =3D=3D=3D=3D=3D > =20 > * The term "crop" used in section 4.2.1.4.2.1. is counter-intuitive. = Crop usually means cutting away part > of the picture to get the desired size and not stretching/shrinking = it. Can you change the name to > dual-view-resize or something similar? > =20 > Editorial > =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > * Section 4.2 penultimate paragraph > =20 > s/operaton/operation/ > =20 > * Section 4.2.1.4.1 > =20 > s/partipicant/participant/g > =20 > * Section 4.6.6 > =20 > s/formated/formatted/ > =20 > Thanks > Suresh > =20 --Apple-Mail-4-537785269 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi = Suresh,

I'm one of the editors = of this specification. I've applied your editorial comments but not your = minor comment about the use of the term 'crop'. The name for these = layouts is defined in the XCON data model specification which the mixer = spec normatively references. So while I can see your point about = strict use of the term, I'm reluctant to change the name in the mixer = specification.

Let us know if you = disagree.

thanks again for your = review.

Scott

On 11 Feb 2010, at 23:05, Suresh Krishnan wrote:

I am the assigned Gen-ART reviewer = for
draft-ietf-mediactrl-mixer-control-package-10.txt
=
For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.htm= l>.

Please resolve these = comments along with any other Last Call comments you may = receive.

Summary: This draft is ready for = publication as Proposed Standard but I have a few editorial = comments.

Minor
=3D=3D=3D=3D=3D
=

* The term "crop" used in section 4.2.1.4.2.1. is = counter-intuitive. Crop usually means cutting away part
of the = picture to get the desired size and not stretching/shrinking it. Can you = change the name to
dual-view-resize or something = similar?

Editorial
=3D=3D=3D=3D=3D=3D= =3D=3D=3D

* Section 4.2 penultimate = paragraph

s/operaton/operation/
= ;
* Section = 4.2.1.4.1

s/partipicant/participant/g

* Section = 4.6.6

s/formated/formatted/

Thanks
Suresh

= = --Apple-Mail-4-537785269-- From Scott.McGlashan@hp.com Fri Feb 19 12:36:38 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329323A7FF2 for ; Fri, 19 Feb 2010 12:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.524 X-Spam-Level: X-Spam-Status: No, score=-104.524 tagged_above=-999 required=5 tests=[AWL=2.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWrM24iUCSsV for ; Fri, 19 Feb 2010 12:36:36 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id 9D9753A785D for ; Fri, 19 Feb 2010 12:36:36 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id E36B23802D; Fri, 19 Feb 2010 20:38:23 +0000 (UTC) Received: from [192.168.0.111] (21.58.227.87.static.ang.siw.siwnet.net [87.227.58.21]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id 620D210003; Fri, 19 Feb 2010 20:38:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-5-541877070 From: Scott McGlashan In-Reply-To: <059AF07365DC474393A19A3AF187DF7405277F69@NAHALD.us.int.genesyslab.com> Date: Fri, 19 Feb 2010 21:38:05 +0100 Message-Id: References: <059AF07365DC474393A19A3AF187DF7405277F69@NAHALD.us.int.genesyslab.com> To: Henry Lum X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Cc: "mediactrl@ietf.org" Subject: Re: [MEDIACTRL] Questions for draft-ietd-mediactrl-mixer-control-package X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:36:38 -0000 --Apple-Mail-5-541877070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Henry, thanks for the mixer comments and again apologies for my delay in = responding.=20 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.=20 Let me know if you need further information or have an issue with a = response. Scott On 11 Jan 2010, at 23:33, Henry Lum wrote: > Hi, > =20 > I have a bunch of questions for the mixer control package: > =20 > - When is called, what happens to a = dialog that is connected to the conference? It looks like the dialog = will receive a rather than a , but it=92s a = bit unclear in the text in section 4.2.1.3. [SMCG] Right. The dialog is terminated by the MS and a = generated. It isn't clear to me that the mixer spec should talk about = dialogs (whereas the IVR spec does talk about conferences). If you think = we should add some wording in the IVR spec, please send a suggestion.=20 > - Can conference be destroyed automatically when the last = participant has left () from the conference? [SMCG] No. The AS needs to explicitly destroy the conference.=20 > - I see that has a status code to timeout a = conference with a maximum duration, is this system specific? [SMCG] Yes. The spec doesn't provide a mechanism to set the maximum = duration but simply allows an MS to indicate this exit reason. > - Can I add my own audio mixing policy by extending the = type attribute? Looks like I can do this with = . [SMCG] Right. If the MS doesn't understand your type, it can send the = appropriate error response. > - When an automatic mixing is applied with , would = show up as a conference or just a bunch of joins? [SMCG] Not quite sure if I get this. If you create a conference it is = audited as a conference mixer; otherwise, explicit s as join = mixers. > - I find the wording for direction to be a bit too = much like SDP because the word sendonly implies it=92s only sending, but = at the same time you can also use another to reference the = reverse stream with recvonly. I think we should use plain language like = =93id1-to-id2=94, =93id2-to-id1=94, =93both=94, for sendonly, recvonly, = and sendrecv, respectively. [SMCG] We didn't have SDP in mind when we came up with the terms = originally (probably CCXML). I can see what you mean but I'm not sure = that 'id1-to-id2', etc are actually clearer and the values are then = different from those used in the IVR package . If others on = the WG mailing list prefer your suggested terms, then I'll change them.=20= > - For , there is one statement that says =93It = MUST NOT change the configuration of any streams not included as child = elements.=94, but then later in the examples part contradicts with this = statement. I actually agree with the example because it=92s simpler, and = that it means a changes the entire configuration of the = existing join and whatever the child elements defined in modifyjoin will = become the new configuration of the join. [SMCG] Good catch.=20 *** PROPOSED CHANGE. can affect streams not explicitly = mentioned.=20 from=20 The MS MUST configure the streams that are included within = to that stated by the child elements. It MUST NOT change the = configuration of any streams not included as child elements. to The MS MUST configure the streams that are included within = to that stated by the child elements.=20 > - Section 4.2.2.5.2 =96 can we simplify the tones attribute = with a default value? For example, the default would be to clamp out all = DTMF tones. [SMCG] Sounds reasonable, although it will require a XML schema change!=20= *** PROPOSED CHANGE: Add a default to :=20 from=20 tones: A space-separated list of the tones to remove. The attribute is = mandatory. to=20 tones: A space-separated list of the tones to remove. The attribute is = optional. The default value is "1 2 3 4 5 6 7 8 9 0 * # A B C D" (i.e. = all DTMF tones removed). > - Section 4.2.2.5.3 =96 What is the exact naming of a region? = I see that in this draft it=92s called 1,2,3.., while in the IVR package = it is called r1. [SMCG] Really up to layout to determine the names. I've changed the name = in the IVR package from 'r1' to '1'.=20 > =20 > Thanks > Henry > =20 >=20 >=20 > 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. --Apple-Mail-5-541877070 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Henry,

thanks for the = mixer comments and again 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 11 Jan 2010, at 23:33, Henry Lum wrote:

Hi,
I have a bunch of questions for the = mixer control package:
- When = <destroyconference> is called, what happens to a dialog that is = connected to the conference? It looks like the dialog will receive a = <dialogexit> rather than a <unjoin-notify>, but it=92s a bit = unclear in the text in section = 4.2.1.3.

[SMCG] = Right. The dialog is terminated by the MS and a <dialogexit> = generated. It isn't clear to me that the mixer spec should talk about = dialogs (whereas the IVR spec does talk about conferences). If you think = we should add some wording in the IVR spec, please send a = suggestion.

- Can = conference be destroyed automatically when the last participant has left = (<unjoin>) from the = conference?

[SMCG= ] No. The AS needs to explicitly destroy the = conference.

- I see that = <conferenceexit> has a status code to timeout a conference with a = maximum duration, is this system = specific?

[SMCG] = Yes. The spec doesn't provide a mechanism to set the maximum duration = but simply allows an MS to indicate this exit = reason.

- Can I add my = own audio mixing policy by extending the <audio-mixing> type = attribute? Looks like I can do this with = <video-switch>.

[SMCG] Right. If the MS doesn't understand your type, it can send = the appropriate error response.

- When an = automatic mixing is applied with <join>, would = <auditresponse> show up as a conference or just a bunch of = joins?

[SMCG] = Not quite sure if I get this. If you create a conference it is audited = as a conference mixer; otherwise, explicit <join>s as join = mixers.

- I find the = wording for <stream> direction to be a bit too much like SDP = because the word sendonly implies it=92s only sending, but at the same = time you can also use another <stream> to reference the reverse = stream with recvonly. I think we should use plain language like = =93id1-to-id2=94, =93id2-to-id1=94, =93both=94, for sendonly, recvonly, = and sendrecv, = respectively.

[SM= CG] We didn't have SDP in mind when we came up with the terms originally = (probably CCXML). I can see what you mean but I'm not sure that = 'id1-to-id2', etc are actually clearer and the values are then different = from those used in the IVR package <direction>. If = others on the WG mailing list prefer your suggested terms, then I'll = change them.

- For = <modifyjoin>, there is one statement that says =93It MUST NOT = change the configuration of any streams not included as child = elements.=94, but then later in the examples part contradicts with this = statement. I actually agree with the example because it=92s simpler, and = that it means a <modifyjoin> changes the entire configuration of = the existing join and whatever the child elements defined in modifyjoin = will become the new configuration of the = join.

[SMCG] = Good catch.

*** PROPOSED CHANGE. = <modifyjoin> can affect streams not explicitly = mentioned.

from

<= div>The MS MUST configure the streams that are included = within <modifyjoin> to that stated by the child elements. It MUST = NOT change the configuration of any streams not included as child = elements.

The MS MUST = configure the streams that are included within <modifyjoin> to = that stated by the child elements.

- Section = 4.2.2.5.2 =96 can we simplify the tones attribute with a default value? = For example, the default would be to clamp out all DTMF = tones.

[SMCG] = Sounds reasonable, although it will require a XML schema = change!

*** PROPOSED = CHANGE: Add a default to = <clamp>:

from

tones:: A space-separated = list of the tones to remove. The attribute is = mandatory.

tones:
A space-separated list of the = tones to remove. The attribute is optional. The default value is "1 2 3 = 4 5 6 7 8 9 0 * # A B C D" (i.e. all DTMF tones = removed).

- Section = 4.2.2.5.3 =96 What is the exact naming of a region? I see that in this = draft it=92s called 1,2,3.., while in the IVR package it is called = r1.

[SMCG] = Really up to layout to determine the names. I've changed the name in the = IVR package from 'r1' to '1'.

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

= --Apple-Mail-5-541877070-- From Henry.Lum@alcatel-lucent.com Fri Feb 19 12:53:20 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD61F3A785D for ; Fri, 19 Feb 2010 12:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZMRzdNEQfr3 for ; Fri, 19 Feb 2010 12:53:12 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 122E43A7EDF for ; Fri, 19 Feb 2010 12:53:11 -0800 (PST) Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o1JKsw4N019022; Fri, 19 Feb 2010 14:54:58 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o1JKsvIY012583; Fri, 19 Feb 2010 14:54:57 -0600 (CST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id o1JKsuMN006974; Fri, 19 Feb 2010 12:54:56 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 12:54:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB1A5.CAA6FC26" Date: Fri, 19 Feb 2010 12:54:55 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74054F8669@NAHALD.us.int.genesyslab.com> In-Reply-To: <37238266-CF4F-49CB-AAF1-341877470AB8@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEDIACTRL] Questions ondraft-ietf-mediactrl-ivr-control-package Thread-Index: AcqxlSfKN5fHQhLBT0ShsvH+mCSgrQAC1C3Q References: <059AF07365DC474393A19A3AF187DF74051E1ACA@NAHALD.us.int.genesyslab.com><000001cab111$ae4f6680$0aee3380$@com> <37238266-CF4F-49CB-AAF1-341877470AB8@hp.com> From: "Henry Lum" To: "Scott McGlashan" X-OriginalArrivalTime: 19 Feb 2010 20:54:56.0556 (UTC) FILETIME=[CAEA66C0:01CAB1A5] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 Cc: mediactrl@ietf.org Subject: Re: [MEDIACTRL] Questions ondraft-ietf-mediactrl-ivr-control-package X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:53:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB1A5.CAA6FC26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, =20 Please see my responses below. =20 Thanks Henry =20 [SMCG] The group had discussed this behavior in the past and agreed that it was important that 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 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. =20 =20 [[hlum]] Okay, I accept the shortcut with the 410 response to optimize the need for . However, in the PREPARED state, when is called and 200 response is received, shall I expect a in this state? =20 =20 [SMCG] I thought this was clear - the paragraph references 'retrieving external .. resources' and a is a one or more (media) resources. In 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 with a 409 status code.' If you have a specific suggestion, please send.=20 =20 [[hlum]] I got confused about the differences between VXML (external) and resources ( tag). Can we modify the wording in to: Dialog preparation consists of (a) retrieving external dialog document and/or resources referenced by the

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 l= ast event sent when a started dialog is terminated by the MS for whatever rea= son. 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 whic= h dialog it was terminating.

<= /p>

[[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 e= xpect a <dialogexit> in this state?

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

<= /p>

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

Dialog preparation consists of (a) retrieving external dialog=
 document and/or resources referenced by the <dialog> IVR dialog el=
ements, and (b) validating the dialog document syntactically and semantic=
ally.

[SMCG] Previously we've taken multiple prompt suppor= t as outside the requirements scope of the dialog language in this spec (tryin= g to keep it simple). I'd have a concern that adding it at this stage would re= quire multiple changes in the syntax and semantics including dialog execution m= odel. The bargein on/off use case can be addressed already with a VoiceXML dial= og type, so I'd be reluctant to add it at this late stage. <= /p>

<= /p>

[[hlum]] Okay this is fine. Let’s keep it simple.<= /o:p>

[SMCG] Right - it is = the responsibility of the MS to map the <media> playback to the appropr= iate 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 th= e end of 4.3.1.1.3 to mention this?

[SMCG] Do you have a = specific suggestion?

<= /p>

[[hlum]] Let’s add to the <media> element referen= ced in this section:

<media>:  specifies a media resource (see Section 4.3.1.5) to play; it is up to the medi=
a server to assign the <media> playback to the appropriate media st=
ream 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 thoug= ht it simply takes priority over the characters in the internal or custom gramm= ar (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. escapi= ng simply restarts the collection without clearing the buffer).

<= /p>

[[hlum]] For (a), if we don’t override the grammar, the= n what happens if this digits happens to match both the escapekey and the gramma= r 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 autom= atically clear the digit buffer again as if <collect> is executed again?

[SMCG] If you have specific wording suggestions, ple= ase 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 wi= ll be a simple fix.

<= /p>

[[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 exe= cution 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 stopp= ed, dtmf, maxtime, finalsilence). I think these are relatively simple fixes to the markups that can make the dialog more useful without resorting to microma= nagement of dialogs or requiring the use of VXML.

Hi Scott,

Please see my responses inline.

Henry

[SMCG] Right. The dialog is terminated by the MS and= a <dialogexit> generated. It isn't clear to me that the mixer spec sh= ould talk about dialogs (whereas the IVR spec does talk about conferences). If= you think we should add some wording in the IVR spec, please send a suggestion.

[HL] IVR spec mentions that status=3D2 in <dialog= exit> means the dialog is terminated because a conference is terminated so it’s= clear in the IVR spec. I just wonder mixer spec should mention this briefly in = the last paragraph of 4.2.1.3.

- When an automatic mixing is applied w= ith <join>, would <auditresponse> show up as a conference or just= a bunch of joins?

[SMCG] Not quite sure if I get this. If you create a= conference it is audited as a conference mixer; otherwise, explicit <join>s as join mixers.

[HL] What I mean is that when implicit or automatic = mixing is applied with <join> (as described in 4.2.2.1), there is no actua= l conference object created and no conferenceid assigned. In other words, n= o conference objects will show up in audit as a result of implicit mixing.<= br>
=

[SMCG] We didn't have SDP in mind when we came up wi= th the terms originally (probably CCXML). I can see what you mean but I'm not su= re that 'id1-to-id2', etc are actually clearer and the values are then diffe= rent from those used in the IVR package <direction>. If other= s on the WG mailing list prefer your suggested terms, then I'll change them.&n= bsp;

[HL] I’m just nitpicking with the choice of na= mes in the attributes since I find that having id1 and id2 in <join> origi= nated from CCXML makes understanding the directionality of <stream> a bit= confusing. I actually prefer the directionality defined in the <join&g= t; itself like <join from=3D”id1” to=3D”id2”>&= lt;stream media=3D”audio” duplex=3D”true”/></join>

The MS MUST configure the streams that are included within <modifyjoin>= to that stated by the child elements.

[HL] looks good to me

t= ones:

A space-separated list of the tones to remove. The attribute is optional. T= he default value is "1 2 3 4 5 6 7 8 9 0 * # A B C D" (i.e. = all DTMF tones removed).

<= o:p>

[= HL] Looks good to me.

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 informat= ion 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 m= edium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent an= d/or its affiliated entities.<ATT00001..txt>

CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CAB3D5.5F86292E-- From eburger@standardstrack.com Tue Feb 23 04:25:46 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BAF28C1BF for ; Tue, 23 Feb 2010 04:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvx3VCTD+gPY for ; Tue, 23 Feb 2010 04:25:46 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 0EA9A28C114 for ; Tue, 23 Feb 2010 04:25:46 -0800 (PST) Received: from rrcs-24-199-33-18.west.biz.rr.com ([24.199.33.18] helo=[10.0.0.115]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Njtrf-0007Y1-U1 for mediactrl@ietf.org; Tue, 23 Feb 2010 04:27:48 -0800 From: Eric Burger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 04:27:47 -0800 Message-Id: <6669E357-2C50-4F87-90F8-C5AAB1AF851F@standardstrack.com> To: mediactrl@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [MEDIACTRL] MRB: DTMF Support X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 12:25:46 -0000 A question came up during the review of MRB. Currently, one of the = values for DTMF support in the consumer and media server interface API = is "INFO". There are at least three incompatible INFO usages for = transporting DTMF and we are about to get a fourth. More importantly, I = am not aware of any media server that can consume or generate INFO's for = DTMF transport. Anyone mind if we drop the "INFO" value for DTMF = support? The editors put it in just because they were thinking, "how = does DTMF go through networks?" not "how do media servers see and handle = DTMF?" Note that by "INFO for DTMF," we mean the use of an INFO method to = transport the digit information. We do NOT mean the use of a media = control protocol over INFO. Thus, while both MSCML and MSML use INFO to = *report* digits, they do NOT use INFO to *transport* digits. So, a quick poll (responses requested!): 1. Does your media server accept or generate INFO for DTMF transport? 1a. If Yes to #1, what INFO payload format and how do you determine what = payload to receive / send? 2. Would you miss removing INFO as a value for DTMF transport? From eburger@standardstrack.com Tue Feb 23 04:25:47 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F89C28C114 for ; Tue, 23 Feb 2010 04:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+tEsbdj34pF for ; Tue, 23 Feb 2010 04:25:46 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id A3A4328C1BA for ; Tue, 23 Feb 2010 04:25:46 -0800 (PST) Received: from rrcs-24-199-33-18.west.biz.rr.com ([24.199.33.18] helo=[10.0.0.115]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Njtrg-0007Y1-LJ for mediactrl@ietf.org; Tue, 23 Feb 2010 04:27:48 -0800 From: Eric Burger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 04:27:48 -0800 Message-Id: <7E9DA7A1-A582-4B99-A32F-0D309F0B4459@standardstrack.com> To: mediactrl@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [MEDIACTRL] MRB: Extensible Fields X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 12:25:47 -0000 Right now the schema for the MRB publisher and consumer interfaces is = not extensible. Do we need them to be? The list of fixed values are: msstatus: {active, deactivated, unavailable} To me, this closed enumeration makes sense. What about you? action: {create, update, remove} To me, this closed enumeration makes sense. What about you? actions: {encoding, decoding, passthrough} Is this OK to be a closed enumeration? dtmf: {RFC4733, Media} [INFO is in the list in mrb-03, but that is the = subject of another email] To me, I think this needs to be extensible. We know (think?) there will = be a DTMF Info-Package, possibly. vxml: {RFC5552, IVR-Package} I'm hesitating here. On the one hand, I cannot imagine new packages. = On the other hand, I could envision someone wanting to use MEDIACTRL to = launch MSML or MSCML sessions. What do people on the list think? Now comes the hard part: what if we do allow for extensibility? How = does that get signaled? Do we need to signal extensions, or just let = the MRB barf or ignore or default unrecognized values? Thoughts welcome.= From ben@estacado.net Tue Feb 23 19:16:42 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A1828C40A; Tue, 23 Feb 2010 19:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=-0.992, BAYES_00=-2.599, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pumlJPU59ao; Tue, 23 Feb 2010 19:16:39 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 5DB3028C16F; Tue, 23 Feb 2010 19:16:37 -0800 (PST) Received: from [10.0.1.12] (adsl-68-94-45-145.dsl.rcsntx.swbell.net [68.94.45.145]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o1O3IN5i049436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Feb 2010 21:18:31 -0600 (CST) (envelope-from ben@estacado.net) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 21:18:18 -0600 Message-Id: To: rai@ietf.org, Chris Boulton , lorenzo.miniero@unina.it Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: mediactrl@ietf.org Subject: [MEDIACTRL] RAI-ART Review of draft-ietf-mediactrl-mrb-03 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 03:16:43 -0000 I am the assigned RAI-ART reviewer for draft-ietf-mediactrl-mrb-03. For background on RAI-ART, please see the FAQ at . Please resolve these comments along with any other comments you may = receive. This draft is on the right track for publication as a proposed standard, = but there are issues that should be considered first. Disclaimer: This draft has 40+ pages of XML schema definitions. I did = not attempt to verify them beyond a cursory look. Hopefully they can be = verified mechanically (by someone with deeper XML knowledge than me) = prior to publication. Architectural Comments: -- The publish interface defines yet another way to do subscriptions. = Since it's based on mediactrl, this means using a SIP dialog to = establish a mediactrl session for these subcriptions. The data in this = case feels like metadata related to signaling more than content. Did = the working group consider the possibility of using SIP-events? (RFC = 3265)? If so, what was the motivation for creating something new? = (Perhaps other mediactrl packages already have subscription semantics, = and this follows their precedents? It's been a long time since I read = the IVR package) -- You note that the consumer inline interface can be equivalent to the = query interface when the MRB sends a 3XX response. Why, then, do you = propose two ways to accomplish the same thing? It seems like this just = makes life harder for everyone. Implementations will have to implement = both methods in order to be interoperable with any other arbitrary = implementation. -- The inline approach to the consumer interface basically involves the = MRB acting as a b2bua to select downstream destinations according to the = app server preferences. This is very similar to the problem caller-prefs = [RFC 3841] set out to solve. Did the work group consider using = caller-prefs as the basis? -- section 4.2:=20 The IUMM requires the MRB to understand how to interpret the SIP = signaling and SDP offer normally intended for the MS. This means it has = to have the same application level knowledge as the MS. This creates = brittleness in the network. For example, if a new mediactrl feature is = invented that requires SDP extensions, the MRB must be updated, in = addition to the AS and MSs. This is generally counter to the end-to-end = principle of the internet architecture. Major Comments: -- 5.2.2:=20 I think you really need a required/supported option tag to indicate the = expected interpretation of the new body parts. You can't just infer the = application by the presence of the body parts, as future applications = could someday use the same MIME types. -- 5.2.2, first two items in first bullet list This use of multipart doesn't really work. You can't just specify SDP in = the first part, and msb-consumer in the 2nd. This breaks if combined = with other extensions that use other body parts or other multipart = types. You really need something like a multi-part related with an index = part, or a header field that contains reference to the mrb-consumer = part.=20 -- 5.2.3: You need some more "big picture" discussion about the lease mechanism. = Does "lease" imply the MRB is managing resources--i.e. keeping state of = allocated resources against available resources, etc, rather than simply = depending on the MS to provide the information? If so, can the MS and = the MRB get out of sync? Is it legal to have some access to a given MS = be direct, and other via the MRB? If there are multiple MRBs do they = need to share resource state? -- 5.2.3, definition: Are 409 and 410 the only allowed errors? Why a separate error codes that = only seem to differ as to the request type? Also, from experience in defining MSRP, I think it is a mistake to = choose error codes for other protocols to match those of SIP or HTTP. = This causes a lot of confusion in place the meanings are subtly = different. It also causes layer confusion (When someone says they got a = 409, is that a SIP 409, or an mrb-consumer 409?) Minor Comments: -- publish interface in general: How does an MRB know what MSs it should = query? Is this expected to be provisioned? -- section 5.1, 2nd paragraph: Can you provide a reference for the spec for "good engineering"? = Seriously, though, you're saying that the MRB can live with imprecise or = even stale information, and that operating on this imperfect information = will provide better results ( or more scaleability or less complexity) = than simply guessing. I'm not saying you're wrong, but I think that = proposal needs a little more analysis for me to accept it as axiomatic. -- section 5.1.1.4: What are the uniqueness requirements (scope, chance of collision, etc) = for "id"? (Question applies to all the ID attributes in this draft.) I think seqnumber needs some more explanation. How is it constructed? = Can the recipient infer anything about gaps in sequence numbers? Do you = have to worry about roll over? Do you have separate sequence spaces in = each direction (like CSeq for SIP?) What is the scope for "expires"? For example, does a the expiring state = survive the end of a mediactrl session? How is it handled if not = present? (Similar questions applies to all occurrences of "Expires" = attributes in the draft.) -- 5.1.4.* This entire section seems to enumerate the features for an MS. How do = new features get added? -- 5.1.4.5: I'm not sure I understand what a non-active session is. Do you mean = available ports, resources, etc that could be used for sessions? Is that = the right way to express available resources? (For example, how would = you express available CPU cycles in terms of available sessions?) I = think you mentioned this issue somewhere, but I'm not sure I agree that = you've found the right abstraction here. -- 5.1.4.7: What's the practical difference between deactivated and unavailable? -- 5.1.4.9: It's not clear to me what is for--can you elaborate? 5.1.4.10, "supported-format" What kind of name goes in the supported format. Is this a MIME type, or = some other managed namespace? (Similar questions apply for the values = for other "name" attributes in the draft, where the name spaces or = registries need to be defined.) -- 5.1.4.12: What goes in "name"? Are you picking from a registry? --5.1.4.13, "audio-mixing-modes" What sort of value does the "package" attribute carry? Is there a = registry for mediactrl package names? (This sort of issue occurs several more times. I'm going to quite = commenting on it.) -- security considerations: It's worth discussing the fact that the IAMM model involves a b2bua = modifying SIP bodies. This impacts the ability to use any SIP security = feature that protects the body (e.g. 4474, s/mime, etc.) unless the MRB = intermediates the security association. Given that one of points of = using SIP for mediactrl in the first place was to reuse SIP features = when possible, I think this is an issue. The security considerations talk about channel security, but not so much = about authorization. I think it's important to make sure only authorized = application servers can get information about media servers, etc. -- 5.2.4, definition of Is the exclusion enforced by the schema? If not, should it be normative? Editorial Comments: -- idnits generates some warnings. -- General Comment: There's a lot of redundancy in this draft. A = procedures are often described several times. Many data elements are = described several times. Data elements that are either identical or very = close to identical between the publish and consumer interface are = described in detail for both interfaces, including in the schemas. It = makes sense to have a section that describes how the protocols work at a = high level, and another that describes them normatively, but that = distinction is not clear. The result is a very long document, that could = probably be considerably shorter with some editing. -- section 2, 2119 language: Why the BCP 15 reference? That's = "Deployment of the Internet White Pages Service"--is that really what = you meant? (BTW, that additional text confuses idnits when it's checking = for 2119 boilerplate.) -- Section 3, paragraph 1: "It is clear from Section 1 that the = MediaCtrl group will be producing a solution that must service a wide variety of deployment architectures." It is clear to whom? (making forward looking statements about what a WG = will solve is dangerous, at best--not to mention this one will date the = draft if it becomes an RFC.) -- section 5.1, first paragraph, 2nd sentence: Generally accepted by whom? I'm not sure what information this sentence = intends to convey. -- ... 2nd to last sentence: Perfect? Really? :-) (I'd suggest turning down the hype a bit.) -- section 5.1.1: That MUST is a statement of fact, not a normative requirement imposed by = _this_ spec. I suggest it be uncapitalized. -- section 5.1.1.4: Is (or can) the MUST requirement of mutual exclusivity expressed in the = schema? -- section 5.1.3.1, definition of "id" What is the "session"? Are we talking about the resulting subscription, = or the mediactrl session? -- section 5.1.4.2: Did you mean to say no child elements? Isn't = a child element? -- 5.1.4.14, supported-country-codes: Need a reference for ISO-3166-1 -- 5.2.3, definition of "action" It would help to separate the possible values into separate paragraphs, = sub-bullets, a table, or something. It's hard to can with the values = defined mid-paragraph. -- 5.3.2, 5th paragraph: s/IAMM/MRB ? s/fulfil/fulfill= From ben@estacado.net Tue Feb 23 20:17:23 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA9C28C204; Tue, 23 Feb 2010 20:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B9BY0WXJQg1; Tue, 23 Feb 2010 20:17:21 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id D6CD028C0EC; Tue, 23 Feb 2010 20:17:20 -0800 (PST) Received: from [10.0.1.12] (adsl-68-94-45-145.dsl.rcsntx.swbell.net [68.94.45.145]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o1O4JH9o059130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Feb 2010 22:19:22 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Tue, 23 Feb 2010 22:19:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Chris Boulton , lorenzo.miniero@unina.it X-Mailer: Apple Mail (2.1077) Cc: rai@ietf.org, mediactrl@ietf.org Subject: Re: [MEDIACTRL] [RAI] RAI-ART Review of draft-ietf-mediactrl-mrb-03 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 04:17:23 -0000 Oops, sorry, my mailer pulled up an old address for Chris. Trying = again... On Feb 23, 2010, at 9:18 PM, Ben Campbell wrote: > I am the assigned RAI-ART reviewer for draft-ietf-mediactrl-mrb-03. >=20 > For background on RAI-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other comments you may = receive. >=20 > This draft is on the right track for publication as a proposed = standard, but there are issues that should be considered first. >=20 > Disclaimer: This draft has 40+ pages of XML schema definitions. I did = not attempt to verify them beyond a cursory look. Hopefully they can be = verified mechanically (by someone with deeper XML knowledge than me) = prior to publication. >=20 > Architectural Comments: >=20 > -- The publish interface defines yet another way to do subscriptions. = Since it's based on mediactrl, this means using a SIP dialog to = establish a mediactrl session for these subcriptions. The data in this = case feels like metadata related to signaling more than content. Did = the working group consider the possibility of using SIP-events? (RFC = 3265)? If so, what was the motivation for creating something new? = (Perhaps other mediactrl packages already have subscription semantics, = and this follows their precedents? It's been a long time since I read = the IVR package) >=20 > -- You note that the consumer inline interface can be equivalent to = the query interface when the MRB sends a 3XX response. Why, then, do you = propose two ways to accomplish the same thing? It seems like this just = makes life harder for everyone. Implementations will have to implement = both methods in order to be interoperable with any other arbitrary = implementation. >=20 > -- The inline approach to the consumer interface basically involves = the MRB acting as a b2bua to select downstream destinations according to = the app server preferences. This is very similar to the problem = caller-prefs [RFC 3841] set out to solve. Did the work group consider = using caller-prefs as the basis? >=20 > -- section 4.2:=20 >=20 > The IUMM requires the MRB to understand how to interpret the SIP = signaling and SDP offer normally intended for the MS. This means it has = to have the same application level knowledge as the MS. This creates = brittleness in the network. For example, if a new mediactrl feature is = invented that requires SDP extensions, the MRB must be updated, in = addition to the AS and MSs. This is generally counter to the end-to-end = principle of the internet architecture. >=20 >=20 > Major Comments: >=20 > -- 5.2.2:=20 >=20 > I think you really need a required/supported option tag to indicate = the expected interpretation of the new body parts. You can't just infer = the application by the presence of the body parts, as future = applications could someday use the same MIME types. >=20 > -- 5.2.2, first two items in first bullet list >=20 > This use of multipart doesn't really work. You can't just specify SDP = in the first part, and msb-consumer in the 2nd. This breaks if combined = with other extensions that use other body parts or other multipart = types. You really need something like a multi-part related with an index = part, or a header field that contains reference to the mrb-consumer = part.=20 >=20 > -- 5.2.3: >=20 > You need some more "big picture" discussion about the lease mechanism. = Does "lease" imply the MRB is managing resources--i.e. keeping state of = allocated resources against available resources, etc, rather than simply = depending on the MS to provide the information? If so, can the MS and = the MRB get out of sync? Is it legal to have some access to a given MS = be direct, and other via the MRB? If there are multiple MRBs do they = need to share resource state? >=20 >=20 > -- 5.2.3, definition: >=20 > Are 409 and 410 the only allowed errors? Why a separate error codes = that only seem to differ as to the request type? >=20 > Also, from experience in defining MSRP, I think it is a mistake to = choose error codes for other protocols to match those of SIP or HTTP. = This causes a lot of confusion in place the meanings are subtly = different. It also causes layer confusion (When someone says they got a = 409, is that a SIP 409, or an mrb-consumer 409?) >=20 >=20 > Minor Comments: >=20 > -- publish interface in general: How does an MRB know what MSs it = should query? Is this expected to be provisioned? >=20 > -- section 5.1, 2nd paragraph: >=20 > Can you provide a reference for the spec for "good engineering"? = Seriously, though, you're saying that the MRB can live with imprecise or = even stale information, and that operating on this imperfect information = will provide better results ( or more scaleability or less complexity) = than simply guessing. I'm not saying you're wrong, but I think that = proposal needs a little more analysis for me to accept it as axiomatic. >=20 > -- section 5.1.1.4: >=20 > What are the uniqueness requirements (scope, chance of collision, etc) = for "id"? (Question applies to all the ID attributes in this draft.) >=20 > I think seqnumber needs some more explanation. How is it constructed? = Can the recipient infer anything about gaps in sequence numbers? Do you = have to worry about roll over? Do you have separate sequence spaces in = each direction (like CSeq for SIP?) >=20 > What is the scope for "expires"? For example, does a the expiring = state survive the end of a mediactrl session? How is it handled if not = present? (Similar questions applies to all occurrences of "Expires" = attributes in the draft.) >=20 > -- 5.1.4.* >=20 > This entire section seems to enumerate the features for an MS. How do = new features get added? >=20 > -- 5.1.4.5: >=20 > I'm not sure I understand what a non-active session is. Do you mean = available ports, resources, etc that could be used for sessions? Is that = the right way to express available resources? (For example, how would = you express available CPU cycles in terms of available sessions?) I = think you mentioned this issue somewhere, but I'm not sure I agree that = you've found the right abstraction here. >=20 > -- 5.1.4.7: >=20 > What's the practical difference between deactivated and unavailable? >=20 > -- 5.1.4.9: >=20 > It's not clear to me what is for--can you = elaborate? >=20 > 5.1.4.10, "supported-format" >=20 > What kind of name goes in the supported format. Is this a MIME type, = or some other managed namespace? (Similar questions apply for the values = for other "name" attributes in the draft, where the name spaces or = registries need to be defined.) >=20 > -- 5.1.4.12: >=20 > What goes in "name"? Are you picking from a registry? >=20 > --5.1.4.13, "audio-mixing-modes" >=20 > What sort of value does the "package" attribute carry? Is there a = registry for mediactrl package names? >=20 > (This sort of issue occurs several more times. I'm going to quite = commenting on it.) >=20 >=20 > -- security considerations: >=20 > It's worth discussing the fact that the IAMM model involves a b2bua = modifying SIP bodies. This impacts the ability to use any SIP security = feature that protects the body (e.g. 4474, s/mime, etc.) unless the MRB = intermediates the security association. Given that one of points of = using SIP for mediactrl in the first place was to reuse SIP features = when possible, I think this is an issue. >=20 > The security considerations talk about channel security, but not so = much about authorization. I think it's important to make sure only = authorized application servers can get information about media servers, = etc. >=20 > -- 5.2.4, definition of >=20 > Is the exclusion enforced by the schema? If not, should it be = normative? >=20 > Editorial Comments: >=20 > -- idnits generates some warnings. >=20 > -- General Comment: There's a lot of redundancy in this draft. A = procedures are often described several times. Many data elements are = described several times. Data elements that are either identical or very = close to identical between the publish and consumer interface are = described in detail for both interfaces, including in the schemas. It = makes sense to have a section that describes how the protocols work at a = high level, and another that describes them normatively, but that = distinction is not clear. The result is a very long document, that could = probably be considerably shorter with some editing. >=20 > -- section 2, 2119 language: Why the BCP 15 reference? That's = "Deployment of the Internet White Pages Service"--is that really what = you meant? (BTW, that additional text confuses idnits when it's checking = for 2119 boilerplate.) >=20 > -- Section 3, paragraph 1: "It is clear from Section 1 that the = MediaCtrl group will be producing > a solution that must service a wide variety of deployment > architectures." >=20 > It is clear to whom? (making forward looking statements about what a = WG will solve is dangerous, at best--not to mention this one will date = the draft if it becomes an RFC.) >=20 > -- section 5.1, first paragraph, 2nd sentence: >=20 > Generally accepted by whom? I'm not sure what information this = sentence intends to convey. >=20 > -- ... 2nd to last sentence: >=20 > Perfect? Really? :-) (I'd suggest turning down the hype a bit.) >=20 > -- section 5.1.1: >=20 > That MUST is a statement of fact, not a normative requirement imposed = by _this_ spec. I suggest it be uncapitalized. >=20 > -- section 5.1.1.4: >=20 > Is (or can) the MUST requirement of mutual exclusivity expressed in = the schema? >=20 > -- section 5.1.3.1, definition of "id" >=20 > What is the "session"? Are we talking about the resulting = subscription, or the mediactrl session? >=20 > -- section 5.1.4.2: Did you mean to say no child elements? Isn't = a child element? >=20 > -- 5.1.4.14, supported-country-codes: >=20 > Need a reference for ISO-3166-1 >=20 > -- 5.2.3, definition of "action" >=20 > It would help to separate the possible values into separate = paragraphs, sub-bullets, a table, or something. It's hard to can with = the values defined mid-paragraph. >=20 >=20 > -- 5.3.2, 5th paragraph: >=20 > s/IAMM/MRB ? >=20 > s/fulfil/fulfill > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From spencer@wonderhamster.org Wed Feb 24 07:40:22 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A77328C1D0; Wed, 24 Feb 2010 07:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=-1.289, BAYES_00=-2.599, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7YTid9ZOrNe; Wed, 24 Feb 2010 07:40:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D113428C1B9; Wed, 24 Feb 2010 07:40:20 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lpu63-1NEql70tFP-00fbO6; Wed, 24 Feb 2010 10:41:08 -0500 Message-ID: <9DA94620FA3B41A49BA78CDE30B29A1A@china.huawei.com> From: "Spencer Dawkins" To: "Ben Campbell" , "Chris Boulton" , References:

Date: Wed, 24 Feb 2010 09:40:59 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+xv2+glbdrSZaVn1K6Ia5t5TraMb/5qm49Wah bQOsjKjZYz4hOwb1zoYquwMW4aO7G1GT+aTTiomS1PcA6i9cpG htwoR06PVoZa7+Bz/ITFsdxaXYbSO6vaIIxvxub+Gw= Cc: rai@ietf.org, mediactrl@ietf.org Subject: Re: [MEDIACTRL] [RAI] RAI-ART Review of draft-ietf-mediactrl-mrb-03 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:40:22 -0000 Hi, Ben, Thank you very much for your careful review! Spencer ----- Original Message ----- From: "Ben Campbell" To: "Chris Boulton" ; Cc: ; Sent: Tuesday, February 23, 2010 10:19 PM Subject: Re: [MEDIACTRL] [RAI] RAI-ART Review of draft-ietf-mediactrl-mrb-03 > Oops, sorry, my mailer pulled up an old address for Chris. Trying again... > > On Feb 23, 2010, at 9:18 PM, Ben Campbell wrote: > >> I am the assigned RAI-ART reviewer for draft-ietf-mediactrl-mrb-03. >> >> For background on RAI-ART, please see the FAQ at >> . >> >> Please resolve these comments along with any other comments you may >> receive. >> >> This draft is on the right track for publication as a proposed standard, >> but there are issues that should be considered first. >> >> Disclaimer: This draft has 40+ pages of XML schema definitions. I did not >> attempt to verify them beyond a cursory look. Hopefully they can be >> verified mechanically (by someone with deeper XML knowledge than me) >> prior to publication. >> >> Architectural Comments: >> >> -- The publish interface defines yet another way to do subscriptions. >> Since it's based on mediactrl, this means using a SIP dialog to establish >> a mediactrl session for these subcriptions. The data in this case feels >> like metadata related to signaling more than content. Did the working >> group consider the possibility of using SIP-events? (RFC 3265)? If so, >> what was the motivation for creating something new? (Perhaps other >> mediactrl packages already have subscription semantics, and this follows >> their precedents? It's been a long time since I read the IVR package) >> >> -- You note that the consumer inline interface can be equivalent to the >> query interface when the MRB sends a 3XX response. Why, then, do you >> propose two ways to accomplish the same thing? It seems like this just >> makes life harder for everyone. Implementations will have to implement >> both methods in order to be interoperable with any other arbitrary >> implementation. >> >> -- The inline approach to the consumer interface basically involves the >> MRB acting as a b2bua to select downstream destinations according to the >> app server preferences. This is very similar to the problem caller-prefs >> [RFC 3841] set out to solve. Did the work group consider using >> caller-prefs as the basis? >> >> -- section 4.2: >> >> The IUMM requires the MRB to understand how to interpret the SIP >> signaling and SDP offer normally intended for the MS. This means it has >> to have the same application level knowledge as the MS. This creates >> brittleness in the network. For example, if a new mediactrl feature is >> invented that requires SDP extensions, the MRB must be updated, in >> addition to the AS and MSs. This is generally counter to the end-to-end >> principle of the internet architecture. >> >> >> Major Comments: >> >> -- 5.2.2: >> >> I think you really need a required/supported option tag to indicate the >> expected interpretation of the new body parts. You can't just infer the >> application by the presence of the body parts, as future applications >> could someday use the same MIME types. >> >> -- 5.2.2, first two items in first bullet list >> >> This use of multipart doesn't really work. You can't just specify SDP in >> the first part, and msb-consumer in the 2nd. This breaks if combined with >> other extensions that use other body parts or other multipart types. You >> really need something like a multi-part related with an index part, or a >> header field that contains reference to the mrb-consumer part. >> >> -- 5.2.3: >> >> You need some more "big picture" discussion about the lease mechanism. >> Does "lease" imply the MRB is managing resources--i.e. keeping state of >> allocated resources against available resources, etc, rather than simply >> depending on the MS to provide the information? If so, can the MS and the >> MRB get out of sync? Is it legal to have some access to a given MS be >> direct, and other via the MRB? If there are multiple MRBs do they need to >> share resource state? >> >> >> -- 5.2.3, definition: >> >> Are 409 and 410 the only allowed errors? Why a separate error codes that >> only seem to differ as to the request type? >> >> Also, from experience in defining MSRP, I think it is a mistake to choose >> error codes for other protocols to match those of SIP or HTTP. This >> causes a lot of confusion in place the meanings are subtly different. It >> also causes layer confusion (When someone says they got a 409, is that a >> SIP 409, or an mrb-consumer 409?) >> >> >> Minor Comments: >> >> -- publish interface in general: How does an MRB know what MSs it should >> query? Is this expected to be provisioned? >> >> -- section 5.1, 2nd paragraph: >> >> Can you provide a reference for the spec for "good engineering"? >> Seriously, though, you're saying that the MRB can live with imprecise or >> even stale information, and that operating on this imperfect information >> will provide better results ( or more scaleability or less complexity) >> than simply guessing. I'm not saying you're wrong, but I think that >> proposal needs a little more analysis for me to accept it as axiomatic. >> >> -- section 5.1.1.4: >> >> What are the uniqueness requirements (scope, chance of collision, etc) >> for "id"? (Question applies to all the ID attributes in this draft.) >> >> I think seqnumber needs some more explanation. How is it constructed? Can >> the recipient infer anything about gaps in sequence numbers? Do you have >> to worry about roll over? Do you have separate sequence spaces in each >> direction (like CSeq for SIP?) >> >> What is the scope for "expires"? For example, does a the expiring state >> survive the end of a mediactrl session? How is it handled if not present? >> (Similar questions applies to all occurrences of "Expires" attributes in >> the draft.) >> >> -- 5.1.4.* >> >> This entire section seems to enumerate the features for an MS. How do new >> features get added? >> >> -- 5.1.4.5: >> >> I'm not sure I understand what a non-active session is. Do you mean >> available ports, resources, etc that could be used for sessions? Is that >> the right way to express available resources? (For example, how would you >> express available CPU cycles in terms of available sessions?) I think you >> mentioned this issue somewhere, but I'm not sure I agree that you've >> found the right abstraction here. >> >> -- 5.1.4.7: >> >> What's the practical difference between deactivated and unavailable? >> >> -- 5.1.4.9: >> >> It's not clear to me what is for--can you elaborate? >> >> 5.1.4.10, "supported-format" >> >> What kind of name goes in the supported format. Is this a MIME type, or >> some other managed namespace? (Similar questions apply for the values for >> other "name" attributes in the draft, where the name spaces or registries >> need to be defined.) >> >> -- 5.1.4.12: >> >> What goes in "name"? Are you picking from a registry? >> >> --5.1.4.13, "audio-mixing-modes" >> >> What sort of value does the "package" attribute carry? Is there a >> registry for mediactrl package names? >> >> (This sort of issue occurs several more times. I'm going to quite >> commenting on it.) >> >> >> -- security considerations: >> >> It's worth discussing the fact that the IAMM model involves a b2bua >> modifying SIP bodies. This impacts the ability to use any SIP security >> feature that protects the body (e.g. 4474, s/mime, etc.) unless the MRB >> intermediates the security association. Given that one of points of using >> SIP for mediactrl in the first place was to reuse SIP features when >> possible, I think this is an issue. >> >> The security considerations talk about channel security, but not so much >> about authorization. I think it's important to make sure only authorized >> application servers can get information about media servers, etc. >> >> -- 5.2.4, definition of >> >> Is the exclusion enforced by the schema? If not, should it be normative? >> >> Editorial Comments: >> >> -- idnits generates some warnings. >> >> -- General Comment: There's a lot of redundancy in this draft. A >> procedures are often described several times. Many data elements are >> described several times. Data elements that are either identical or very >> close to identical between the publish and consumer interface are >> described in detail for both interfaces, including in the schemas. It >> makes sense to have a section that describes how the protocols work at a >> high level, and another that describes them normatively, but that >> distinction is not clear. The result is a very long document, that could >> probably be considerably shorter with some editing. >> >> -- section 2, 2119 language: Why the BCP 15 reference? That's "Deployment >> of the Internet White Pages Service"--is that really what you meant? >> (BTW, that additional text confuses idnits when it's checking for 2119 >> boilerplate.) >> >> -- Section 3, paragraph 1: "It is clear from Section 1 that the MediaCtrl >> group will be producing >> a solution that must service a wide variety of deployment >> architectures." >> >> It is clear to whom? (making forward looking statements about what a WG >> will solve is dangerous, at best--not to mention this one will date the >> draft if it becomes an RFC.) >> >> -- section 5.1, first paragraph, 2nd sentence: >> >> Generally accepted by whom? I'm not sure what information this sentence >> intends to convey. >> >> -- ... 2nd to last sentence: >> >> Perfect? Really? :-) (I'd suggest turning down the hype a bit.) >> >> -- section 5.1.1: >> >> That MUST is a statement of fact, not a normative requirement imposed by >> _this_ spec. I suggest it be uncapitalized. >> >> -- section 5.1.1.4: >> >> Is (or can) the MUST requirement of mutual exclusivity expressed in the >> schema? >> >> -- section 5.1.3.1, definition of "id" >> >> What is the "session"? Are we talking about the resulting subscription, >> or the mediactrl session? >> >> -- section 5.1.4.2: Did you mean to say no child elements? Isn't >> a child element? >> >> -- 5.1.4.14, supported-country-codes: >> >> Need a reference for ISO-3166-1 >> >> -- 5.2.3, definition of "action" >> >> It would help to separate the possible values into separate paragraphs, >> sub-bullets, a table, or something. It's hard to can with the values >> defined mid-paragraph. >> >> >> -- 5.3.2, 5th paragraph: >> >> s/IAMM/MRB ? >> >> s/fulfil/fulfill >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai > > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl From Scott.McGlashan@hp.com Wed Feb 24 12:30:30 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9133D3A85AF for ; Wed, 24 Feb 2010 12:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.939 X-Spam-Level: X-Spam-Status: No, score=-104.939 tagged_above=-999 required=5 tests=[AWL=1.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfyotwDLweYq for ; Wed, 24 Feb 2010 12:30:29 -0800 (PST) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by core3.amsl.com (Postfix) with ESMTP id E3C143A85B1 for ; Wed, 24 Feb 2010 12:30:28 -0800 (PST) Received: from g5t0012.atlanta.hp.com (unknown [15.192.0.16]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id 591DA301F1; Wed, 24 Feb 2010 20:32:36 +0000 (UTC) Received: from [192.168.0.111] (21.58.227.87.static.ang.siw.siwnet.net [87.227.58.21]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id 24E1410002; Wed, 24 Feb 2010 20:32:35 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-28-973529768 From: Scott McGlashan In-Reply-To: <059AF07365DC474393A19A3AF187DF74054F8669@NAHALD.us.int.genesyslab.com> Date: Wed, 24 Feb 2010 21:32:18 +0100 Message-Id: <9629229F-0386-4808-B895-947CF102733F@hp.com> References: <059AF07365DC474393A19A3AF187DF74051E1ACA@NAHALD.us.int.genesyslab.com><000001cab111$ae4f6680$0aee3380$@com> <37238266-CF4F-49CB-AAF1-341877470AB8@hp.com> <059AF07365DC474393A19A3AF187DF74054F8669@NAHALD.us.int.genesyslab.com> To: Henry Lum X-Mailer: Apple Mail (2.1077) Cc: "mediactrl@ietf.org" Subject: Re: [MEDIACTRL] Questions ondraft-ietf-mediactrl-ivr-control-package X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 20:30:30 -0000 --Apple-Mail-28-973529768 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Henry, I think we are almost there on the IVR. thanks Scott On 19 Feb 2010, at 21:54, Henry Lum wrote: > Hi Scott, > =20 > Please see my responses below. > =20 > Thanks > Henry > =20 > [SMCG] The group had discussed this behavior in the past and agreed = that it was important that 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 = 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. =20 > =20 > [[hlum]] Okay, I accept the shortcut with the 410 response to optimize = the need for . However, in the PREPARED state, when = is called and 200 response is received, shall I expect = a in this state? [SMCG] Not according to the current spec wording and state machine. = would only follow when the dialog is in = the started state. =20 > =20 > =20 > [SMCG] I thought this was clear - the paragraph references 'retrieving = external .. resources' and a is a one or more (media) = resources. In 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 with a 409 status code.' If = you have a specific suggestion, please send.=20 > =20 > [[hlum]] I got confused about the differences between VXML (external) = and resources ( tag). Can we modify the wording in = to: > Dialog preparation consists of (a) retrieving external dialog document = and/or resources referenced by the

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

Hi = Scott,
Please see my = responses below.
[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] Not according to the current spec wording = and state machine. <dialogexit> would only follow = <dialogterminate> when the dialog is in the started 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] 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 =96 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=92s = add to the <media> element referenced in this = section:
<media>: specifies = a media resource (see

[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=92t 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=92s debatable since it=92s 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.

[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 =93finishonmatch=94 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=92t 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?

= --Apple-Mail-28-973529768-- From Henry.Lum@alcatel-lucent.com Wed Feb 24 13:28:36 2010 Return-Path: X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11233A85CF for ; Wed, 24 Feb 2010 13:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIArs65OafnC for ; Wed, 24 Feb 2010 13:28:30 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 4169F3A85C8 for ; Wed, 24 Feb 2010 13:28:29 -0800 (PST) Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o1OLUWV4026002; Wed, 24 Feb 2010 15:30:32 -0600 (CST) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o1OLUVpS017701; Wed, 24 Feb 2010 15:30:32 -0600 (CST) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc (8.13.8+Sun/8.13.8) with ESMTP id o1OLUUXP019925; Wed, 24 Feb 2010 13:30:31 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 13:30:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB598.96D08C61" x-cr-hashedpuzzle: AqvG Bejr DdCe Gb29 GypG IAhP IGus IiPA Nip0 OUF1 PlaW RCyr RH/V R4sW R+jK TnZg; 2; bQBlAGQAaQBhAGMAdAByAGwAQABpAGUAdABmAC4AbwByAGcAOwBzAGMAbwB0AHQALgBtAGMAZwBsAGEAcwBoAGEAbgBAAGgAcAAuAGMAbwBtAA==; Sosha1_v1; 7; {8DE06A2F-B894-4B4F-BE30-4E8F3E5FE506}; aABlAG4AcgB5AC4AbAB1AG0AQABnAGUAbgBlAHMAeQBzAGwAYQBiAC4AYwBvAG0A; Wed, 24 Feb 2010 21:30:25 GMT; UgBFADoAIABbAE0ARQBEAEkAQQBDAFQAUgBMAF0AIABRAHUAZQBzAHQAaQBvAG4AcwAgAG8AbgBkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBlAGQAaQBhAGMAdAByAGwALQBpAHYAcgAtAGMAbwBuAHQAcgBvAGwALQBwAGEAYwBrAGEAZwBlAA== x-cr-puzzleid: {8DE06A2F-B894-4B4F-BE30-4E8F3E5FE506} Content-class: urn:content-classes:message Date: Wed, 24 Feb 2010 13:30:25 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74054F8EB4@NAHALD.us.int.genesyslab.com> In-Reply-To: <9629229F-0386-4808-B895-947CF102733F@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEDIACTRL] Questions ondraft-ietf-mediactrl-ivr-control-package Thread-Index: Acq1kIHxhvdZOEePTaW+UYZLz/kwgQAAbZ0Q References: <059AF07365DC474393A19A3AF187DF74051E1ACA@NAHALD.us.int.genesyslab.com><000001cab111$ae4f6680$0aee3380$@com> <37238266-CF4F-49CB-AAF1-341877470AB8@hp.com> <059AF07365DC474393A19A3AF187DF74054F8669@NAHALD.us.int.genesyslab.com> <9629229F-0386-4808-B895-947CF102733F@hp.com> From: "Henry Lum" To: "Scott McGlashan" X-OriginalArrivalTime: 24 Feb 2010 21:30:30.0724 (UTC) FILETIME=[970B5840:01CAB598] X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 Cc: mediactrl@ietf.org Subject: Re: [MEDIACTRL] Questions ondraft-ietf-mediactrl-ivr-control-package X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 21:28:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB598.96D08C61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, =20 3 items left J =20 Thanks Henry =20 [SMCG] Not according to the current spec wording and state machine. would only follow when the dialog is in the started state. =20 =20 [[hlum]] So this is the only exception where you don't get either a nor a negative response to a dialogterminate. This is in contradiction with the wording in 4.2.5.1 for :=20 " The event indicates that a prepared or active dialog has exited because it is..." We should either change the wording for the event to indicate only active dialogs, or we change the state machine to fix this exception. I would vote for the latter. =20 =20 [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.=20 =20 [[hlum]] I am fine with your assumption for (b); let's clarify this in escapekey. [SMCG] Ok. How about *** PROPOSED CHANGE:=20 =20 Add a 'repeatUntilComplete' attribute (boolean value, default false) on