Subject: RE: [speechsc] Fallback <audio> and 003 uri-failure

From: "Carter, Jerry" <[email-masked]>
Date: Tue, 16 May 2006 15:40:30 -0400

This question is probably best answered directly by members of the UI
Designer community such as Blade Kotelly, but the responses that I've gotten
fall into two classes.

The first group notes that since VoiceXML 2.x does not have this capability,
current applications must be designed without this information.  I call this
the "If I can't do it, I don't even want to think about it" response.

The second group notes that knowing exactly what errors occurred and by
inference what the caller heard, allows the application server to better
tailor subsequent interactions by replaying certain portions or by producing
prompts that avoid troublesome servers.  Transmitting this information to
the application server is done by the client.  Few if any directed dialog
applications support this capability today, but the next generation of
NL-focused state-based dialog engines being developed and deployed by AT&T,
IBM, Nuance, and others support far more flexible applications.

> -----Original Message-----
> From: Burger, Eric [mailto:[email-masked]]
> Sent: Tuesday, May 16, 2006 12:33 PM
> To: David R Oran; Jerry Carter
> Cc: IETF SPEECHSC (E-mail)
> Subject: RE: [speechsc] Fallback <audio> and 003 uri-failure
> 
> Would a client actually *do* anything with the enhanced information?
> Sure it is a nice-to-have, but does any real application care to know
> anything besides "something went wrong"?
> 
> -----Original Message-----
> From: David R Oran [mailto:[email-masked]]
> Sent: Tuesday, May 09, 2006 8:34 AM
> To: Jerry Carter
> Cc: IETF SPEECHSC (E-mail); Andrew Wahbe; Dave Burke
> Subject: Re: [speechsc] Fallback <audio> and 003 uri-failure
> 
> 
> On May 8, 2006, at 5:43 PM, Jerry Carter wrote:
> 
> > Experience leads me to believe that the simpler approach does not
> > work for arbitrary SSML documents.  Because URIs may point to
> > streaming data or return content based on cookies, SSML may use the
> > same URI to reference different data.  Having explicit marker
> > events and error reporting (either as events or messages) may allow
> > the client to determine the exact URI instance that failed -- for
> > those rare cases where this is necessary.
> >
> Why can't the client re-reference the URI itself to see if it's an
> aliasing problem? Strikes me this is a general issue with any content
> indirection scheme and it isn't the job of MRCP to provide the
> forensics. On the other hand, giving the client a pointer into the
> SSML document for where the synthesizer "gave up" would seem to be
> useful and not much of a burden on the server. If we do something
> like this, it's important to not go *too* far and wind up with
> something complex like compiler tracebacks syntactically and
> semantically mandated by MRCP. Here's one possible approach:
> 
> 1) we allow some opaque (to MRCP) data to be returned on the URI
> failure event.
> 2) we suggest to people the server can use this to provide forensics
> to the client for where in parsing/playing the SSML the server barfed
> and possibly why.
> 
> Dave.
> 
> 
> >   C->S: MRCP/2.0 489 SPEAK 543257
> >         Channel-Identifier:32AECB23433802@speechsynth
> >         Content-Type:application/ssml+xml
> >         Content-Length:???
> >
> >         <?xml version="1.0"?>
> >         <speak version="1.0"
> >             xmlns="http://www.w3.org/2001/10/synthesis"
> >             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >             xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
> >             http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
> >             xml:lang="en-US" xml:base="http://www.example.com/">
> >           <audio src="uri.wav"> <!-- invalid URI -->
> >             <mark name="inside first"/>
> >             <audio src="uri.wav"/> <!-- valid URI -->
> >           </audio>
> >           <mark name="before second"/>
> >           <audio src="uri.wav"/>
> >         </speak>
> >
> >   S->C: MRCP/2.0 28 543257 200 IN-PROGRESS
> >         Channel-Identifier:32AECB23433802@speechsynth
> >
> >   S->C: MRCP/2.0 543257 407 IN-PROGRESS
> >         Channel-Identifier:32AECB23433802@speechsynth
> >         Completion-Cause:009 uri resolution problem
> >         Failed-URI-Cause:404
> >         Failed-URI:http://www.example.com/uri.wav
> >
> >   S->C: MRCP/2.0 SPEECH-MARKER 543257 IN-PROGRESS
> >         Channel-Identifier:32AECB23433802@speechsynth
> >         Speech-Marker:timestamp=;inside first
> >
> >   S->C: MRCP/2.0 SPEECH-MARKER 543257 IN-PROGRESS
> >         Channel-Identifier:32AECB23433802@speechsynth
> >         Speech-Marker:timestamp=;before second
> >
> >   S->C: MRCP/2.0 SPEAK-COMPLETE 543257 COMPLETE
> >         Channel-Identifier:32AECB23433802@speechsynth
> >         Completion-Cause:000 normal
> >
> >
> >
> > On May 8, 2006, at 4:39 PM, Dave Burke wrote:
> >
> >> At this late stage, I think changing the message exchange pattern
> >> is too incisive (I also quite like the patter...). Though, I
> >> understand you concern for a proliferation of events.... With that
> >> in mind, how about taking a variation of what's been discussed for
> >> grammars and go with:
> >>
> >> 1. Allow Failed-URI to appear multiple times in SPEAK-COMPLETE
> >> (and reports failed <audio>s) with return type 003 uri-failure.
> >> These headers cannot be combined to one comma separated list
> >> because commas are valid reserved URI tokens.
> >>
> >> 2. Combine the the reason in the Failed-URI as you suggested so
> >> that we can have multiple Failed-URIs.
> >>
> >> This is sufficient for the MRCP client to detect what has been
> >> played and what hasn't and is consistent with SSML.
> >>
> >> Dave
> >>
> >> ----- Original Message ----- From: "Carter, Jerry"
> >> <[email-masked]>
> >> To: "Andrew Wahbe" <[email-masked]>; "Dave Burke"
> >> <[email-masked]>
> >> Cc: <[email-masked]>
> >> Sent: Monday, May 08, 2006 8:34 PM
> >> Subject: RE: [speechsc] Fallback <audio> and 003 uri-failure
> >>
> >>
> >>> I agree that the current text is clear.  As described in section
> >>> 5, there is
> >>> a single response delivered for each message.  Unfortunately, as
> >>> this case
> >>> and a similar analysis for grammar definitions shows [1], error
> >>> handling is
> >>> an area of weakness in the -09 draft.
> >>>
> >>> There are two solutions that come to mind.
> >>>
> >>> * Add additional events which can be used for error reporting.
> >>> This seems
> >>> to be the direction that you and Dave are endorsing.
> >>>
> >>> * Alternatively, relax the single response requirement so that
> >>> requests
> >>> follow a natural progression from PENDING to IN-PROGRESS to
> >>> COMPLETE. Each
> >>> request would generate exactly one COMPLETE response.  This final
> >>> response
> >>> might be preceded by zero or more IN-PROGRESS messages which
> >>> would in turn
> >>> be preceded by zero or more PENDING messages.
> >>>
> >>> I fear the events approach leads to a proliferation of events and
> >>> confuses
> >>> the semantics of the language.  Conversely, the clear progression
> >>> in message
> >>> handling states is easily described by adding a paragraph or two
> >>> to section
> >>> 5.
> >>>
> >>>
> >>> [1] http://www1.ietf.org/mail-archive/web/speechsc/current/
> >>> msg01797.html
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Andrew Wahbe [mailto:[email-masked]]
> >>>> Sent: Monday, May 08, 2006 3:08 PM
> >>>> To: Dave Burke
> >>>> Cc: Carter, Jerry; [email-masked]
> >>>> Subject: Re: [speechsc] Fallback <audio> and 003 uri-failure
> >>>>
> >>>> I was going to give a similar reply but I wanted to reference the
> >>>> restriction text in the spec. Unfortunately, I haven't been able
> >>>> to find
> >>>> it though the term "response" does imply it... of course PENDING
> >>>> and
> >>>> IN-PROGRESS could be interpreted as a kind of "provisional"
> >>>> response....
> >>>> though the examples paint a different picture (only 1 response
> >>>> to each
> >>>> request).
> >>>>
> >>>> Section 5.3 says:
> >>>>
> >>>>    After receiving and interpreting the request message for a
> >>>> method,
> >>>>    the server resource responds with an MRCPv2 response message.
> >>>>
> >>>> and
> >>>>
> >>>>    A PENDING or IN-PROGRESS
> >>>>    status indicates that further Event messages may be delivered
> >>>> with
> >>>>    that request-id.
> >>>>
> >>>> Perhaps the limit of one response to each request should be stated
> >>>> explicitly somewhere (sorry if I missed it).
> >>>>
> >>>> Andrew
> >>>>
> >>>> Dave Burke wrote:
> >>>> > That works if we change the second response to an event as
> >>>> suggested
> >>>> > by Andrew (the MRCP message exchange pattern rightly restricts
> >>>> one
> >>>> > response to each request).
> >>>> >
> >>>> > Dave
> >>>> >
> >>>> > ----- Original Message ----- From: "Carter, Jerry"
> >>>> > <[email-masked]>
> >>>> > To: "Dave Burke" <[email-masked]>; <[email-masked]>
> >>>> > Sent: Monday, May 08, 2006 4:45 PM
> >>>> > Subject: RE: [speechsc] Fallback <audio> and 003 uri-failure
> >>>> >
> >>>> >
> >>>> > Would not notification along these lines be appropriate?  If
> >>>> so, > perhaps
> >>>> > adding this example to the specification would be useful.
> >>>> >
> >>>> >   C->S: MRCP/2.0 489 SPEAK 543257
> >>>> >         Channel-Identifier:32AECB23433802@speechsynth
> >>>> >         Content-Type:application/ssml+xml
> >>>> >         Content-Length:???
> >>>> >
> >>>> >         <?xml version="1.0"?>
> >>>> >            <speak version="1.0"
> >>>> >                xmlns="http://www.w3.org/2001/10/synthesis"
> >>>> >                xmlns:xsi="http://www.w3.org/2001/XMLSchema-
> >>>> instance"
> >>>> >                xsi:schemaLocation="http://www.w3.org/2001/10/
> >>>> synthesis
> >>>> >                   http://www.w3.org/TR/speech-synthesis/
> >>>> synthesis.xsd"
> >>>> >                xml:lang="en-US" xml:base="http://
> >>>> www.example.com/">
> >>>> >              <audio src="baduri.wav"> <!-- invalid URI -->
> >>>> >                <audio src="gooduri.wav"/> <!-- valid URI -->
> >>>> >              </audio>
> >>>> >           </speak>
> >>>> >
> >>>> >
> >>>> >   S->C: MRCP/2.0 28 543257 200 IN-PROGRESS
> >>>> >         Channel-Identifier:32AECB23433802@speechsynth
> >>>> >
> >>>> >   S->C: MRCP/2.0 543260 407 IN-PROGRESS
> >>>> >         Channel-Identifier:32AECB23433802@speechsynth
> >>>> >         Completion-Cause:009 uri resolution problem
> >>>> >         Failed-URI-Cause:404
> >>>> >         Failed-URI:http://www.example.com/baduri.wav
> >>>> >
> >>>> >   S->C: MRCP/2.0 79 SPEAK-COMPLETE 543257 COMPLETE
> >>>> >         Channel-Identifier:32AECB23433802@speechsynth
> >>>> >         Completion-Cause:000 normal
> >>>> >
> >>>> >
> >>>> > Dave Burke wrote:
> >>>> >> If I have some SSML along the lines of
> >>>> >>
> >>>> >> <speak>
> >>>> >> <audio src="baduri.wav"> <!-- invalid URI -->
> >>>> >> <audio src="gooduri.wav"/> <!-- valid URI -->
> >>>> >> </audio>
> >>>> >> </speak>
> >>>> >>
> >>>> >> will I get a SPEAK-COMPLETE with 000 normal or 003 uri-failure?
> >>>> >>
> >>>> >> SSML requires that processing continues but that the
> >>>> >> hosting environment be notified. It would be useful to
> >>>> >> clarify that this is indeed the case with the basicsynth
> >>>> >> / speechsynth and that 003 uri-failure will be returned.
> >>>> >> Without this, the most trivial of media server applications
> >>>> >> (i.e. playing announcements) is not possible to be
> >>>> >> implemented robustly.
> >>>> >>
> >>>> >> Dave
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Speechsc mailing list
> >>>> > [email-masked]
> >>>> > https://www1.ietf.org/mailman/listinfo/speechsc
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Speechsc mailing list
> >>>> > [email-masked]
> >>>> > https://www1.ietf.org/mailman/listinfo/speechsc
> >>>> >
> >>>> >
> >>>
> >>> _______________________________________________
> >>> Speechsc mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/speechsc
> >>
> >>
> >> _______________________________________________
> >> Speechsc mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/speechsc
> >>
> >
> >
> > _______________________________________________
> > Speechsc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speechsc
> 
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Andrew Wahbe <[email-masked]>
Date: Tue, 16 May 2006 16:11:55 -0400

I agree that this isn't a strange thing to ask for. I think the question 
here is not if this is needed but when it should be added. i.e. does 
this go into MRCP v2 or some future draft. It could even be a short 
draft that just specifies new headers to enable the feature and to 
communicate the failed URIs.

Andrew