_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

   =
dtmf-term-char         &nbs=
p; =3D  "DTMF-Term-Char" ":" VCHAR =
CRLF

   =
dtmf-term-char          =
; =3D  "DTMF-Term-Char" ":" VCHAR =
CRLF

   =
dtmf-term-char         &nbs=
p; =3D  "DTMF-Term-Char" ":" VCHAR =
CRLF

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:EBurger@cantata.com]
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:oran@cisco.com]
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"
<jerry.carter@nuance.com>
To: "Andrew Wahbe" <awahbe@voicegenie.com>; "Dave Burke"
<david.burke@voxpilot.com>
Cc: <speechsc@ietf.org>
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:awahbe@voicegenie.com]
Sent: Monday, May 08, 2006 3:08 PM
To: Dave Burke
Cc: Carter, Jerry; speechsc@ietf.org
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"
<jerry.carter@nuance.com>
To: "Dave Burke" <david.burke@voxpilot.com>; <speechsc@ietf.org>
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
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

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:EBurger@cantata.com]
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:oran@cisco.com]
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=3D"1.0"?>
        <speak version=3D"1.0"
            xmlns=3D"http://www.w3.org/2001/10/s=
ynthesis"
            xmlns:xsi=3D"http://www.w3.org/200=
1/XMLSchema-instance"
            xsi:schemaLocation=3D"http://www.w3.org/2001/10/synthesis
            http://www.w3.org/TR/speech-synthesis/synthesis.xsd""
            xml:lang=3D"en-US" xml:base=3D""http://www.example.com/">
          <audio src=3D"uri.wav"> <!-- invalid URI -->
            <mark name=3D"inside first"/>
            <audio src=3D"uri.wav"/> <!-- valid URI -->
          </audio>
          <mark name=3D"before second"/>
          <audio src=3D"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=3D;inside first

  S->C: MRCP/2.0 SPEECH-MARKER 543257 IN-PROGRESS
        Channel-Identifier:32AECB23433802@speechsynth
        Speech-Marker:timestamp=3D;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"
<jerry.carter@nuance.com>
To: "Andrew Wahbe" <awahbe@voicegenie.com>; =
"Dave Burke"
<david.burke@voxpilot.com>=

Cc: <speechsc@ietf.org>
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://w=
ww1.ietf.org/mail-archive/web/speechsc/current/
msg01797.html

-----Original =
Message-----
From: Andrew Wahbe [mailto:awahbe@voicegenie.com]
Sent: Monday, May 08, 2006 3:08 PM
To: Dave Burke
Cc: Carter, Jerry; speechsc@ietf.org
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"
<jerry.carter@nuance.com>
To: "Dave Burke" <david.burke@voxpilot.com>=
; <speechsc@ietf.org>
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=3D"1.0"?>
           <speak version=3D"1.0"
               xmlns=3D"http://www.w3.org/2001/10/s=
ynthesis"
               xmlns:xsi=3D"http://www.w3.org/2001/XMLSchem=
a-

instance"

               =
xsi:schemaLocation=3D"http://www.w3.org/2001/10/

synthesis

                  =
http://www.w3.org/TR/spee=
ch-synthesis/

synthesis.xsd"

               xml:lang=3D"en-US" xml:base=3D"http://

www.example.com/">

             =
<audio src=3D"baduri.wav"> <!-- invalid URI -->
               <audio src=3D"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=3D"baduri.wav"> <!-- invalid URI -->
<audio src=3D"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
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc