Subject: Re: [Speechsc] Draft Minutes - clarification/additional request

From: "John Potemri" <[email-masked]>
Date: Thu, 11 Mar 2004 09:29:40 -0500

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
[email-masked]

----- Message from Sarvi Shanmugham <[email-masked]> on Thu, 11 Mar 2004
00:59:12 -0800 -----
                                                         
      To: Jeff Kusnitz <[email-masked]>                   
                                                         
      cc: "IETF SPEECHSC (E-mail)" <[email-masked]>   
                                                         
 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
      [email-masked]
      https://www1.ietf.org/mailman/listinfo/speechsc

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

---

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

This was not for the purpose of proxies. This is for purpose of 
switching media servers for reasons such as Language capability etc.  
These could be completely different servers. So when the call has been 
using server1 for for a couple of minutes, line information that it 
collected could be usefull to another server operating on the same 
line.  The client is the one that knows that the 2 resources are being 
used for the same media or line. If client does not co-ordinate this 
information transfer, how do you think should.

And if I remember right, speechwork, nuance or both were proponants of 
this features in MRCPv1.

Sarvi