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 at voicegenie.com]
Sent: Monday, May 08, 2006 7:35 AM
To: Dave Burke
Cc: speechsc at 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=""> 

         <audio src=""/> 

     </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 at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc