[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
I not too thrilled with the implication of leaking more MRCP Application
parameters into SDP, which could be possibly considered outside the scope
of resource session establishment,. This could potentially end up
complicating interoperability scenarios.
Thanks,
Brett Gavagni
WebSphere Voice Server Development
http://www-306.ibm.com/software/pervasive/voice_server/
gavagni at us.ibm.com
"Eric Burger" <eburger at brooktrout.com>
10/18/2005 10:48 PM
To
"Shanmugham, Saravanan" <sarvi at cisco.com>, Brett Gavagni/West Palm
Beach/IBM at IBMUS
cc
"IETF SPEECHSC \(E-mail\)" <speechsc at ietf.org>
Subject
RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:
ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
Fine with me, so long as server can reject and client can handle situation
where I ask for only NLSML in SIP negotiation and then I ask for EMMA and
the server doesn't handle it.
-----Original Message-----
From: Shanmugham, Saravanan [mailto:sarvi at cisco.com]
Sent: Tue Oct 18 20:57:20 2005
To: Eric Burger; Brett Gavagni
Cc: IETF SPEECHSC (E-mail)
Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:
ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
I suggest that we do both.
The SIP Alow/Accept header during MRCP session setup for server
discovery and routing.
We then add support for the Accept header in MRCPv2 messages. I suspect
this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS.
And can be used in the case where the client or the server can do both.
What do you think.
Sarvi
-----Original Message-----
From: Eric Burger [mailto:eburger at brooktrout.com]
Sent: Monday, October 17, 2005 1:52 PM
To: Shanmugham, Saravanan; Brett Gavagni
Cc: IETF SPEECHSC (E-mail)
Subject: Question on negotiating EMMA (was RE: [Speechsc]
EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
My logic, which may be flawed, is that we want to be able
to achieve these objectives.
o Ensure the trivial ability to negotiate other result
formats, such as EMMA.
o Ensure the server knows what format the client wants.
o Ensure the client knows the server supports the format
the client wants, before it is "too late".
I would offer that using SET-PARAMS is "too late", in that
the client and server has already spent the effort to
establish the RTP sessions.
It would be a pity to then tear it all down when the
client finds out the server does not support the format of choice.
One can negotiating the format at session establishment
time with SDP
(a=resultformat:application/emma-xml) or with SIP
(Allow/Accept). I would offer that it is easier to
implement, and makes MRCPv2 (SIP) proxies easier if we do
the negotiation at the SIP level. For example, if a
client wants results in EMMA, a MRCPv2 proxy can route the
request to a server that supports EMMA by inspecting the
SIP headers, rather than having to dive in to the SDP.
While the preceding paragraph indicates my preference for
using the SIP negotiation mechanism, there still is the
case where both the client and server support NLSML and EMMA.
++++ THE QUESTION ++++
Is there a realistic use case where the client, in any
given session, would want to use multiple result formats?
That is, something like, "RECOGNIZE this and give me the
result in EMMA" and then later issue something like,
"RECOGNIZE that and give me the result in NLSML"?
If so, then we would *also* need a per-recognition /
SET-PARAMS header for the result type.
-----Original Message-----
From: speechsc-bounces at ietf.org
[mailto:speechsc-bounces at ietf.org] On Behalf Of
Shanmugham, Saravanan
Sent: Wednesday, September 28, 2005 2:36 PM
To: Brett Gavagni; Jerry Carter
Cc: IETF SPEECHSC (E-mail); speechsc-bounces at ietf.org; Baggia Paolo
Subject: RE: [Speechsc] EMMA:
ExtensibleMultiModalAnnotation markuplanguagesupport?
Would something like the HTTP "Accept" header address
these and other similar concerns.
The RECOGNIZE request can then carry this header in it to
specify an alternative to NLSML.
Sarvi
-----Original Message-----
From: speechsc-bounces at ietf.org
[mailto:speechsc-bounces at ietf.org] On Behalf Of Brett Gavagni
Sent: Saturday, September 24, 2005 7:51 AM
To: Jerry Carter
Cc: IETF SPEECHSC (E-mail);
speechsc-bounces at ietf.org; Baggia Paolo
Subject: Re: [Speechsc] EMMA: Extensible
MultiModalAnnotation markuplanguagesupport?
Hi,
I agree that the ability for a client to request the
format of the recognizer result data content would be useful.
I would prefer to see this function defined in a
consistent manner with the current draft specification; by
a client request to enable a session parameter via a
header (ie. "Result-Data-Type") in a SET-PARAMS or
RECOGNIZE request, rather than an attribute used for
RECOGNIZER session negotiation/update. The server should
then respond with an accept or reject response as it does
today for other client requested parameter values.
Currently, the draft specification doesn't expose the MRCP
resource configurable parameters in the SDP.
I don't think that enabling platform-specific formats
facilitates the adoption of a standard specification for
speech resources. I believe that the specification should
continue to address the required supported formats and
require new draft iterations including the updated
specifications. The updated draft iterations would
continue to assist with potential client/server
interoperability issues.
Thanks,
Brett Gavagni
WebSphere Voice Server Development
http://www-306.ibm.com/software/pervasive/voice_server/
gavagni at us.ibm.com
Jerry Carter <jerry at jerrycarter.org>
Sent by: speechsc-bounces at ietf.org
09/23/2005 11:42 PM
To
Baggia Paolo <Paolo.Baggia at LOQUENDO.COM> cc "IETF SPEECHSC
\(E-mail\)" <speechsc at ietf.org> Subject
Re: [Speechsc] EMMA: Extensible MultiModal Annotation
markuplanguagesupport?
I agree that minor changes made today will prevent
the need for an
amended document in the very near future. Providing
for content
negotiation solves both the EMMA issue and allows for
future or
platform-specific return formats without requiring that the
specification be iterated.
Of the two suggestions, I prefer the SDP extension as the
return format
is analogous to other SIP media type negotiations.
On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote:
> the last answers and discussions in this thread
seems to confirm
> that the direction of MRCPv2 is to allow the use of
EMMA when
> it will become a W3C Recommendation. Some text
should be added
> in the future release to say that.
> This is fine from us point of view, but a mechanism
for asking
> a different result format is not present in the
current draft.
>
> We think to add that mechanism will allow a smooth
transition
> from the current situation: always result in
"application/nlsml+xml",
> to a future one with results in EMMA.
>
> Would it be possible to consider this "negotiation"
of the output
> result in the next draft?
>
> There are different options to implement it:
> a) to extend SDP to leave taht outside of MRCPv2
core protocol
> E.g.
> a=recogResultFormat:application/nlsml+xml
> if present it sets the recognition result for a whole MRCP
> session.
>
> b) to add a new recognizer header to set the result format
> for that specific recognition turn.
>
> What do you think?
>
> We are aware the draft is near to be closed, but we
think this
> will help the passage from NLSML to EMMA.
>
> Regards,
> Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo)
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc