From exim@www1.ietf.org Wed Nov 5 17:14:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26883 for ; Wed, 5 Nov 2003 17:14:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVut-0002Eb-SF for speechsc-archive@odin.ietf.org; Wed, 05 Nov 2003 17:14:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5MEJes008583 for speechsc-archive@odin.ietf.org; Wed, 5 Nov 2003 17:14:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVut-0002EM-Oo for speechsc-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 17:14:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26875 for ; Wed, 5 Nov 2003 17:14:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVur-0004YH-00 for speechsc-web-archive@ietf.org; Wed, 05 Nov 2003 17:14:17 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHVuo-0004YD-00 for speechsc-web-archive@ietf.org; Wed, 05 Nov 2003 17:14:16 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHVun-0005E3-QX for speechsc-web-archive@ietf.org; Wed, 05 Nov 2003 17:14:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVua-0002Aj-R4; Wed, 05 Nov 2003 17:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVth-00029Z-Kh for speechsc@optimus.ietf.org; Wed, 05 Nov 2003 17:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26828 for ; Wed, 5 Nov 2003 17:12:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVtf-0004Wv-00 for speechsc@ietf.org; Wed, 05 Nov 2003 17:13:03 -0500 Received: from [205.150.90.87] (helo=voicegenie.com) by ietf-mx with esmtp (Exim 4.12) id 1AHVtb-0004Wn-00 for speechsc@ietf.org; Wed, 05 Nov 2003 17:12:59 -0500 Received: from voicegenie.com (dilbert.voicegenie.com [205.150.90.110]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id hA5MCRY28708 for ; Wed, 5 Nov 2003 17:12:27 -0500 (EST) Message-ID: <3FA97740.3CCD5D0D@voicegenie.com> Date: Wed, 05 Nov 2003 17:18:40 -0500 From: Alex Lee Reply-To: alee@voicegenie.com Organization: VoiceGenie Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: speechsc@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Speechsc] Question on Proxy, and media redirect. Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From exim@www1.ietf.org Thu Nov 6 08:26:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07897 for ; Thu, 6 Nov 2003 08:26:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk9D-0006M3-F6 for speechsc-archive@odin.ietf.org; Thu, 06 Nov 2003 08:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6DQ3QM024423 for speechsc-archive@odin.ietf.org; Thu, 6 Nov 2003 08:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk9D-0006Lq-9D for speechsc-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 08:26:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07857 for ; Thu, 6 Nov 2003 08:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHk9C-0000wA-00 for speechsc-web-archive@ietf.org; Thu, 06 Nov 2003 08:26:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHk9B-0000w7-00 for speechsc-web-archive@ietf.org; Thu, 06 Nov 2003 08:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk9B-0006Kz-Eu; Thu, 06 Nov 2003 08:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHk3P-0005vV-Ut for speechsc@optimus.ietf.org; Thu, 06 Nov 2003 08:20:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07635 for ; Thu, 6 Nov 2003 08:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHk3O-0000sU-00 for speechsc@ietf.org; Thu, 06 Nov 2003 08:20:02 -0500 Received: from pb-relay1.scansoft.com ([198.71.64.23] helo=smtp-relay1.scansoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AHk3O-0000s2-00 for speechsc@ietf.org; Thu, 06 Nov 2003 08:20:02 -0500 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73] unverified) by smtp-relay1.scansoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Nov 2003 08:19:35 -0500 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Nov 2003 08:19:31 -0500 Message-ID: <9E452E1028D9664E89CA1BBCF166805768EBE0@bn-exch1> From: "Eberman, Brian" To: speechsc@ietf.org Cc: "Eberman, Brian" Subject: RE: [Speechsc] Question on Proxy, and media redirect. Date: Thu, 6 Nov 2003 08:19:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-OriginalArrivalTime: 06 Nov 2003 13:19:35.0945 (UTC) FILETIME=[9FB43F90:01C3A468] Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , 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:alee@voicegenie.com] Sent: Wednesday, November 05, 2003 5:19 PM To: speechsc@ietf.org 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 Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From exim@www1.ietf.org Thu Nov 6 15:07:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26615 for ; Thu, 6 Nov 2003 15:07:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqPH-00078F-L2 for speechsc-archive@odin.ietf.org; Thu, 06 Nov 2003 15:07:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6K73QD027406 for speechsc-archive@odin.ietf.org; Thu, 6 Nov 2003 15:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqPH-00077x-57 for speechsc-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 15:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26560 for ; Thu, 6 Nov 2003 15:06:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHqPD-00072z-00 for speechsc-web-archive@ietf.org; Thu, 06 Nov 2003 15:06:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHqPD-00072w-00 for speechsc-web-archive@ietf.org; Thu, 06 Nov 2003 15:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqPE-000768-Mf; Thu, 06 Nov 2003 15:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqOw-00074T-LC for speechsc@optimus.ietf.org; Thu, 06 Nov 2003 15:06:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26520 for ; Thu, 6 Nov 2003 15:06:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHqOt-00072X-00 for speechsc@ietf.org; Thu, 06 Nov 2003 15:06:39 -0500 Received: from [63.163.229.65] (helo=[208.236.204.65]) by ietf-mx with smtp (Exim 4.12) id 1AHqOs-00072T-00 for speechsc@ietf.org; Thu, 06 Nov 2003 15:06:38 -0500 Received: from namasmtp02.nmss.com by [208.236.204.65] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 6 Nov 2003 15:07:24 -0500 To: speechsc@ietf.org Cc: "Eberman, Brian" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "John Potemri" Date: Thu, 6 Nov 2003 15:06:11 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.12 |February 13, 2003) at 11/06/2003 03:06:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Speechsc] Re: Speechsc digest, Vol 1 #153 - 2 msgs Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Brian, I did wonder when someone would raise "record" on the reflector. I know= many people are talking about it. I would caution to push "record" int= o the recognize package (a.k.a. resource type). Someone may want to offer= record capabilities via MRCP and not have recognition. I would prefer to see record defined as a separate resource. MRCP does allow multiple resource types on the same control channel and share the= same source stream, so you could record while recognizing, too. This ke= eps the two state machines and protocol interface clean. I don't want to open a can of words, but I suppose similar arguments fo= r more granular resource types could be made around: - "speak" supporting both TTS and audio - what if I only supported audio? At least in this case you wouldn't have both resources "activ= e". - "recognize" resources that only do DTMF grammars. But then again, these are "types" within the "resource" and one could a= rgue that you support the functional interface specified by the resource definition, but may not support certain types. This could have been resolved out-of-band via some resource management framework. But record= in recognition is different. I understand that this may not be a speech vendors preferred way to look at things. This does beg the question of MRCP as the protocol for media engine ("m= edia server") functions. You'll note that while not defined, the spec does suggest fax as a type, too. Perhaps someone has already had this dialog= . I have excluded addessing conferencing at this point because I know who w= ill jump all over me. -John P.S. And while we comment against MRCPv2, is it out-of-scope to mention= the effects relative to MRCP(v1) for which people might make parallel suggestions? John Potemri NMS Communications 100 Crossing Blvd Framingham, MA=A0 01702 +1-508-271-1369 john_potemri@nmss.com |---------+----------------------------> | | speechsc-request@| | | ietf.org | | | Sent by: | | | speechsc-admin@ie| | | tf.org | | | | | | | | | 11/06/2003 12:00 | | | PM | | | Please respond to| | | speechsc | | | | |---------+----------------------------> >--------------------------------------------------------------------= ------------------------------------------| | = | | To: speechsc@ietf.org = | | cc: = | | Subject: Speechsc digest, Vol 1 #153 - 2 msgs = | >--------------------------------------------------------------------= ------------------------------------------| Send Speechsc mailing list submissions to speechsc@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/speechsc or, via email, send a message with subject or body 'help' to speechsc-request@ietf.org You can reach the person managing the list at speechsc-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Speechsc digest..." Today's Topics: 1. Question on Proxy, and media redirect. (Alex Lee) 2. RE: Question on Proxy, and media redirect. (Eberman, Brian) ----- Message from Alex Lee on Wed, 05 Nov 2003 17:18:40 -0500 ----- =20 To: speechsc@ietf.org =20 =20 Subject: [Speechsc] Question on Proxy, and media=20 redirect. =20 =20 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 multipl= e 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 thi= s 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 possibilit= y 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 o= f 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 th= e 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 ---------> | | | | | | | | | =3D=3D=3D=3D=3D=3D=3D TCP connect() =3D=3D=3D=3D=3D=3D> | = | | | | | =3D=3D=3D=3D MRCP DEFINE-GRAMMAR =3D=3D=3D> | = | | | | | <=3D=3D=3D MRCP DEFINE-GRAMMAR =3D=3D=3D=3D | = | | | | | =3D=3D=3D=3D=3D=3D MRCP SET-PARAM =3D=3D=3D=3D=3D=3D> | = | | | | | <=3D=3D=3D=3D=3D MRCP SET-PARAM =3D=3D=3D=3D=3D=3D=3D | = | | | | | <=3D=3D=3D More MRCP SET-PARAM =3D=3D=3D> | = | | and DEFINE-GRAMMAR | | | | | | =3D=3D=3D=3D MRCP RECOGNIZE (1) =3D=3D=3D=3D> | = | | | | | | -------- SIP INVITE --------> | | | | | | <------- SIP INVITE --------- | | | Port# for both control | | | and media | | | | | | ---------- SIP ACK ---------> | | | | | <------- SIP INVITE --------- | | | New Port# of media | | | | | | -------- SIP INVITE --------> | | | | | | <--------- SIP ACK ---------- | | | | =3D=3D=3D=3D=3D=3D=3D TCP connect(= ) =3D=3D=3D=3D=3D=3D> | | | | | | <=3D=3D=3D=3D All MRCP SET-PARAM =3D= =3D=3D> | | | and DEFINE-GRAMMAR | | | sent by client | | | | | | =3D=3D=3D=3D=3D=3D MRCP RECOGNIZE = =3D=3D=3D=3D=3D=3D> | | | | | | <=3D=3D=3D=3D=3D MRCP RECOGNIZE =3D= =3D=3D=3D=3D=3D=3D |=00 | | | | <=3D=3D=3D=3D MRCP RECOGNIZE (2) =3D=3D=3D=3D | = | | | | | | <=3D=3D=3D MRCP START-OF-SPEECH =3D= =3D=3D |=00 | | | | <=3D=3D=3D MRCP START-OF-SPEECH =3D=3D=3D | = | | | | | | < MRCP RECOGNITION-COMPLETE =3D |=00= | | | | < MRCP RECOGNITION-COMPLETE =3D | | | | | | | | Is there any possibility to explicitly include this mechanism, or a= n 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... ----- Message from "Eberman, Brian" on Thu= , 6 Nov 2003 08:19:29 -0500 ----- =20 To: speechsc@ietf.org =20 =20 cc: "Eberman, Brian" =20 =20 =20 Subject: RE: [Speechsc] Question on Proxy, and =20 media redirect. =20 =20 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 stre= am to get a cleaner specification. Proxy scaling should really be a key issu= es for MRCPv2 and I thought it was in the base requirements. This seems li= ke 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 u= nder MRCP to implement the record function of VoiceXML without having the VoiceXML implementation box routing the audio. I think we need to resol= ve 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 eve= nt. 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:alee@voicegenie.com] Sent: Wednesday, November 05, 2003 5:19 PM To: speechsc@ietf.org 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 o= n the same call. When it is desired that a different server is to be used for differ= ent recognition sessions, there are two possibilities for how this may be d= one. First, if the client is very smart, then it can be aware of many differ= ent servers it has access to, and setup independent sessions to these serve= rs based on what it needs. The other possibility is to build a client tha= t 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 Pr= oxy should not proxy the audio data, but rather it should only proxy the SI= P and MRCP control messages. In order to do that, however, the spec itself must allow for some k= ind of media re-routing (similar to a SIP re-invite) initiated from the ser= ver 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 chan= ge some properties of the media channel. In the use case with the proxy switching back-end servers, the client would initiate a session with th= e proxy. Then, based on the parameters of the MRCP RECOGNIZE command (e.= g. which grammars to use for recognition, which languages to use, etc.), t= he proxy would choose the back-end server to use for the recognition. Aft= er the real back-end server has been chosen, the proxy would go back to th= e 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 situati= on. The single arrows are messages sent via the SIP channels, while the dou= ble arrows are messages sent via the control channels. Client Proxy Server= | | | | -------- SIP INVITE --------> | | | | | | <------- SIP INVITE --------- | | | Port# for both control | | | and media | | | | | | ---------- SIP ACK ---------> | | | | | | | | | =3D=3D=3D=3D=3D=3D=3D TCP connect() =3D=3D=3D=3D=3D=3D> | = | | | | | =3D=3D=3D=3D MRCP DEFINE-GRAMMAR =3D=3D=3D> | = | | | | | <=3D=3D=3D MRCP DEFINE-GRAMMAR =3D=3D=3D=3D | = | | | | | =3D=3D=3D=3D=3D=3D MRCP SET-PARAM =3D=3D=3D=3D=3D=3D> | = | | | | | <=3D=3D=3D=3D=3D MRCP SET-PARAM =3D=3D=3D=3D=3D=3D=3D | = | | | | | <=3D=3D=3D More MRCP SET-PARAM =3D=3D=3D> | = | | and DEFINE-GRAMMAR | | | | | | =3D=3D=3D=3D MRCP RECOGNIZE (1) =3D=3D=3D=3D> | = | | | | | | -------- SIP INVITE --------> | | | | | | <------- SIP INVITE --------- | | | Port# for both control | | | and media | | | | | | ---------- SIP ACK ---------> | | | | | <------- SIP INVITE --------- | | | New Port# of media | | | | | | -------- SIP INVITE --------> | | | | | | <--------- SIP ACK ---------- | | | | =3D=3D=3D=3D=3D=3D=3D TCP connect(= ) =3D=3D=3D=3D=3D=3D> | | | | | | <=3D=3D=3D=3D All MRCP SET-PARAM =3D= =3D=3D> | | | and DEFINE-GRAMMAR | | | sent by client | | | | | | =3D=3D=3D=3D=3D=3D MRCP RECOGNIZE = =3D=3D=3D=3D=3D=3D> | | | | | | <=3D=3D=3D=3D=3D MRCP RECOGNIZE =3D= =3D=3D=3D=3D=3D=3D |=00 | | | | <=3D=3D=3D=3D MRCP RECOGNIZE (2) =3D=3D=3D=3D | = | | | | | | <=3D=3D=3D MRCP START-OF-SPEECH =3D= =3D=3D |=00 | | | | <=3D=3D=3D MRCP START-OF-SPEECH =3D=3D=3D | = | | | | | | < MRCP RECOGNITION-COMPLETE =3D |=00= | | | | < MRCP RECOGNITION-COMPLETE =3D | | | | | | | | Is there any possibility to explicitly include this mechanism, or a= n alternative, in the MRCPv2 spec that would allow for the usage of a pro= xy where it needs change the back-end server media properties in the middl= e of the session? I have seen that "RE-DIRECT" has been mentioned in the MR= CPv2 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 Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc = _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From exim@www1.ietf.org Thu Nov 6 16:09:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00982 for ; Thu, 6 Nov 2003 16:09:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrNI-00048h-BJ for speechsc-archive@odin.ietf.org; Thu, 06 Nov 2003 16:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6L9419015907 for speechsc-archive@odin.ietf.org; Thu, 6 Nov 2003 16:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrNI-00048U-6b for speechsc-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 16:09:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00970 for ; Thu, 6 Nov 2003 16:08:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrNG-0000Wi-00 for speechsc-web-archive@ietf.org; Thu, 06 Nov 2003 16:09:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHrNG-0000Wf-00 for speechsc-web-archive@ietf.org; Thu, 06 Nov 2003 16:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrNF-00047k-7A; Thu, 06 Nov 2003 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrMQ-00043n-7Y for speechsc@optimus.ietf.org; Thu, 06 Nov 2003 16:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00952 for ; Thu, 6 Nov 2003 16:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrMO-0000WJ-00 for speechsc@ietf.org; Thu, 06 Nov 2003 16:08:08 -0500 Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHrMN-0000WG-00 for speechsc@ietf.org; Thu, 06 Nov 2003 16:08:07 -0500 Received: from cisco.com ([128.107.139.4]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Nov 2003 13:06:20 -0800 Message-ID: <3FAAB817.7090209@cisco.com> Date: Thu, 06 Nov 2003 13:07:35 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: alee@voicegenie.com CC: speechsc@ietf.org Subject: Re: [Speechsc] Question on Proxy, and media redirect. References: <3FA97740.3CCD5D0D@voicegenie.com> In-Reply-To: <3FA97740.3CCD5D0D@voicegenie.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2003 21:06:20.0984 (UTC) FILETIME=[D4021380:01C3A4A9] Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: >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 backed 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 backed server to use for the >recognition. After the real backed 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 >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From exim@www1.ietf.org Thu Nov 6 16:37:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02387 for ; Thu, 6 Nov 2003 16:37:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHroO-0005Gc-SD for speechsc-archive@odin.ietf.org; Thu, 06 Nov 2003 16:37:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Lb4j7020232 for speechsc-archive@odin.ietf.org; Thu, 6 Nov 2003 16:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHroO-0005GF-Cl for speechsc-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 16:37:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02368 for ; Thu, 6 Nov 2003 16:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHroK-0000zk-00 for speechsc-web-archive@ietf.org; Thu, 06 Nov 2003 16:37:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHroK-0000zg-00 for speechsc-web-archive@ietf.org; Thu, 06 Nov 2003 16:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHroK-0005EW-Gz; Thu, 06 Nov 2003 16:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrny-0005E2-Uv for speechsc@optimus.ietf.org; Thu, 06 Nov 2003 16:36:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02310 for ; Thu, 6 Nov 2003 16:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrns-0000zB-00 for speechsc@ietf.org; Thu, 06 Nov 2003 16:36:32 -0500 Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHrnr-0000yP-00 for speechsc@ietf.org; Thu, 06 Nov 2003 16:36:31 -0500 Received: from cisco.com ([128.107.139.4]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Nov 2003 13:34:45 -0800 Message-ID: <3FAABEBF.4090302@cisco.com> Date: Thu, 06 Nov 2003 13:35:59 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Potemri CC: speechsc@ietf.org, "Eberman, Brian" Subject: Re: [Speechsc] Re: Speechsc digest, Vol 1 #153 - 2 msgs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2003 21:34:45.0250 (UTC) FILETIME=[CBD46E20:01C3A4AD] Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi John, I agree with all your comments. These are things that I was planning to propose too, as additions to the specification, but haven't been able to get to it due to some other priority work items. Like you, I am also interested in seeing the Record as a separate resource for purposes very similar to the ones stated by you and Brian. But I still see a need for recording capabilities associated with the recognition resources to be able to record and manage utterances. I still have no problem looking at the Recording engine as a separately controlable standalone resource, as long as for simplicity sake, we allow the Recognize operation to trigger the start and stop of the recording engine if needed. Another place I suspect this Recording or the Record utterances operation is going to be usefull, is for Speaker verification. This requires the user to record/buffer user utterances spoken separately or during a recognize operation and then apply the recorded/buffered audio to the Speaker Verification Engine. I also agree with john that there is need to be able to play only audio from a synthesizer. The I was hoping we could achieve this, is by using the smae messages with different limitations based on the specific resource profiles. For Example: with the Synthesizer we could have 3 different profiles. Audio-Player, poor-mans TTS(concatenating audio bits), advanced TTS. The major difference between the 3 is the synthesizer data sent in the SPEAK method. 1. Audio player may only support , the SSML