Subject: [Speechsc] new-audio-channel

From: "David R. Oran" <[email-masked]>
Date: Wed, 15 Jun 2005 11:24:02 -0400

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

I thinks both of these ought to be SHOULDs.

Dave.

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