Subject: RE: [Speechsc] Draft Minutes

From: "Eric Burger" <[email-masked]>
Date: Wed, 3 Mar 2004 13:25:41 -0500

On the barge v. hotword issue, Jeff's interpretation is correct.

On the TLS issue: because of the security and privacy issues surrounding identification credentials (e.g., SV templates) and recognition results (e.g., credit card numbers), MRCPv2 servers MUST have some baseline security mechanism.  This guarantees to clients that, if they desire, they KNOW that they can make secure requests.

That said, do not confuse "MUST support TLS" with "MUST *use* TLS".  It is up to the client to chose to use TLS or not.

-----Original Message-----
From: Jeff Kusnitz [mailto:[email-masked]]
Sent: Wednesday, March 03, 2004 12:46 PM
To: Daniel Burnett
Cc: Eric Burger; IETF SPEECHSC (E-mail); [email-masked]
Subject: RE: [Speechsc] Draft Minutes

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

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

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

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

---

From: "Reifenrath, Klaus" <[email-masked]>
Date: Thu, 4 Mar 2004 08:25:37 -0500

I am missing one other open issue "The SPEECH-MARKER event for TTS doesn't
indicate the time of the event". 
See 2) of Brian Eberman's mail 
http://www.ietf.org/mail-archive/working-groups/speechsc/current/msg00291.ht
ml

With the current interface lip-synching cannot be realized for example.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Mittwoch, 3. März 2004 07:06
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.