Subject: RE: [Speechsc] Recognizer queueing versus synthesizer queueing

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Fri, 3 Jun 2005 10:37:44 -0700

In general some of these mechanims, like Canel-If-Queue are there to
make life easy. 
But I agree that these can be streamlined a little more. 

Like I mentioned, in a previous mail, some of the convoluted wording was
because the current text was derived from proposed extensions to MRCPv1
and hence was attempting to maintain some backward compatibility.

That is not requirment any more and so that can be simplified. 

Here is my proposal. 

Synthesizer
    1. We leave SPEAK queing mechanism as is. 
    2. We leave the behaviour of STOP as defined for the speech
synthesizer.
    3. We add that if a SPEAK request fails due to an error, any
currently queued SPEAK/RECOGNIZE requests behind the failed one should
also be removed from the queue. Here just as in the case of barge-in,
the SPEAK-COMPLETE/RECOGNITON-COMPLETE event for the failed
SPEAK/RECOGNIZE request MUST contain the request-id of the failed
request followed by the list of queued/pending request-ids that were
terminted because of the failure.
    4. We could generalize the Cancel-If-Queue header proposed for the
recongizer to also apply for synthesizer resource with the same
behaviour. Default value for "Cancel-If-Queue" header field is "false".
Which allows for queing of requests, same as today.
    5. We leave the behaviour of BARGE-IN-OCCURRED and its effect on
queued requests as is. This operation is unique to synthesizers and has
no equivalent in recognition.

Recognizer
    1. Modify RECOGNIZE to have the same behaviour as synthesizer SPEAK
requests.
    2. We add text to cover the behaviour of STOP when there are queued
RECOGNIZE requests. The behaviour would be the same as for speech.
    3. We add that if a RECOGNIZE request fails due to an error, any
currently queued RECOGNIZE requests behind the failed one should also be
removed from the queue. The RECOGNITON-COMPLETE event for the failed
RECOGNIZE request MUST contain the request-id of the failed request
followed by the list of queued/pending request-ids that were terminted
because of the failure. Default value for "Cancel-If-Queue" header field
is "false". Which allows for queing of requests, same as today.
    4. Modify Cancel-if-Queue to remove language about what happens to
queued SPEAK/RECOGNIZE requests when the active one fails. This has no
bearing on the behaviour of this header field and should already have
been covered when discussing the queeing behaviour for SPEAK or
RECOGNIZE. 

What do you think.
Sarvi

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of David R. Oran
     Sent: Friday, June 03, 2005 8:46 AM
     To: Dave Burke
     Cc: [email-masked]
     Subject: Re: [Speechsc] Recognizer queueing versus 
     synthesizer queueing

     On Jun 3, 2005, at 11:27 AM, Dave Burke wrote:
     
     > It's probably worth pointing out that SPEAK and 
     RECOGNIZE are not 
     > really anti-symmetric since (a) RECOGNIZE requests 
     typically require 
     > the audio input to be synchronised with the recognition 
     request and 
     > (b) subsequent recognition actions normally depend on 
     the results of 
     > previous recognition action(s).
     >
     > I don't think queuing of RECOGNIZE requests is useful 
     and by removing 
     > it altogether we also get consistency with RECORD.
     >
     That works for me. The current machinery for recognize 
     queueing is, well, peculiar, and if we don't need it I'd 
     just as soon get rid of it.
     
     Let's see how others feel first.
     
     Dave.
     
     > Dave
     >
     > ----- Original Message ----- From: "David R. Oran" 
     <[email-masked]>
     > To: <[email-masked]>
     > Sent: Friday, June 03, 2005 3:16 PM
     > Subject: [Speechsc] Recognizer queueing versus 
     synthesizer queueing
     >
     >
     >
     >> For some reason that escapes me these work completely 
     differently.
     >>
     >> The reasons may be historical, or possibly because we thought   
     >> queueing of requests processing media input were 
     different from   
     >> requests processing media output.
     >>
     >> To refresh memory, SPEAK requests are queued when the 
     client issues  
     >> one while a current SPEAK is active. If the current request is  
     >> canceled for any reason (stop, cancel-on-barge-in,
     >> etc.) the pending  SPEAK requests are nuked, and the completion 
     >> response for the  cancelled SPEAK contains a header 
     with the request 
     >> id's of the other  requests in the queue that are now history.
     >>
     >> In RECOGNIZE, there is a header (cancel-if-queue) 
     saying whether or  
     >> not to cancel the current request if the client tries to queue  
     >> another one. If a request is cancelled, the pending 
     requests are also  
     >> canceled but each returns a separate completion event. 
     For some  
     >> reason this header is defined as mandatory rather than 
     having a  
     >> default value.
     >>
     >> It seems at a minimum inelegant, to have this disparate 
     machinery,  
     >> and quite possibly a pain for servers which have a 
     single scheduler 
     >> implementation for their different resources to have to 
     implement two 
     >> entirely different schemes, not to mention clients 
     which really  
     >> should be simple and not have to worry about this kind of 
     >> inconsistency.
     >>
     >> If it's too late to change this, I suppose we can live with it.
     >>
     >> If the WG will entertain a technical change, let me 
     suggest that the 
     >> other resources adopt the scheduling scheme used by 
     SPEAK, since it's 
     >> simpler, fully general, and well-described in the spec 
     (the recognize 
     >> scheme has some pretty tortured language to explain 
     what's supposed  
     >> to happen). If we do this, the cancel-on-queue header 
     goes away and  
     >> the active-request-ids header gets adopted by the other 
     resources.
     >>
     >> I'd probably move the material on request queueing to 
     the common   
     >> protocol section if we go this route, rather than 
     repeating all the  
     >> stuff in each resource.
     >>
     >> Please respond with views, because I don't want to 
     adopt such a   
     >> change lightly.
     >>
     >> Dave.
     >>
     >> _______________________________________________
     >> Speechsc mailing list
     >> [email-masked]
     >> https://www1.ietf.org/mailman/listinfo/speechsc
     >
     
     _______________________________________________
     Speechsc mailing list
     [email-masked]
     https://www1.ietf.org/mailman/listinfo/speechsc

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