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

From: "Carter, Jerry" <[email-masked]>
Date: Mon, 8 May 2006 11:45:58 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

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

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

         <?xml version="1.0"?>
            <speak version="1.0"

---

From: Andrew Wahbe <[email-masked]>
Date: Mon, 08 May 2006 15:08:17 -0400

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