Subject: RE: [Speechsc] Server capabilities

From: "Reifenrath, Klaus" <[email-masked]>
Date: Wed, 15 Jun 2005 12:44:00 -0400

>From my point of view it is even more important to enable the client to
request the right MRCP that has defined capabilities (installed languages,
"instantly available" grammars, support of some optional MRCP method, ...).
In earlier threads and F2F meetings we discussed preference based SIP
routing. But this unfortunately never made it into the spec.

Your option c) seems to be one step in this direction.

Regards,
Klaus

-----Original Message-----
From: David R. Oran [mailto:[email-masked]] 
Sent: Mittwoch, 15. Juni 2005 16:33
To: [email-masked] ((((E-mail))))
Subject: [Speechsc] Server capabilities

This message was prompted by one aspect of the discussion on the list about
large grammars, which is how a client can figure out in advance just what a
server can and can't do, so it isn't "unpleasantly surprised" at the instant
it issues a method.

The current specification walks a fine line between giving flexibility to
server implementers and giving clients a sufficient degree of control over
server behavior. For example we have things like multiple jump-length units
which a server may or may not support, server-specific default values for
confidence-threshold and speed-vs-accuracy, and a bunch of others.

There is some for this support, including:
1) through SDP and SIP OPTIONS the client can discover what resources the
server supports and what media formats it can process.
2) through GET-PARAMS on a particular session with a resource the client can
discover any implementation-specific server default values for MRCPv2
protocol headers.

My question to the WG is what, if anything do we need beyond these?

Here's a small list of candidates. Feel free to comment and/or propose your
own:

a) we may want/need a way for the server to determine what audio formats a
client supports for the purposes of returning captured audio. Right now we
don't even have a way for the client to tell the server what format it wants
audio returned in, so we at least have to remedy that omission.

b) we may want a way for a client to learn the current list of "instantly
available" grammars the server has handy and which are in some way
"guaranteed" to persist for a while.

c) we may want a form of GET-PARAMS which fetches session-independent server
information. One way to do this is to define a MRCPv2-frag content type
(like we have with sipfrag). That way a SIP OPTIONs to an MRCPv2 server can
return an MRCP-specific body with all that interesting information about
server capabilities.

<chair hat>
I don't want this to necessary turn into a free-for-all, because we really
do want to reach closure on the spec and get it to last call.  
My target for finishing my chair review and editing is the end of this week.
</chair hat>

_______________________________________________
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: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 15 Jun 2005 12:49:25 -0700

This comment is only relating to your suggestion to use option b to
address resolving binary grammar uri.
I think the right way to do this would be to define a file format for
this binary across vendors and use it. This wouldn't have to be very
complex, at a minimum agree on standard header for the beginning of this
file that identifies vendor and format version number and the rest of
the binary file could be vendor specific. 

No need to address this through the MRCP specification.

Sarvi 

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of Corby Anderson
     Sent: Wednesday, June 15, 2005 12:20 PM
     To: [email-masked]
     Subject: Re: [Speechsc] Server capabilities
     
     I'm very much in favor of b).
     
     In the "managing big grammars" thread we were considering 
     about permitting URIs to reference binary grammars as well 
     as source grammars (was that ever codified?).  How about 
     having some way for the server to indicate what 
     vendor/version it is.  For heterogenous MRCP server 
     environments, this would allow clients to give the right 
     grammar binary URIs to the right servers.
     
     Corby Anderson
     Tellme Networks, Inc.
     
     David R. Oran wrote:
     
     > This message was prompted by one aspect of the 
     discussion on the list 
     > about large grammars, which is how a client can figure 
     out in advance 
     > just what a server can and can't do, so it isn't "unpleasantly 
     > surprised" at the instant it issues a method.
     >
     > The current specification walks a fine line between 
     giving flexibility 
     > to server implementers and giving clients a sufficient degree of 
     > control over server behavior. For example we have things 
     like multiple 
     > jump-length units which a server may or may not support, 
     > server-specific default values for confidence-threshold and 
     > speed-vs-accuracy, and a bunch of others.
     >
     > 1) through SDP and SIP OPTIONS the client can discover 
     what resources 
     > the server supports and what media formats it can process.
     > 2) through GET-PARAMS on a particular session with a 
     resource the 
     > client can discover any implementation-specific server 
     default values 
     > for MRCPv2 protocol headers.
     >
     > Here's a small list of candidates. Feel free to comment 
     and/or propose 
     > your own:
     >
     > a) we may want/need a way for the server to determine what audio 
     > formats a client supports for the purposes of returning captured 
     > audio. Right now we don't even have a way for the client 
     to tell the 
     > server what format it wants audio returned in, so we at 
     least have to 
     > remedy that omission.
     >
     > b) we may want a way for a client to learn the current list of 
     > "instantly available" grammars the server has handy and 
     which are in 
     > some way "guaranteed" to persist for a while.
     >
     > c) we may want a form of GET-PARAMS which fetches 
     session-independent 
     > server information. One way to do this is to define a 
     MRCPv2-frag 
     > content type (like we have with sipfrag). That way a SIP 
     OPTIONs to an 
     > MRCPv2 server can return an MRCP-specific body with all that 
     > interesting information about server capabilities.
     >
     > <chair hat>
     > I don't want this to necessary turn into a free-for-all, 
     because we 
     > really do want to reach closure on the spec and get it 
     to last call.
     > My target for finishing my chair review and editing is 
     the end of this 
     > week.