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

From: Alex Lee <[email-masked]>
Date: Wed, 05 Nov 2003 17:18:40 -0500

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

---

From: Sarvi Shanmugham <[email-masked]>
Date: Thu, 06 Nov 2003 13:07:35 -0800

Hi Alex,
    I agree with you very much that the redirect /proxy capabilities of 
MRCPv2 need to upgraded.
The current MRCPv2 specification is derived from the the current MRCPv1 
spec which is RTSP based, and hence was limited in its Proxy/Redirect 
capabilities.
   With MRCPv2, it fits in the SIP framework. The SIP framework is 
expected to setup  media-lines and control-lines. And I agree with your 
call flow too. I was hoping we could achieve re-directs in a similar 
fashion too.

     I agree we should add such call flows  in the spec to explain how 
this achieved. It hasn't been addressed in the current spec yet.

Sarvi

Alex Lee wrote:

>find that it isn't well defined for some proxy applications.  The
>proxy switching backed servers, the client would initiate a session
>use, etc.), the proxy would choose the backed server to use for the
>recognition.  After the real backed server has been chosen, the proxy

---

From: Alex Lee <[email-masked]>
Date: Thu, 06 Nov 2003 16:51:42 -0500

Thanks for your response Sarvi.  Do you think the client should be *required*
to support this kind of "redirect" instruction from the server, or do you
think this may be optional?  Thanks.

Alex...

---

From: Sarvi Shanmugham <[email-masked]>
Date: Thu, 06 Nov 2003 14:14:29 -0800

I would think the client SHOULD be required to respond to SIP 
re-INVITEs.  My understanding was that as SIP UA the client would 
already suipport re-INVITES. If not, we make it SHOULD level requirement 
for the SIP UA acting as the MRCPv2 client to respond appropriately to 
re-INVITES.

As of now, the spec does not say anything about when audio transmition 
should start  or stop on a media pipe, for a Recognition resource. I 
suppose the best time to have the client start media transmition to the 
client would be after it gets MRCPv2 200 OK for the recognize command. 
The media transmition from the client can stop after the 
RECOGNITION-COMPLETE event is received by the client.

This would allow the proxy to delay sending back the MRCPv2 200 OK until 
the media pipe has been redirected and the RECOGNIZE command has been 
received from the back end server.

Sarvi