Subject: RE: [Speechsc] Question on Proxy, and media redirect.

From: "Eberman, Brian" <[email-masked]>
Date: Thu, 6 Nov 2003 08:19:29 -0500

I really think Alex has brought up an important point here.  We need to be
able to cleanly separate the RTP/ audio streaming from the control stream to
get a cleaner specification.  Proxy scaling should really be a key issues
for MRCPv2 and I thought it was in the base requirements. This seems like a
significant whole.

I've seen two other places in implementations of VoiceXML browsers that need
to be clarified for v2:

1) There isn't any way to cleanly implement a pure recording function under
MRCP to implement the record function of VoiceXML without having the
VoiceXML implementation box routing the audio. I think we need to resolve
this issue.  VoiceXML recording can be terminated by speech recognition so
it is actually more like a recognition then a recording.

2) The SPEECH-MARKER event for TTS doesn't indicate the time of the event.
So if a system is distributing the RTP stream and the TTS stream and
potential mixing audio using the MARKER it doesn't know the time in the RTP
stream when the audio mark was hit.

The stream control semantics seem to need a little work here.
-Brian

-----Original Message-----
From: Alex Lee [mailto:[email-masked]] 
Sent: Wednesday, November 05, 2003 5:19 PM
To: [email-masked]
Subject: [Speechsc] Question on Proxy, and media redirect.

Hi,

    We have looked at the way the sessions are set up with MRCPv2, and find
that it isn't well-defined for some proxy applications.  The situation we're
thinking about is that there's a proxy fronting multiple ASR servers at the
back end, where each ASR server may have different capabilities (e.g. Server
1 supports English, Server 2 supports French).  Sometimes, it may be
desirable to use different servers for different recognition sessions on the
same call.

    When it is desired that a different server is to be used for different
recognition sessions, there are two possibilities for how this may be done.
First, if the client is very smart, then it can be aware of many different
servers it has access to, and setup independent sessions to these servers
based on what it needs.  The other possibility is to build a client that
isn't very smart, but it will access an MRCP proxy that is capable of
routing its recognition requests, based on the parameters of each
recognition session.  For efficient implementation of the Proxy, the Proxy
should not proxy the audio data, but rather it should only proxy the SIP and
MRCP control messages.

    In order to do that, however, the spec itself must allow for some kind
of media re-routing (similar to a SIP re-invite) initiated from the server
when a "RECOGNIZE" method is called from the MRCP client.  Right now, MRCPv2
assumes that the same media channel will be used within one session.

    One way to work around this is to allow for a SIP INVITE to be sent from
the Server to the Client in the middle of a "recognize" method, to change
some properties of the media channel.  In the use case with the proxy
switching back-end servers, the client would initiate a session with the
proxy.  Then, based on the parameters of the MRCP RECOGNIZE command (e.g.
which grammars to use for recognition, which languages to use, etc.), the
proxy would choose the back-end server to use for the recognition.  After
the real back-end server has been chosen, the proxy would go back to the
client to modify the media properties, so that the client can send the audio
directly to the real server.

    The following diagram illustrates the interaction of such a situation.
The single arrows are messages sent via the SIP channels, while the double
arrows are messages sent via the control channels.

Client                           Proxy                           Server
   |                               |                               |
   | -------- SIP INVITE --------> |                               |
   |                               |                               |
   | <------- SIP INVITE --------- |                               |
   |     Port# for both control    |                               |
   |            and media          |                               |
   |                               |                               |
   | ---------- SIP ACK ---------> |                               |
   |                               |                               |
   |                               |                               |
   | ======= TCP connect() ======> |                               |
   |                               |                               |
   | ==== MRCP DEFINE-GRAMMAR ===> |                               |
   |                               |                               |
   | <=== MRCP DEFINE-GRAMMAR ==== |                               |
   |                               |                               |
   | ====== MRCP SET-PARAM ======> |                               |
   |                               |                               |
   | <===== MRCP SET-PARAM ======= |                               |
   |                               |                               |
   | <=== More MRCP SET-PARAM ===> |                               |
   |       and DEFINE-GRAMMAR      |                               |
   |                               |                               |
   | ==== MRCP RECOGNIZE (1) ====> |                               |
   |                               |                               |
   |                               | -------- SIP INVITE --------> |
   |                               |                               |
   |                               | <------- SIP INVITE --------- |
   |                               |     Port# for both control    |
   |                               |            and media          |
   |                               |                               |
   |                               | ---------- SIP ACK ---------> |
   |                               |                               |
   | <------- SIP INVITE --------- |                               |
   |      New Port# of media       |                               |
   |                               |                               |
   | -------- SIP INVITE --------> |                               |
   |                               |                               |
   | <--------- SIP ACK ---------- |                               |
   |                               | ======= TCP connect() ======> |
   |                               |                               |
   |                               | <==== All MRCP SET-PARAM ===> |
   |                               |       and DEFINE-GRAMMAR      |
   |                               |        sent by client         |
   |                               |                               |
   |                               | ====== MRCP RECOGNIZE ======> |
   |                               |                               |
   |                               | <===== MRCP RECOGNIZE ======= |
   |                               |                               |
   | <==== MRCP RECOGNIZE (2) ==== |                               |
   |                               |                               |
   |                               | <=== MRCP START-OF-SPEECH === |
   |                               |                               |
   | <=== MRCP START-OF-SPEECH === |                               |
   |                               |                               |
   |                               | < MRCP RECOGNITION-COMPLETE = |
   |                               |                               |
   | < MRCP RECOGNITION-COMPLETE = |                               |
   |                               |                               |
   |                               |                               |

    Is there any possibility to explicitly include this mechanism, or an
alternative, in the MRCPv2 spec that would allow for the usage of a proxy
where it needs change the back-end server media properties in the middle of
the session?  I have seen that "RE-DIRECT" has been mentioned in the MRCPv2
spec in section 8.5.3, but there hasn't been any example, explicit
description, or rules on how this is to be done.  Any extensions or
clarification on this topic is much appreciated.  Thanks.

Alex...

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

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