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

From: "Dave Burke" <[email-masked]>
Date: Sat, 6 May 2006 18:07:21 +0100

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

---

From: Andrew Wahbe <[email-masked]>
Date: Mon, 08 May 2006 10:34:51 -0400

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:
> 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
>  
> ------------------------------------------------------------------------
>

---

From: "Dave Burke" <[email-masked]>
Date: Mon, 8 May 2006 17:37:53 +0100

My customer-driven use-case is that of a media server using a basicsynth to play a network announcement. Somewhere behind all this next-gen IP network equipment is a legacy IN network that wants to simply know (by INAP response) "did that announcement play"? It seems such a basic use-case yet SSML and now MRCP make it very difficult because of SSML's fallback and best-effort behaviour.

An AUDIO-EXCEPTION event using the already defined Failed-URI and Failed-URI-Cause header fields would certainly work fine.

Point to clean-up: Failed-URI and Failed-URI-Cause are currently restricted to responses but need to be allowed in SPEAK-COMPLETE since a lexicon document might have a Fetch-Hint of safe.

Dave

  ----- Original Message ----- 
  From: Andrew Wahbe 
  To: Dave Burke 
  Cc: [email-masked] 
  Sent: Monday, May 08, 2006 3:34 PM
  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: 

    <speak>

    Dave

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