Subject: [Speechsc] Draft Minutes

From: "Eric Burger" <[email-masked]>
Date: Wed, 3 Mar 2004 01:06:10 -0500

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

---

From: Jeff Kusnitz <[email-masked]>
Date: Wed, 10 Mar 2004 19:39:07 -0800

> header. check on this, not clear what it's saying..

Was the above text in response to my request in January to allow 
vendor-specific-parameters on all request (SET/GET-PARAMS, DEFINE-GRAMMAR 
and RECOGNIZE)?

I have a related request (yes, I know, it never ends with me and these 
requests).  When a client issues a DEFINE-GRAMMAR or RECOGNIZE request 
specifying an external grammar, all it can currently specify is the URI 
for the grammar.  Sometimes that's not enough.  Specifically, if the 
grammar is coming from an application server that's keeping some sort of 
session state via cookies.  These cookies need to be passed from the reco 
server to the app server when it fetches the grammar (the same would hold 
true for audio files on SPEAK requests).

There's no way to do this currently, so I would propose adding a "cookies" 
header to the relevant requests (SET/GET-PARAMS, SPEAK, DEFINE-GRAMMAR and 
RECOGNIZE).

What does everyone think?

Thanks,
Jeff

---

From: Jerry Carter <[email-masked]>
Date: Thu, 11 Mar 2004 08:38:18 -0500

On Mar 11, 2004, at 5:21 AM, Dave Burke wrote:

> The problem of passing the cookie jar is one of a number of issues 
> that has
> come up with us internally as a consequence of collaborative, 
> distributed
> user agents (specifically VoiceXML interpreters, SSML processors, and 
> SRGS
> processors).
>
> The problem arises in reasonably straightforward scenarios e.g. 
> consider a
> VoiceXML MRCP client which fetches a VoiceXML page from an app server. 
> App
> server stores some objects server-side on behalf of the VoiceXML user
> agent - a handle to these objects is identified by a "session ID" 
> contained
> in a returned cookie. Included in the returned VoiceXML page is some 
> SSML
> with an <audio> element, which references the app server to obtain the 
> audio
> stream. The SSML processor user agent processes the SSML on behalf of 
> the
> VoiceXML user agent (invoked through MRCP) and makes a HTTP request to
> dereference the <audio> URI. The app server wishes to use the server 
> side
> objects created earlier to customise the audio for the caller but has 
> no
> handle to them since the session ID is only present in the cookie jar 
> on the
> VoiceXML interpreter user agent.
>
> I am happy to help specify a proposal for handling cookies in MRCP if
> required (if Jeff can review).

I will also look forward to this proposal.  I've encountered this issue 
as well and believe that the lack of cookie jar handling is a real 
deficiency in MRCP.

-=- Jerry Carter

---

From: Sarvi Shanmugham <[email-masked]>
Date: Thu, 11 Mar 2004 10:58:03 -0800

Would be glad to add to the draft if ou could propose a solution and 
provide the text.

On a related note, I am not sure if security has any related problems.

Thanks,
Sarvi

Dave Burke wrote:

>The problem of passing the cookie jar is one of a number of issues that has
>come up with us internally as a consequence of collaborative, distributed
>user agents (specifically VoiceXML interpreters, SSML processors, and SRGS
>processors).
>
>The problem arises in reasonably straightforward scenarios e.g. consider a
>VoiceXML MRCP client which fetches a VoiceXML page from an app server. App
>agent - a handle to these objects is identified by a "session ID" contained
>in a returned cookie. Included in the returned VoiceXML page is some SSML
>with an <audio> element, which references the app server to obtain the audio
>stream. The SSML processor user agent processes the SSML on behalf of the
>dereference the <audio> URI. The app server wishes to use the server side
>objects created earlier to customise the audio for the caller but has no
>handle to them since the session ID is only present in the cookie jar on the
>- Dave
>----- Original Message -----
>From: "Jeff Kusnitz" <[email-masked]>
>To: "IETF SPEECHSC (E-mail)" <[email-masked]>
>Sent: Thursday, March 11, 2004 3:39 AM
>Subject: Re: [Speechsc] Draft Minutes - clarification/additional request
>
>
>  
>

---

From: Sarvi Shanmugham <[email-masked]>
Date: Thu, 11 Mar 2004 00:59:12 -0800

comments inline.

>vendor-specific-parameters on all request (SET/GET-PARAMS, DEFINE-GRAMMAR 
Actually note. This is related to the Vendor-Specific-Context block that 
server can provide. When the client has uses a recognizer resource, for 
example, to process media from a phone call, it collects some 
lcharactersitcs and other information about the quality of the media 
session. When the client wants to switch media servers, this information 
collected at server1 may give server2 a headstart in its recognition 
operation. This recognizer-context-block can be requested from server1 
by the client and provided to server2 when it switches servers.  If the 
servers are from the same vendor they will be able recognize the context 
block from the vendor-type field and use it.

So the conclusion meeting was that the client when it switches servers 
MUST attempt to get this block from server1 and provide it to server2. 
But the server should barf when the client request such a context block 
or tries to provide one to it. If it recognizes it should use it, else 
it should silently ignore it.

>What does everyone think?
Let me get back to you on this later.

Sarvi

---

From: "Dave Burke" <[email-masked]>
Date: Thu, 11 Mar 2004 10:21:08 -0000

- Dave