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

From: "Reifenrath, Klaus" <[email-masked]>
Date: Wed, 8 Jun 2005 07:56:01 -0400

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."

BTW: Shouldn't the 'should' be a 'SHOULD' in the last sentence?

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

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 8 Jun 2005 08:30:41 -0400

> receives the recognize request, but should not buffer anything it
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.