Subject: [speechsc] Record-URI mechanism

From: "Dave Burke" <[email-masked]>
Date: Sun, 14 May 2006 13:34:58 +0100

In 10.6, the spec says:

   If the recording-uri is not specified [in RECORD], the server captures the media
   anywhere it finds convenient and returns a URI pointing to the
   recorded audio in the RECORD-COMPLETE event.

However, 10.4.7 apparently conflicts with this and says:

   If this header is not specified in the RECORD request, the server
   MUST capture the audio and send it in the "STOP" response or the
   RECORD-COMPLETE event as a message body.  In this case, the response
   carrying the audio content would have this header with a cid value
   pointing to the Content-ID in the message body.

Which is it? I prefer it to be the former (i.e. no data in the message body). It's easy to implement (very likely the MRCP client has a HTTP client somewheres, optimised for streaming and allowing caching for repeated playback), it doesn't burden the control channel with potentially very large audio data, and besides, the MRCP client might not even want the data in the case of verification on the server.

Dave

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

---

From: Jerry Carter <[email-masked]>
Date: Sun, 14 May 2006 14:22:11 -0400

Agreed.  The language from 10.6 is preferrable.

On May 14, 2006, at 8:34 AM, Dave Burke wrote:

> Which is it? I prefer it to be the former (i.e. no data in the message 
> body). It's easy to implement (very likely the MRCP client has a HTTP 
> client somewheres, optimised for streaming and allowing caching for 
> repeated playback), it doesn't burden the control channel with 
> potentially very large audio data, and besides, the MRCP client might 
> not even want the data in the case of verification on the server.
>  
> Dave
>  
>