Subject: RE: [Speechsc] Draft Minutes

From: "Daniel Burnett" <[email-masked]>
Date: Wed, 3 Mar 2004 06:35:34 -0800

Eric,

Thanks for sending the minutes.  Please accept my apologies again for not being able to attend.

I have a question about your "speech vs hotword barge-in" topic.  "speech" and "hotword" are recognition types distinguished by what happens on a rejection (failure to match the speech to a grammar path).  Barge-in refers to whether or not a recognizer listens for speech while a prompt is playing.  My understanding is that these features are orthogonal.  Can you explain the question here?

Also, what does MANDATORY support for TLS (for MRCP) mean?  In particular, what requirements does it place on server implementations of MRCP?

-- dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Eric Burger
Sent: Tuesday, March 02, 2004 10:06 PM
To: IETF SPEECHSC (E-mail)
Subject: [Speechsc] Draft Minutes

Awesome job by Magnus!

Please comment by 3/12.

SpeechSC Minutes 040302 17.00-18.00
Magnus Westerlund

Chairs Introduction and WG Status
---------------------------------

The WG chairs started with agenda bashing, followed up with presenting 
the WG status. The SpeechSC requirements document has been approved by 
the IESG with some smaller edits requested. However the document was 
lost between IESG and the RFC-Editor. This has delayed the publication. 
There is a milestone to request publication of any drafts by October 03. 
The current goal is to request publication no later than October 04.

Separate Record Function Discussion
-----------------------------------

The question to the WG was: Should there be a explicit recording 
function in MRCPv2? The draft version 01 does not have a pure recording 
function. Recording behaviour is determined by using speech recognition 
or at least voice activity detection. There was some discussion around 
the use cases for recording. One use cases mentioned for this behaviour 
is voice mail recording, where the recording is controlled through voice 
recognition. Therefore there is desire to have a RECORD resource, a 
RECORD method which has has a header indicating how the recorder should 
perform speech recognition. Another use case that match this behaviour 
is recording for training, or verification. The conclusion of the 
discussion was there is no expressed need for blind recording, any one 
needing this can use RTSP record. Also this use case should be mentioned 
in the protocol spec to motivate the functionality.

MRCPv2
------

The draft version 02 was made available on mailing list, will be 
submitted when [email-masked] opens again. A number of open 
issues where discussed. Presentation was made by Sarvi Shanmugham.

NAT traversal for the MRCPv2 TCP control channel setup: As long as only 
one end-point is in a private space it is possible to make things work. 
If both entities are in a private space a relay will be needed. To get 
TCP to work some signalling to indicate how the TCP connect should be 
done is needed. This is similar to the MMUSIC work on Co-Media 
(draft-ietf-mmusic-sdp-comedia-05).

Do we need an INTERMEDIATE-RECOG-RESULT: The WG was questioned if there 
any need for this functionality. Nobody expressed any desire for it. 
Unless anyone on the mailing list expresses a real need for this 
functionality, it will not be included. A mail will be sent to the 
mailing list to ask this question.

Speech or hotword barge-in: Eric Burger asked if there is any protocol 
difference between the two. The answer is that real issues is actually 
to identify what type of barge in that has happened, as this may exist 
policies accepting either of the types. The conclusion is to confirm the 
with the mailing list that this feature is included if a solution exist.

Multiple instances of a Header field Vs Single header field with 
multiple values: First there where some discussion around the historical 
reasons. Then it was asked;
Are any reason why not to leave it as it is? As none had a real reason 
to change it from how SIP, and HTTP handles headers? The list shall be 
asked if they no a reason to change it.

Header field ranges Confidence-Threshold, Speed-Vs-Accuracy etc(0.0 - 
1.0 or 0 - 100): There was consensus in the room to use 0.0-1.0 ranges. 
It will be confirmed by the mailing list.

