Subject: [Speechsc] "Race" condition between RECOGNIZE.request and media

From: "David R. Oran" <[email-masked]>
Date: Tue, 7 Jun 2005 09:53:17 -0400

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

---

From: Brett Gavagni <[email-masked]>
Date: Tue, 7 Jun 2005 16:23:13 -0400

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:

---

From: Qiru Zhou <[email-masked]>
Date: Tue, 07 Jun 2005 17:42:50 -0400

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). 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. Therefore,
no race condition exist.

-- Qiru

---

From: Qiru Zhou <[email-masked]>
Date: Tue, 07 Jun 2005 17:44:38 -0400

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