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

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:awahbe@voicegenie.com] 
	Sent: Monday, May 08, 2006 7:35 AM
	To: Dave Burke
	Cc: speechsc@ietf.org
	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
		Speechsc@ietf.org
		https://www1.ietf.org/mailman/listinfo/speechsc