Proposal to specify a fixed header with a vendor identifier and a vendor 
registry for the Recognizer context block: David Oran stated that IESG 
has concerns with vendor specific extensions that make things fail. To 
make this work, the specification needs to ensure that it is optional 
and can be ignored. No new error cases should be generated by this. Also 
the motivation of this was discussed, allowing some resources to work 
better, however it is not required to. A proposal was: The client MUST 
copy the header field to the next resource within the session. Some 
discussion of making the MUST a SHOULD. After some more discussion 
around the issues the following conclusion was reached in the room: 
Client must copy, Server must not barf.
Server is not allowed to reject a request based on empty or non-present 
header.

The WG should also look into if there exist an already existing vendor 
registry that can be leveraged, for example with IANA.

DTMF support and RFC 2833 support: The conclusion was: If one supports 
DTMF, one MUST  support RFC 2833. Confirm consensus on the mailing list.

Security support - sips: ? https? Digest ? SRTP?: What is the minimal 
security support to implement. To help interoperability it is normal to 
require a single solution as being mandatory when having security 
features. The discussion was split into the different parts. For the 
MRCP channel it where consensus for having MANDATORY support of TLS. For 
the media channel, the initial proposal from David Oran was: when 
transmitting media streams requiring security one uses either SRTP or 
IPSec. Further discussion made the observation that no other place in 
the system does there exist a requirement for IPSec. Therefore there 
might be a reason for looking more a SRTP. Further comments was that the 
WG should early on contact security area advisors to have them check the 
proposal, thus avoiding late surprise. Another question was, how does 
one indicate in SDP that one should use IPSec for a media stream?

Define grammars one at a time: This proposal was supported by the room.

PAUSE on Barge In: Is there a need to have this instead of Stop on barge 
in? There where no comments raised on this topic.

There is two proposal for similar functionality of determining available 
functionality: "OPTION commands for m-lines" and "SIP Callee capability 
for resource description and capability". The proposal is to check if 
the SIP Callee method can solve everything. IF not then one needs to 
look into SIP OPTIONS.

3PCC model of connecting with the MRCPv2 server: It was proposed that 
using Offer-Answer will solve the problem. Invite response can be the 
initial offer.

Specification conclusion: The specification is believed to be 
functionality wise completed. However it needs review to ensure that 
everything works. The WG chairs asked Sarvi if was possible to have a 
target of working group last call by end of April, which he confirmed.

_______________________________________________
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: Jeff Kusnitz <[email-masked]>
Date: Wed, 3 Mar 2004 09:46:27 -0800

Dan Burnett wrote on 03/03/2004 06:35:34 AM:

> I have a question about your "speech vs hotword barge-in" topic. 
> "speech" and "hotword" are recognition types distinguished by what 
> happens on a rejection (failure to match the speech to a grammar 
> path).  Barge-in refers to whether or not a recognizer listens for 
> speech while a prompt is playing.  My understanding is that these 
> features are orthogonal.  Can you explain the question here?

If I'm not mistaken (I also was not able to attend), the "speech vs 
hotword barge-in" request came from me - it was a request for a header 
that would map to the VoiceXML bargeintype attribute - when set to 
"speech", the recognition engine would send a bargein message to the 
client/tts engine immediately, but when set to "hotword", the bargein 
message would only be sent in the event of a successful recognition.

Thanks,
Jeff

---

From: Sarvi Shanmugham <[email-masked]>
Date: Wed, 03 Mar 2004 17:11:04 -0800

comments inline.

> message would only be sent in the event of a successful recognition. 

Your interpretation of the problem is right.
I believe there are 2 aspects to the problem or its solution.
   1. Is the Kill-On-Barge-In header field may need to 3 value choices, 
"speech", hotword", "none". This header field tells the synthesizer when 
it should kill the prompt.
   2. The Barg-In-Occured method may need a header describing what type 
of barge-in occured, "speech" or  "htoword".

