[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Speechsc] Draft Minutes - clarification/additional request
Perhaps I haven't followed the thread of discussion well enough. Anytime I
see that a client MUST do something, I have to wonder.
A client getting a "context" from an MRCP server to supply it to another
MRCP server?
And this only works if the MRCP servers are from the same vendor?
First off, it sounds strange when I read it. Perhaps there is some "real"
problem being solved (line adaptation or something), but I'm suprised to
see that we would put that burden on the client.
I believe that vendors providing MRCP interfaces to speech resources today
front-ending their resource pool (call it proxying).
Take for instance, N clients, 2 MRCP servers for a specific vendor
[client 1] -> [MRCP Server Vendor A - 1] -> [ASR Resource Vendor A - 1]
[client 2] [MRCP Server Vendor A - 1] [ASR Resource Vendor A - 2]
: :
[client N] [ASR Resource Vendor A - M]
If the ASR resource changes, why does the client need to touch anything?
I think that vendors can optimize for this behavior within the MRCP server.
This can address optimizing resources, fail-over of resources and the case
where a client requests a different resource (language, type of recognizer,
etc.). The MRCP server makes sure any internal context is optimized for
that vendor. The client doesn't see it.
If you have MRCP resources from another vendor, we already said that we
can't pass the context.
Maybe I've failed to follow the discussion. Or maybe you could elaborate
more. Even better, I'd like to hear what the ASR vendors are thinking.
Regards,
John
P.S. On the topic of vendor specific requests, I trust there will always be
an escape for the conveyance of parameters, etc. with no effect on overall
state model of the protocol. And if that's the case, a vendor can always
provide "context" to clients and support "context" as an extension to be
pushed at them. They would have to document it for users of their MRCP
implementation, which being optional, can always be ignored by the client.
John Potemri
NMS Communications
100 Crossing Blvd
Framingham, MA 01702
+1-508-271-1369
john_potemri@nmss.com
----- Message from Sarvi Shanmugham <sarvi@cisco.com> on Thu, 11 Mar 2004
00:59:12 -0800 -----
To: Jeff Kusnitz <jk@us.ibm.com>
cc: "IETF SPEECHSC (E-mail)" <speechsc@ietf.org>
Subject: Re: [Speechsc] Draft Minutes -
clarification/additional request
comments inline.
Jeff Kusnitz wrote:
Eric Burger wrote on 03/02/2004 10:06:10 PM:
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. 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)?
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.
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?
Let me get back to you on this later.
Sarvi
Thanks,
Jeff
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc