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

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 9 May 2006 09:51:24 -0700

A couple of things.
Current Draft:
    1. In the example mentioned the Completion-Cause header that comes
in a SPEAK-COMPLETE message with a request-state of COMPLETE MUST
reflect the final completion state of the operation(in this case SPEAK).
Which means that in this SSML example the Completion-Cause code should
be "normal". Because, though there were some URI fetch failure, the
alternative <audio> succeeded and hence the overall SPEAK operation was
successfull.
    2. The MRCP server must log the failed URI to its logging system. 
 
Future Possible Extentions:
    3. In future, if there are exceptions that the client needs to be
notified of, such as the above URI failures in this example, they MUST
be sent as events(say EXCEPTION) that MUST carry a request-state of
IN-PROGRESS (as the request, say SPEAK, is still proceeding) and an
Exception-Cause. The values that can be specified in the Exception-Cause
are most likely a small sub-set of the Completion-Cause values.
    4.  Such EXCEPTION events should be used only if the resource is
able to proceed past these errors, else it would be a <request>-COMPLETE
event.
    5. As a general guide for the protocol, we should design all future
requests that need multiple response scenarios, as a response that
returns status 200 and request-state IN-PROGRESS or PENDING if the
request was queued or successfully started. Future intermediate
responses to that request should always designed as events with
request-state of IN-PROGRESS or PENDING. The final response to the
request MUST be sent as a <request>-COMPLETE event with a request-state
of COMPLETE and a Completion-Cause header.
 
I understand we could have designed the system to have multiple
responses to the request, in which case we should not have events. But
the current design is one response and possible multiple events. Which
is essentially the same thing and gives the same level of flexibility as
the other approach, just that the 2+ response messages looks slightly
different.
 
So we should stick to this general approach when proposing future
extensions to the protocol such as the EXCEPTION event.
 
Thx,
Sarvi 

________________________________

	From: Andrew Wahbe [mailto:[email-masked]] 
	Sent: Monday, May 08, 2006 7:35 AM
	To: Dave Burke
	Cc: [email-masked]
	Subject: Re: [speechsc] Fallback <audio> and 003 uri-failure

	The VoiceXML Forum MRCP Liaison Committee came to the following
conclusion on this issue (see
http://www.ietf.org/mail-archive/web/speechsc/current/msg01611.html):
	
	2) It should be clarified that  SPEAK completion code 003
"uri-failure" only applies to  fetched SSML files and that  failure to
fetch (or process) an audio file will not result in aborting the SPEAK
request. This does mean, however, that there is no way to communicate
the failure to fetch (or process) the audio file to the MRCP client.
While SSML requires that the processor "notify the hosting environment"
when such a failure occurs, the members of the committee agree that
logging this event at the MRCP server is sufficient. It may be advisable
for the MRCP specification to suggest that these events should be logged
in some way. We would also like to suggest that future versions of MRCP
consider adding an event (e.g. "Audio-Exception") to notify the MRCP
client that such a failure has occurred without aborting the SPEAK
request. 
	
	Is there a specific reason why the above approach is not
sufficient? Or are you thinking of a non-VoiceXML case?
	
	Andrew Wahbe
	
	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

---

From: "Burger, Eric" <[email-masked]>
Date: Tue, 16 May 2006 12:45:22 -0400

Like...?

-----Original Message-----
From: Jerry Carter [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2006 12:40 PM
To: Burger, Eric
Cc: David R Oran; IETF SPEECHSC (E-mail)
Subject: Re: [speechsc] Fallback <audio> and 003 uri-failure

Yes.

On May 16, 2006, at 12:33 PM, Burger, Eric wrote:

> 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
> 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-----
>>>>> Sent: Monday, May 08, 2006 3:08 PM
>>>>> To: Dave Burke
>>>>> Cc: Carter, Jerry; [email-masked]
>>>>> 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/">
>>>>>>   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:
>>>>>>> will I get a SPEAK-COMPLETE with 000 normal or 003 uri-failure?
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 16 May 2006 13:32:24 -0700

I agree this may be usefull information for the server to send to the
client. 
But I do not believe that it is urgent enough that we try to address it
in this specification.
 
Like I said earlier, I like the suggestion from Dave Oran on how to
approach this problem.
Details about the TTS speech markup compilation, Recognizer Grammar
Compilation errors etc could be returned in the message body of
associated *-COMPLETE event or an appropriate EXCEPTION event.
 
The format of the message body(possibly in XML) needs to be well defined
if we expect this to work interoperably between all clients and servers.
I suggest interested parties write a draft proposing a format for this
error message body and also the EXCEPTION event if they see a need for
it.
 
Thanks,
Sarvi

	From: Andrew Wahbe [mailto:[email-masked]] 
	Sent: Tuesday, May 16, 2006 1:12 PM
	To: Carter, Jerry
	Cc: IETF SPEECHSC (E-mail); David R Oran; Burger, Eric
	Subject: Re: [speechsc] Fallback <audio> and 003 uri-failure

	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
	
	Carter, Jerry wrote: 

		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

				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.

	

				        <?xml version="1.0"?>
				        <speak version="1.0"
	
xmlns="http://www.w3.org/2001/10/synthesis"
<http://www.w3.org/2001/10/synthesis> 
	
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<http://www.w3.org/2001/XMLSchema-instance> 

http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
<http://www.w3.org/2001/10/synthesishttp://www.w3.org/TR/speech-synthesi
s/synthesis.xsd> "
				            xml:lang=" <xml:lang=>
en-US" xml:base=" <xml:base=> "http://www.example.com/"
<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

	
				        Completion-Cause:009 uri
resolution problem
				        Failed-URI-Cause:404

				  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

				
				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]>
<mailto:[email-masked]> 
				To: "Andrew Wahbe"
<[email-masked]> <mailto:[email-masked]> ; "Dave Burke"
				<[email-masked]>
<mailto:[email-masked]> 
				Cc: <[email-masked]>
<mailto:[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

				Dave
				
				----- Original Message ----- From:
"Carter, Jerry"
				<[email-masked]>
<mailto:[email-masked]> 
				To: "Dave Burke"
<[email-masked]> <mailto:[email-masked]> ;
<[email-masked]> <mailto:[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.

	
				
				        <?xml version="1.0"?>
				           <speak version="1.0"
	
xmlns="http://www.w3.org/2001/10/synthesis"
<http://www.w3.org/2001/10/synthesis> 

				instance"

				synthesis

				synthesis.xsd"

				               xml:lang="en-US"
xml:base=" <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

	
				        Completion-Cause:009 uri
resolution problem
				        Failed-URI-Cause:404

				  S->C: MRCP/2.0 79 SPEAK-COMPLETE
543257 COMPLETE

				Dave Burke wrote:

				<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