Subject: RE: [Speechsc] "Race" condition between RECOGNIZE.request and med ia

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 8 Jun 2005 18:31:43 -0700

Done't we want to specifically disallow using data buffered before the
RECOGNIZE method is received by the resource. The problem is some one is
going to implement some amount of buffering at the input. If someone set
this to be large you could be recognizing data from something that was
spoken well before the recognize. 

That's what we are trying to avoid by this paragraph.

I think I like Dave's proposal, that the recognizer use at most a fixed
length/in time of data that is already in the buffer when the RECOGNIZE
method is received by the recognizer. Limiting it to 1 or 2 RTT sounds
reasonable.

Sarvi 
     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of David R. Oran
     Sent: Wednesday, June 08, 2005 5:31 AM
     To: Reifenrath, Klaus
     Cc: [email-masked]'; [email-masked]'
     Subject: Re: [Speechsc] "Race" condition between 
     RECOGNIZE.request and med ia

     On Jun 8, 2005, at 7:56 AM, Reifenrath, Klaus wrote:
     
     > I also vote for removing the old and fuzzy MRCPv1 text 
     "Note that 
     > since the audio and the messages are carried over separate 
     > communication paths there may be a race condition 
     between the start of 
     > the flow of audio and the receipt of the RECOGNIZE method. For 
     > example, if an audio flow is started by the client at 
     the same time as 
     > the RECOGNIZE method is sent, either the audio or the 
     RECOGNIZE can 
     > arrive at the recognizer first. As another example, the 
     client may 
     > chose to continuously send audio to the Server and 
     signal the Server 
     > to recognize using the RECOGNIZE method. A number of 
     mechanisms exist 
     > to resolve this condition and the mechanism chosen is 
     left to the 
     > implementers of recognition resource."
     >
     > BUT I agree with Brett, we should keep the last sentence 
     (that was not 
     > in the MRCPv1 spec):
     > "The recognizer should expect the media to start flowing when it 
     > receives the recognize request, but should not buffer 
     anything it 
     > receives beforehand."
     Ok, I think we have consensus on this.
     
     > BTW: Shouldn't the 'should' be a 'SHOULD' in the last sentence?
     >
     I don't think so. My concern is that implementers take 
     this literally and try to dump an active jitter buffer 
     when they receive the RECOGNIZE, which is unnecessary and 
     probalby the wrong thing to do.  
     If in fact the client starts sending audio at the exact 
     moment it issues the RECOGNIZE, it is in fact likely that 
     a few media packets will in fact arrive before the 
     RECOGNIZE, because of the differential QoS the media 
     likely has. There is also the possibility of a lost 
     control packet and TCP retransmission.
     
     So, I think the point is that we want semantics that do 
     not require extra server machinery to deal with the cases 
     where the media and control channels become mis-synchronized.
     
     I think the above wording is ok, but if we want to capture 
     this point accurately, an alternative wording might be:
     
     "The recognizer should expect the media to start flowing 
     when it receives the recognize request, but need not take 
     special action to buffer anything it receives beforehand 
     to process media which arrives before the MRCPv2 control 
     channel message."
     
     Dave.
     
     > Klaus
     >
     >
     > -----Original Message-----
     > From: Qiru Zhou [mailto:[email-masked]]
     > Sent: Dienstag, 7. Juni 2005 23:45
     > To: Brett Gavagni
     > Cc: [email-masked] ((((E-mail)))); [email-masked]
     > Subject: Re: [Speechsc] "Race" condition between 
     RECOGNIZE.request  
     > and media
     >
     > To me, this line implies that RECOGNIZE is the trigger 
     signal to let
     > recognizer to start listening (buffer and do 
     recognition). It is  
     > not clear
     > to me why the recognizer need to buffer audio before the 
     RECOGNIZE  
     > message
     > and it is ambiguous to do that (how early and how much data to  
     > buffer). A
     > particular implementation may choose to do something 
     like that for  
     > signal
     > processing purpose I guess but it is the implementation 
     detail. So  
     > I'd vote
     > keep the line below and nuke the rest.
     >
     > -- Qiru
     >
     > Brett Gavagni wrote:
     >
     >> I would vote to leave the wording, or at a minimum keep 
     the following
     >> line. This statement can be quite helpful in mitigating 
     potential
     >> client/server interoperability issues.
     >>
     >> "The recognizer should expect the media to start flowing when it
     >> receives the recognize request, but should not buffer 
     anything it
     >> receives beforehand."
     >>
     >> Thanks,
     >>
     >> Brett Gavagni
     >> WebSphere Voice Server Development
     >> http://www-306.ibm.com/software/pervasive/voice_server/
     >> [email-masked]
     >>
     >>
     >>
     >>
     >> "David R. Oran" <[email-masked]>
     >> Sent by: [email-masked]
     >> 06/07/2005 09:53 AM
     >>
     >> To
     >> "[email-masked] ((((E-mail))))" <[email-masked]> cc
     >>
     >> Subject
     >> [Speechsc] "Race" condition between RECOGNIZE.request and media
     >>
     >>
     >>
     >>
     >>
     >>
     >> The text says:
     >>
     >> "Note that since the audio and the messages are carried 
     over separate
     >> communication paths there may be a race condition between the  
     >> start of
     >> the flow of audio and the receipt of the RECOGNIZE method. For
     >> example, if an audio flow is started by the client at the same  
     >> time as
     >> the RECOGNIZE method is sent, either the audio or the 
     RECOGNIZE can
     >> arrive at the recognizer first. As another example, the 
     client may
     >> chose to continuously send audio to the Server and 
     signal the Server
     >> to recognize using the RECOGNIZE method. A number of 
     mechanisms exist
     >> to resolve this condition and the mechanism chosen is 
     left to the
     >> implementers of recognition resource. The recognizer 
     should expect  
     >> the
     >> media to start flowing when it receives the recognize 
     request, but
     >> should not buffer anything it receives beforehand."
     >>
     >> Either this race condition doesn't matter, in which 
     case we should
     >> either just nuke this paragraph or take out the 
     should/should not
     >> guidance at the end, or it does matter, in which case this  
     >> material is
     >> wholly inadequate.
     >>
     >> If the synchronization of the control and media 
     channels matters,  
     >> then
     >> we really do need to fix the protocol. Luckily, this is 
     relatively
     >> easy to do:
     >>
     >> a) recommend that servers with recognizers buffer at 
     least an RTT
     >> worth of media.
     >> b) include an NTP timestamp of where in the the input media
     >> recognition should start in a RECOGNIZE request header.
     >> c) define an error to cover the "lost media" case.
     >>
     >> My gut tells me that for recognition none of this is 
     necessary and we
     >> should just nuke the paragraph above as making 
     implementers think
     >> about something they can only screw up if they work too 
     hard at it.
     >>
     >> _______________________________________________
     >> 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

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