This is because, there could be a regular recognizer and a hotword 
recognizer active at the same time, and it could be on the same of or a 
different box from the Synthesizer.  The synthesizer could potentially 
get 2 separate barge-in events, and the synthesizer needs to know when 
to kill the the prompt.

Sarvi

---

From: Alex Lee <[email-masked]>
Date: Thu, 25 Mar 2004 18:08:32 -0500

For the "hotword recognitions", what should the semantics be for the START-OF-SPEECH
event that comes back from the recognizer to the client.  There seems
to be 4 different approaches here:

1) There shouldn't be any START-OF-SPEECH event to be sent back from
recognizer

2) The START-OF-SPEECH event should be sent back when the recognizer
first detects speech, whether the speech matches the hotword parameter
and grammar or not.  If the speech doesn't match the grammar, nothing
further would be sent from the recognizer.  After a while the speaker
stops and starts speaking again and matches the grammar, then the RECOGNITION-COMPLETE
would be sent.  However, there won't be any more START-OF-SPEECH for
the other times the recognizer detects speech.

3) The START-OF-SPEECH event should be sent back to the client just
before the RECOGNITION-COMPLETE event.

4) There should be multiple START-OF-SPEECH event sent back from the
server to the client, where each time the recognizer detects speech, it
will send the START-OF-SPEECH event back to the client.

To me, I think (1) would be the correct behaviour, because a "START-OF-SPEECH"
event doesn't really make sense for hotword mode.  My second choice
would be (4).

Any suggestions?

Alex...

Jeff Kusnitz wrote:

> Thanks for sending the minutes.  Please accept
my apologies again

> for not being able to attend.

> features are orthogonal.  Can you explain
the question here?

If I'm not mistaken (I also was not able to attend),
the "speech vs hotword barge-in" request came from me - it was a request
for a header that would map to the VoiceXML bargeintype attribute - when
set to "speech", the recognition engine would send a bargein message to
the client/tts engine immediately, but when set to "hotword", the bargein
message would only be sent in the event of a successful recognition.

Thanks,

Jeff

---

From: Jeff Kusnitz <[email-masked]>
Date: Thu, 25 Mar 2004 16:18:36 -0800

[email-masked] wrote on 03/25/2004 03:08:32 PM:

> For the "hotword recognitions", what should the semantics be for the
> START-OF-SPEECH event that comes back from the recognizer to the 
> client.  There seems to be 4 different approaches here: 
> first detects speech, whether the speech matches the hotword 
> parameter and grammar or not.  If the speech doesn't match the 
> grammar, nothing further would be sent from the recognizer.  After a
> while the speaker stops and starts speaking again and matches the 
> grammar, then the RECOGNITION-COMPLETE would be sent.  However, 
> there won't be any more START-OF-SPEECH for the other times the 
> recognizer detects speech. 
> server to the client, where each time the recognizer detects speech,
> it will send the START-OF-SPEECH event back to the client. 
> To me, I think (1) would be the correct behaviour, because a "START-
> OF-SPEECH" event doesn't really make sense for hotword mode.  My 
> second choice would be (4). 
> Any suggestions? 
> Alex... 

I like a derivative of option 4 - a START-OF-SPEECH message would be sent 
by the recognizer each time it detected the start of speech, independent 
of the bargeintype.  I'd also propose that an END-OF-SPEECH message be 
sent back to the client as well when the recognizer detects the end of 
speech.  I can see using both of these in the client to do "things" with 
the prompts.  For example, when speech is first detected, don't halt the 
prompt, but play it a little quieter, so the user knows something's 
happening.  And at end of speech, turn the volume back up (though a bit of 
smarts here would be useful - only turn it up if a recognition-complete 
message isn't coming as well)

The client can always ignore messages, but it can't make things up that 
aren't there.  But I do see where this starts to become "chatty" - I'm ok 
with tha if it improves the user experience.

Thanks,
Jeff