Subject: RE: [Speechsc] new-audio-channel

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 15 Jun 2005 11:49:40 -0700

Comments inline. 

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of David R. Oran
     Sent: Wednesday, June 15, 2005 8:24 AM
     To: [email-masked] ((((E-mail))))
     Subject: [Speechsc] new-audio-channel
     
     Sorry to keep barraging the WG with these editing points - 
     I'm really getting close to the end of the chair review of 
     the spec.
     
     This query concerns the "new-audio-channel" header on 
     RECOGNIZE requests.
     
     1. Shouldn't this be called "audio-source-changed"? It 
     might not be strictly speaking "new". And it may not be 
     the channel that changed (e.g. My MRCPv2 client might be 
     on an IP phone and the user switches from speakerphone to headset).
     
     2. Do we need to say anything about whether servers ought 
     to have separate resource state on one session from 
     different SSRCs of a single media session? The client may 
     not even know this is happening.
     
     3. The current text says MUST in a few places that seem 
     restrictive and unenforceable:
     
     "This header MAY be specified in a RECOGNIZE request and 
     allows the client to tell the server that, from this point 
     on, further input audio comes from a different audio 
     source, channel or speaker. If the recognition resource 
     had collected any input statistics or adaptation state, it 
     MUST discard the state and start fresh for this RECOGNIZE 
     request. Note that if there are multiple resources on the 
     same SIP dialog that may be collecting or using this data, 
     the client MUST declare a new audio channel for all these 
     resources. This helps in a numbe of use case, including 
     where the client wishes to reuse an open recognition 
     session with an existing media session for multiple 
     telephone calls."
     
     The first MUST is too restrictive because some adaptations 
     may be independent of the source or channel.
The first MUST is important for a functionaility standpoint i.e the
server MUST recognize this is a new channel and and do what is
necessary. 
But I think what you are getting at is that its interpretation i.e. what
a resource must do to get ready for this change in audio source should
be left to the server implementation and technology behind the server.
If that is correct, I am not sure 
How to word this differently. How about,
 
"The recognition resource MUST do what is appropriate for the specific
recognition technology, which includes but is not limited to discarding
any collected input statistics or adaptation state before starting the
RECOGNIZE request.

     The second MUST is too restrictive because the client may 
     not even be aware of the change, and the server can't 
     depend on the client detection working deterministically.

Here too the must is to cover cases where one audio pipe is shared
between, say the recognition resource and a verification resource. They
both may have a common front end or some common statistics that may be
collecting. When a RECOGNIZE to recognition resource has this header it
tells the system that the input source has changed, which means that
noise and other statistics that were collected until that point are of
no use anymore. That will automatically have to be the case for the
verification resource as well even if the VERIFY command sometime later
did not send a new-audio-channel header in it. Infact it shouldn't have
to if the media channel is shared between the resources. 

How about the following text instead of the current text with the MUST.

"Note that if there are multiple resources that are sharing a media pipe
and are collecting or using this data, and the client issues this header
to one of the resources, the reset operation applies to all resources
that use the shared media stream."

Sarvi
     
     I thinks both of these ought to be SHOULDs.
     
     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