From mailnull@www1.ietf.org Tue Mar 4 12:36:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02942 for ; Tue, 4 Mar 2003 12:36:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Hkch25564 for speechsc-archive@odin.ietf.org; Tue, 4 Mar 2003 12:46:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Hkcp25561 for ; Tue, 4 Mar 2003 12:46:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02899 for ; Tue, 4 Mar 2003 12:35:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HkXp25548; Tue, 4 Mar 2003 12:46:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Hk1p25479 for ; Tue, 4 Mar 2003 12:46:01 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02871 for ; Tue, 4 Mar 2003 12:34:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 4 Mar 2003 12:39:09 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24885D@zoe.office.snowshore.com> Thread-Topic: FW: IETF 56 Presentation Submissions Thread-Index: AcLiboc85UZeBqqtRfybrE+idUxHGA== From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24Hk1p25480 Subject: [Speechsc] FW: IETF 56 Presentation Submissions 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: 8bit Content-Transfer-Encoding: 8bit I can get your presentations posted prior to our meeting in San Francisco. As a reminder, we are meeting from 2:15pm - 3:15pm on Tuesday, March 18. Cons: You have to get your presentation written before you present it :-) Pros: If (when) the projector dies, everyone has access to your presentation without lots of "I'll post it here" time wasted. Also, people following on Jabber can follow along with the presentation without clogging up the mail list. N.B.: No tutorials; only problem resolution and discussion. Remember, we have only 1 hour! -----Original Message----- From: IETF Proceedings Administrator [mailto:minutes@ietf.org] Sent: Monday, March 03, 2003 2:53 PM To: wgchairs@ietf.org; bofchairs@ietf.org; Steve Coya Subject: IETF 56 Presentation Submissions This message is for all group chairs who will be meeting in San Francisco. Presentations may be submitted for online viewing at IETF 56 along with any interim sessions since Atlanta (55). These materials may be sent in until Thursday, March 14th @ 5:00pm. After this cutoff date materials may be submitted onsite at the Registration Desk, however please allow at least 1 day for new posts to be listed online. Please see www.ietf.org/proceedings/03mar/ for guidelines and the group submission form. Thank you, IETF Secretariat _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Mar 13 16:17:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19464 for ; Thu, 13 Mar 2003 16:17:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DLWLd00324 for speechsc-archive@odin.ietf.org; Thu, 13 Mar 2003 16:32:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLWLO00321 for ; Thu, 13 Mar 2003 16:32:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19431 for ; Thu, 13 Mar 2003 16:17:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLWFO32753; Thu, 13 Mar 2003 16:32:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLRKO32505 for ; Thu, 13 Mar 2003 16:27:20 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19326 for ; Thu, 13 Mar 2003 16:12:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 13 Mar 2003 16:16:33 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2488BE@zoe.office.snowshore.com> Thread-Topic: Text Conferencing for the 56th IETF meeting in San Francisco Thread-Index: AcLoBVabSuzp8UnOQH2PWzjV/PwZAgBnhiXg From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" , "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DLRKO32506 Subject: [Speechsc] FW: Text Conferencing for the 56th IETF meeting in San Francisco 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: 8bit Content-Transfer-Encoding: 8bit -----Original Message----- From: Marshall Rose [mailto:mrose+mtr.ietf@dbc.mtview.ca.us] Sent: Tuesday, March 11, 2003 1:59 PM Subject: Text Conferencing for the 56th IETF meeting in San Francisco Remote Access for the 56th IETF meeting in San Francisco: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 56th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: plenary Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ NOTE: the logging facility will not be active until later this week... ####### _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Mar 17 19:03:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09072 for ; Mon, 17 Mar 2003 19:03:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I0KH817473 for speechsc-archive@odin.ietf.org; Mon, 17 Mar 2003 19:20:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I0KHO17470 for ; Mon, 17 Mar 2003 19:20:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09062 for ; Mon, 17 Mar 2003 19:03:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I0KBO17459; Mon, 17 Mar 2003 19:20:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I0JWO17395 for ; Mon, 17 Mar 2003 19:19:32 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09036; Mon, 17 Mar 2003 19:02:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 17 Mar 2003 19:06:49 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24890C@zoe.office.snowshore.com> Thread-Topic: Agenda for Speechsc Thread-Index: AcLpy2zV2syvcuMsT4SYVw7mGHx0swDDAyaw From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2I0JWO17396 Subject: [Speechsc] Agenda for Speechsc 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: 8bit Content-Transfer-Encoding: 8bit TUESDAY, March 18, 2003 1415-1515 Afternoon Sessions II Continental 7 TSV speechsc Speech Services Control WG Note Well and Agenda Bashing 5 min Requirements Status 5 min Protocol Analysis Status 20 min Document Assignments 10 min _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Mar 18 03:17:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04001 for ; Tue, 18 Mar 2003 03:17:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I8YCp28196 for speechsc-archive@odin.ietf.org; Tue, 18 Mar 2003 03:34:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I8YBO28193 for ; Tue, 18 Mar 2003 03:34:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03998 for ; Tue, 18 Mar 2003 03:16:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I8Y7O28182; Tue, 18 Mar 2003 03:34:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I8X1O28154 for ; Tue, 18 Mar 2003 03:33:01 -0500 Received: from mallaury.noc.nerim.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03967 for ; Tue, 18 Mar 2003 03:15:40 -0500 (EST) Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 69B3062E19; Tue, 18 Mar 2003 09:17:53 +0100 (CET) Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id DB5523B6CA; Tue, 18 Mar 2003 03:15:32 -0500 (EST) Reply-To: From: "Brian Wyld" To: "'Eric Burger'" , "'IETF SPEECHSC (E-mail)'" Subject: RE: [Speechsc] Agenda for Speechsc Date: Tue, 18 Mar 2003 09:14:44 +0100 Message-ID: <048801c2ed26$6f74c920$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D24890C@zoe.office.snowshore.com> Content-Transfer-Encoding: 8bit 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: 8bit Content-Transfer-Encoding: 8bit Hi Eric, Although I cannot be there at the IETF meeting (sob), I have come across a requirement for speechsc that I am not sure is covered in the requirements doc..... (and yes, I know its late to throw in new requirements.....sorry...) The issue is "legal/commercial" rather than technical, but nontheless real :-< Problem ------- Basically, the issue is that several ASR motor vendors require to be able to identify the "call context" for the recognise requests, as they either require all recognise requests for the same call to use exclusively the same "port" (==RTSP/RTP session when using MRCP) or have discount levels depending on the number of requests associated to the same call, or both(!). MRCP is lacking in this department, as it has no clear mapping between a call and an MRCP request. One might assume a 1:1 mapping between the RTSP SETUP/TEARDOWN and call start/end, but in fact : - some mrcp clients do a SETUP/TEARDOWN per MRCP transaction - some mrcp clients do a SETUP at the platform bringup and TEARDOWN at shutdown (possible with clients that can re-route the RTP stream dynamically to different trunks for instance) Although one could just tighten this up by stating 'the RTSP session start/end MUST corrospond to the call start/end, and all MRCP requests relating to the same call MUST use the same RTSP session', I think this is far too restrictive, as there may be significant performance benefits to keeping the RTSP session open for platform lifetime, as well as other "provisioning/monitoring" benefits (if the platform provisions its RTP media channels at startup, and can monitor their state, it can be sure of the exact level of available resources at all times - important for telephony systems) In the case of MRCP therefore, I would suggest we need a new pair of MRCP level messages: CALL_CONTEXT_BEGIN - signal start of a "call" - defines a "callId", unique for the RTSP session on which it is sent CALL_CONTEXT_END - signal end of the "call" for this RTSP session plus to add the callId in a suitable header to the MRCP RECOGNISE and SPEAK messages eg CallId : Server vendors would then be free to reject resource requests on the same RTSP/RTP channel that had overlapping callIds if they had a legal/commercial need, or just ignore these new messages/header if they do not (this would anyway be the default behaviour for an existing MRCP implementation I would hope - be liberal in what you accept eh?) I don't know if you could throw this into the discussion, or maybe its already covered in the requirements doc and I'm just not reading it right..... Anyway, enjoy! Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Eric Burger > Envoyé : Tuesday, March 18, 2003 01:07 > À : IETF SPEECHSC (E-mail) > Cc : agenda@ietf.org > Objet : [Speechsc] Agenda for Speechsc > > > TUESDAY, March 18, 2003 > 1415-1515 Afternoon Sessions II > Continental 7 TSV speechsc Speech Services Control WG > > > Note Well and Agenda Bashing 5 min > Requirements Status 5 min > Protocol Analysis Status 20 min > Document Assignments 10 min > _______________________________________________ > 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 mailnull@www1.ietf.org Sat Mar 22 00:12:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07650 for ; Sat, 22 Mar 2003 00:12:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2M5VKU05039 for speechsc-archive@odin.ietf.org; Sat, 22 Mar 2003 00:31:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M5VKO05036 for ; Sat, 22 Mar 2003 00:31:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07646 for ; Sat, 22 Mar 2003 00:12:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M5VCO05028; Sat, 22 Mar 2003 00:31:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M5UsO05000 for ; Sat, 22 Mar 2003 00:30:54 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07643 for ; Sat, 22 Mar 2003 00:11:41 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2M5DnmU008820; Fri, 21 Mar 2003 21:13:49 -0800 (PST) Received: from cisco.com (sjc-vpn1-524.cisco.com [10.21.98.12]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEY12276; Fri, 21 Mar 2003 21:10:30 -0800 (PST) Message-ID: <3E7BF044.8000405@cisco.com> Date: Fri, 21 Mar 2003 21:10:28 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: brian.wyld@eloquant.com CC: "'Eric Burger'" , "'IETF SPEECHSC (E-mail)'" Subject: Re: [Speechsc] Agenda for Speechsc References: <048801c2ed26$6f74c920$8300a8c0@hq.eloquant.com> Content-Type: multipart/alternative; boundary="------------040402040402030508010505" 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: , --------------040402040402030508010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I am not sure if this is what you are looking for. But MRCP has 2 mechanisms aimed towards this problem. 1. There is a channel-Reset header field that can be sent. This allows the client to tell the recognizer to drop the line quality and other voice quality information it has learned for the current voice session and resets this information. This was placed for the purpose of using a single open MRCP session for more than one call one after the other. 2. When you close an MRCP recognizer session, the recognizer could return a Context-Block of data (treated as an opaque block of data) back to the client. The client is required to send pass that block of opaque data to the next server in the SETUP message(if the new session is a continuation of the call). Does this cover your needs. If so, then the requirement is already covered since the SpeechSC refers to MRCP as the model for requirements. Sarvi Brian Wyld wrote: >Hi Eric, > >Although I cannot be there at the IETF meeting (sob), I have come across a >requirement for speechsc that I am not sure is covered in the requirements >doc..... (and yes, I know its late to throw in new >requirements.....sorry...) > >The issue is "legal/commercial" rather than technical, but nontheless real >:-< > >Problem >------- >Basically, the issue is that several ASR motor vendors require to be able to >identify the "call context" for the recognise requests, as they either >require all recognise requests for the same call to use exclusively the same >"port" (==RTSP/RTP session when using MRCP) or have discount levels >depending on the number of requests associated to the same call, or both(!). > >MRCP is lacking in this department, as it has no clear mapping between a >call and an MRCP request. One might assume a 1:1 mapping between the RTSP >SETUP/TEARDOWN and call start/end, but in fact : > - some mrcp clients do a SETUP/TEARDOWN per MRCP transaction > - some mrcp clients do a SETUP at the platform bringup and TEARDOWN at >shutdown (possible with clients that can re-route the RTP stream dynamically >to different trunks for instance) > >Although one could just tighten this up by stating 'the RTSP session >start/end MUST corrospond to the call start/end, and all MRCP requests >relating to the same call MUST use the same RTSP session', I think this is >far too restrictive, as there may be significant performance benefits to >keeping the RTSP session open for platform lifetime, as well as other >"provisioning/monitoring" benefits (if the platform provisions its RTP media >channels at startup, and can monitor their state, it can be sure of the >exact level of available resources at all times - important for telephony >systems) > >In the case of MRCP therefore, I would suggest we need a new pair of MRCP >level messages: >CALL_CONTEXT_BEGIN > - signal start of a "call" > - defines a "callId", unique for the RTSP session on which it is sent >CALL_CONTEXT_END > - signal end of the "call" for this RTSP session >plus to add the callId in a suitable header to the MRCP RECOGNISE and SPEAK >messages eg >CallId : > >Server vendors would then be free to reject resource requests on the same >RTSP/RTP channel that had overlapping callIds if they had a legal/commercial >need, or just ignore these new messages/header if they do not (this would >anyway be the default behaviour for an existing MRCP implementation I would >hope - be liberal in what you accept eh?) > >I don't know if you could throw this into the discussion, or maybe its >already covered in the requirements doc and I'm just not reading it >right..... > >Anyway, enjoy! > >Brian > >[Brian Wyld] [brian.wyld@eloquant.com] >[Directeur General R&D] >[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] >[advanced solutions for telecoms and IT services] > > > >>-----Message d'origine----- >>De : speechsc-admin@ietf.org >>[mailto:speechsc-admin@ietf.org]De la part >>de Eric Burger >>Envoyé : Tuesday, March 18, 2003 01:07 >>À : IETF SPEECHSC (E-mail) >>Cc : agenda@ietf.org >>Objet : [Speechsc] Agenda for Speechsc >> >> >>TUESDAY, March 18, 2003 >>1415-1515 Afternoon Sessions II >>Continental 7 TSV speechsc Speech Services Control WG >> >> >>Note Well and Agenda Bashing 5 min >>Requirements Status 5 min >>Protocol Analysis Status 20 min >>Document Assignments 10 min >>_______________________________________________ >>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 > > > --------------040402040402030508010505 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I am not sure if this is what you are looking for.
But MRCP has 2 mechanisms aimed towards this problem.

1. There is a channel-Reset header field that can be sent. This allows the client to tell the recognizer to drop the line quality and other voice quality information it has learned for the current voice session and resets this information. This was placed for the purpose of using a single open MRCP session for more than one call one after the other.

2. When you close an MRCP recognizer session, the recognizer could return a Context-Block of data (treated as an opaque block of data) back to the client. The client is required to send pass that block of opaque data to the next server in the SETUP message(if the new session is a continuation of the call).

Does this cover your needs. If so, then the requirement is already covered since the SpeechSC refers to MRCP as the model for requirements.

Sarvi

Brian Wyld wrote:
Hi Eric,

Although I cannot be there at the IETF meeting (sob), I have come across a
requirement for speechsc that I am not sure is covered in the requirements
doc..... (and yes, I know its late to throw in new
requirements.....sorry...)

The issue is "legal/commercial" rather than technical, but nontheless real
:-<

Problem
-------
Basically, the issue is that several ASR motor vendors require to be able to
identify the "call context" for the recognise requests, as they either
require all recognise requests for the same call to use exclusively the same
"port" (==RTSP/RTP session when using MRCP) or have discount levels
depending on the number of requests associated to the same call, or both(!).

MRCP is lacking in this department, as it has no clear mapping between a
call and an MRCP request. One might assume a 1:1 mapping between the RTSP
SETUP/TEARDOWN and call start/end, but in fact :
 - some mrcp clients do a SETUP/TEARDOWN per MRCP transaction
 - some mrcp clients do a SETUP at the platform bringup and TEARDOWN at
shutdown (possible with clients that can re-route the RTP stream dynamically
to different trunks for instance)

Although one could just tighten this up by stating 'the RTSP session
start/end MUST corrospond to the call start/end, and all MRCP requests
relating to the same call MUST use the same RTSP session', I think this is
far too restrictive, as there may be significant performance benefits to
keeping the RTSP session open for platform lifetime, as well as other
"provisioning/monitoring" benefits (if the platform provisions its RTP media
channels at startup, and can monitor their state, it can be sure of the
exact level of available resources at all times - important for telephony
systems)

In the case of MRCP therefore, I would suggest we need a new pair of MRCP
level messages:
CALL_CONTEXT_BEGIN
 - signal start of a "call"
 - defines a "callId", unique for the RTSP session on which it is sent
CALL_CONTEXT_END
 - signal end of the "call" for this RTSP session
plus to add the callId in a suitable header to the MRCP RECOGNISE and SPEAK
messages eg
CallId : <callId>

Server vendors would then be free to reject resource requests on the same
RTSP/RTP channel that had overlapping callIds if they had a legal/commercial
need, or just ignore these new messages/header if they do not (this would
anyway be the default behaviour for an existing MRCP implementation I would
hope - be liberal in what you accept eh?)

I don't know if you could throw this into the discussion, or maybe its
already covered in the requirements doc and I'm just not reading it
right.....

Anyway, enjoy!

Brian

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  
-----Message d'origine-----
De : speechsc-admin@ietf.org
[mailto:speechsc-admin@ietf.org]De la part
de Eric Burger
Envoyé : Tuesday, March 18, 2003 01:07
À : IETF SPEECHSC (E-mail)
Cc : agenda@ietf.org
Objet : [Speechsc] Agenda for Speechsc


TUESDAY, March 18, 2003
1415-1515 Afternoon Sessions II
Continental 7 TSV speechsc Speech Services Control WG


Note Well and Agenda Bashing   5 min
Requirements Status            5 min
Protocol Analysis Status      20 min
Document Assignments          10 min
_______________________________________________
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

--------------040402040402030508010505-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Mar 26 16:09:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14864 for ; Wed, 26 Mar 2003 16:09:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QLUQr02789 for speechsc-archive@odin.ietf.org; Wed, 26 Mar 2003 16:30:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLUQO02786 for ; Wed, 26 Mar 2003 16:30:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14848 for ; Wed, 26 Mar 2003 16:08:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLUFO02778; Wed, 26 Mar 2003 16:30:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLTqO02678 for ; Wed, 26 Mar 2003 16:29:52 -0500 Received: from mallaury.noc.nerim.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14807 for ; Wed, 26 Mar 2003 16:08:21 -0500 (EST) Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 9A3B862D1D; Wed, 26 Mar 2003 22:10:37 +0100 (CET) Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 5E3183B6CA; Wed, 26 Mar 2003 16:10:37 -0500 (EST) Reply-To: From: "Brian Wyld" To: "'Sarvi Shanmugham'" Cc: "'Eric Burger'" , "'IETF SPEECHSC (E-mail)'" Subject: RE: [Speechsc] Agenda for Speechsc Date: Wed, 26 Mar 2003 22:07:18 +0100 Message-ID: <003301c2f3db$b042f240$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C2F3E4.12075A40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3E7BF044.8000405@cisco.com> 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0034_01C2F3E4.12075A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Sarvi, I don't think either of these mechanisms covers the requirement. 1/ they are somewhat obscure - the need is for a specific mapping between the MRCP transactions and a call start/end identification. 2/ the channel reset allows the idea that the SETUP/TEARDOWN does not match to the call start/end, but does not help in matching requests to calls 3/ the Context-Block from the server is passed back in the next SETUP - so if the client wishes to have a single SETUP spanning multiple calls this does not help. Also, the need is for the client to notify the server of the call delimitations, rather than the server mapping SETUPs to calls.... I think there is a need for a specific requirement for instance: "The speechsc protocol MUST provide a means for the client to assign an identifier to a call session, and to communicate this to the speechsc server as being associated with a particular media session. The speechsc protocol MUST provide a means to associate all requests (ie ASR/TTS/SV/SI operation requests) to a specific call session id. " This information would not change the functional operation of the protocol; the server would then be free to either ignore this information, use it for billing, or use it to enforce a particular legal license mapping (eg start-call for a specific media session means that only requests with the same id are accepted on that session until the end-call releases it.) Brian -----Message d'origine----- De : Sarvi Shanmugham [mailto:sarvi@cisco.com] Envoyé : Saturday, March 22, 2003 06:10 À : brian.wyld@eloquant.com Cc : 'Eric Burger'; 'IETF SPEECHSC (E-mail)' Objet : Re: [Speechsc] Agenda for Speechsc I am not sure if this is what you are looking for. But MRCP has 2 mechanisms aimed towards this problem. 1. There is a channel-Reset header field that can be sent. This allows the client to tell the recognizer to drop the line quality and other voice quality information it has learned for the current voice session and resets this information. This was placed for the purpose of using a single open MRCP session for more than one call one after the other. 2. When you close an MRCP recognizer session, the recognizer could return a Context-Block of data (treated as an opaque block of data) back to the client. The client is required to send pass that block of opaque data to the next server in the SETUP message(if the new session is a continuation of the call). Does this cover your needs. If so, then the requirement is already covered since the SpeechSC refers to MRCP as the model for requirements. Sarvi Brian Wyld wrote: Hi Eric, Although I cannot be there at the IETF meeting (sob), I have come across a requirement for speechsc that I am not sure is covered in the requirements doc..... (and yes, I know its late to throw in new requirements.....sorry...) The issue is "legal/commercial" rather than technical, but nontheless real :-< Problem ------- Basically, the issue is that several ASR motor vendors require to be able to identify the "call context" for the recognise requests, as they either require all recognise requests for the same call to use exclusively the same "port" (==RTSP/RTP session when using MRCP) or have discount levels depending on the number of requests associated to the same call, or both(!). MRCP is lacking in this department, as it has no clear mapping between a call and an MRCP request. One might assume a 1:1 mapping between the RTSP SETUP/TEARDOWN and call start/end, but in fact : - some mrcp clients do a SETUP/TEARDOWN per MRCP transaction - some mrcp clients do a SETUP at the platform bringup and TEARDOWN at shutdown (possible with clients that can re-route the RTP stream dynamically to different trunks for instance) Although one could just tighten this up by stating 'the RTSP session start/end MUST corrospond to the call start/end, and all MRCP requests relating to the same call MUST use the same RTSP session', I think this is far too restrictive, as there may be significant performance benefits to keeping the RTSP session open for platform lifetime, as well as other "provisioning/monitoring" benefits (if the platform provisions its RTP media channels at startup, and can monitor their state, it can be sure of the exact level of available resources at all times - important for telephony systems) In the case of MRCP therefore, I would suggest we need a new pair of MRCP level messages: CALL_CONTEXT_BEGIN - signal start of a "call" - defines a "callId", unique for the RTSP session on which it is sent CALL_CONTEXT_END - signal end of the "call" for this RTSP session plus to add the callId in a suitable header to the MRCP RECOGNISE and SPEAK messages eg CallId : Server vendors would then be free to reject resource requests on the same RTSP/RTP channel that had overlapping callIds if they had a legal/commercial need, or just ignore these new messages/header if they do not (this would anyway be the default behaviour for an existing MRCP implementation I would hope - be liberal in what you accept eh?) I don't know if you could throw this into the discussion, or maybe its already covered in the requirements doc and I'm just not reading it right..... Anyway, enjoy! Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] -----Message d'origine----- De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part de Eric Burger Envoyé : Tuesday, March 18, 2003 01:07 À : IETF SPEECHSC (E-mail) Cc : agenda@ietf.org Objet : [Speechsc] Agenda for Speechsc TUESDAY, March 18, 2003 1415-1515 Afternoon Sessions II Continental 7 TSV speechsc Speech Services Control WG Note Well and Agenda Bashing 5 min Requirements Status 5 min Protocol Analysis Status 20 min Document Assignments 10 min _______________________________________________ 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 ------=_NextPart_000_0034_01C2F3E4.12075A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Sarvi,
 
I=20 don't think either of these mechanisms covers the=20 requirement.
 
1/ they are somewhat obscure - the need = is for a=20 specific mapping between the MRCP transactions and a call start/end=20 identification.
 
2/ the=20 channel reset allows the idea that the SETUP/TEARDOWN does not match to = the call=20 start/end, but does not help in matching requests to = calls
 
3/ the=20 Context-Block from the server is passed back in the next SETUP - so if = the=20 client wishes to have a single SETUP spanning multiple calls this does = not help.=20 Also, the need is for the client to notify the server of the call = delimitations,=20 rather than the server mapping SETUPs to calls....
 
I=20 think there is a need for a specific requirement for=20 instance:
"The=20 speechsc protocol MUST provide a means for the client to assign an=20 identifier to a call session, and to communicate this to the speechsc = server as=20 being associated with a particular media session. The speechsc = protocol=20 MUST provide a means to associate all requests (ie = ASR/TTS/SV/SI=20 operation requests) to a specific call session id. "
 
This=20 information would not change the functional operation of the protocol; = the=20 server would then be free to either ignore this information, use it for = billing,=20 or use it to enforce a particular legal license mapping (eg start-call = for a=20 specific media session means that only requests with the same id are = accepted on=20 that session until the end-call releases it.)
 
Brian
 
 

 

-----Message d'origine-----
De : Sarvi = Shanmugham=20 [mailto:sarvi@cisco.com]
Envoy=E9 : Saturday, March 22, = 2003=20 06:10
=C0 : brian.wyld@eloquant.com
Cc : = 'Eric=20 Burger'; 'IETF SPEECHSC (E-mail)'
Objet : Re: = [Speechsc] Agenda=20 for Speechsc

I am not sure if this is what you are = looking=20 for.
But MRCP has 2 mechanisms aimed towards this = problem.

1. There=20 is a channel-Reset header field that can be sent. This allows the = client to=20 tell the recognizer to drop the line quality and other voice quality=20 information it has learned for the current voice session and resets = this=20 information. This was placed for the purpose of using a single open = MRCP=20 session for more than one call one after the other.

2. When you = close=20 an MRCP recognizer session, the recognizer could return a = Context-Block of=20 data (treated as an opaque block of data) back to the client. The = client is=20 required to send pass that block of opaque data to the next server in = the=20 SETUP message(if the new session is a continuation of the = call).

Does=20 this cover your needs. If so, then the requirement is already covered = since=20 the SpeechSC refers to MRCP as the model for=20 requirements.

Sarvi

Brian Wyld wrote:
Hi Eric,

Although I cannot be there at the IETF meeting (sob), I have come across =
a
requirement for speechsc that I am not sure is covered in the =
requirements
doc..... (and yes, I know its late to throw in new
requirements.....sorry...)

The issue is "legal/commercial" rather than technical, but nontheless =
real
:-<

Problem
-------
Basically, the issue is that several ASR motor vendors require to be =
able to
identify the "call context" for the recognise requests, as they either
require all recognise requests for the same call to use exclusively the =
same
"port" (=3D=3DRTSP/RTP session when using MRCP) or have discount levels
depending on the number of requests associated to the same call, or =
both(!).

MRCP is lacking in this department, as it has no clear mapping between a
call and an MRCP request. One might assume a 1:1 mapping between the =
RTSP
SETUP/TEARDOWN and call start/end, but in fact :
 - some mrcp clients do a SETUP/TEARDOWN per MRCP transaction
 - some mrcp clients do a SETUP at the platform bringup and TEARDOWN at
shutdown (possible with clients that can re-route the RTP stream =
dynamically
to different trunks for instance)

Although one could just tighten this up by stating 'the RTSP session
start/end MUST corrospond to the call start/end, and all MRCP requests
relating to the same call MUST use the same RTSP session', I think this =
is
far too restrictive, as there may be significant performance benefits to
keeping the RTSP session open for platform lifetime, as well as other
"provisioning/monitoring" benefits (if the platform provisions its RTP =
media
channels at startup, and can monitor their state, it can be sure of the
exact level of available resources at all times - important for =
telephony
systems)

In the case of MRCP therefore, I would suggest we need a new pair of =
MRCP
level messages:
CALL_CONTEXT_BEGIN
 - signal start of a "call"
 - defines a "callId", unique for the RTSP session on which it is sent
CALL_CONTEXT_END
 - signal end of the "call" for this RTSP session
plus to add the callId in a suitable header to the MRCP RECOGNISE and =
SPEAK
messages eg
CallId : <callId>

Server vendors would then be free to reject resource requests on the =
same
RTSP/RTP channel that had overlapping callIds if they had a =
legal/commercial
need, or just ignore these new messages/header if they do not (this =
would
anyway be the default behaviour for an existing MRCP implementation I =
would
hope - be liberal in what you accept eh?)

I don't know if you could throw this into the discussion, or maybe its
already covered in the requirements doc and I'm just not reading it
right.....

Anyway, enjoy!

Brian

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  
-----Message d'origine-----
De : speechsc-admin@ietf.org
[mailto:speechsc-admin@ietf.org]De la part
de Eric Burger
Envoy=E9 : Tuesday, March 18, 2003 01:07
=C0 : IETF SPEECHSC (E-mail)
Cc : agenda@ietf.org
Objet : [Speechsc] Agenda for Speechsc


TUESDAY, March 18, 2003
1415-1515 Afternoon Sessions II
Continental 7 TSV speechsc Speech Services Control WG


Note Well and Agenda Bashing   5 min
Requirements Status            5 min
Protocol Analysis Status      20 min
Document Assignments          10 min
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

    

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

------=_NextPart_000_0034_01C2F3E4.12075A40-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Mar 28 03:30:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20708 for ; Fri, 28 Mar 2003 03:30:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S8pr516782 for speechsc-archive@odin.ietf.org; Fri, 28 Mar 2003 03:51:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S8ppO16778 for ; Fri, 28 Mar 2003 03:51:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20698 for ; Fri, 28 Mar 2003 03:29:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S8piO16748; Fri, 28 Mar 2003 03:51:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S8nWO16470 for ; Fri, 28 Mar 2003 03:50:08 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20647 for ; Fri, 28 Mar 2003 03:27:17 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2S8TZ4c015595; Fri, 28 Mar 2003 00:29:35 -0800 (PST) Received: from cisco.com (sjc-vpn4-758.cisco.com [10.21.82.246]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFG60298; Fri, 28 Mar 2003 00:27:11 -0800 (PST) Message-ID: <3E84075B.5010406@cisco.com> Date: Fri, 28 Mar 2003 00:27:07 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: brian.wyld@eloquant.com CC: "'Eric Burger'" , "'IETF SPEECHSC (E-mail)'" Subject: Re: [Speechsc] Agenda for Speechsc References: <003301c2f3db$b042f240$8300a8c0@hq.eloquant.com> Content-Type: multipart/alternative; boundary="------------070806060600060407020900" 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: , --------------070806060600060407020900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am confused with you requirements. I am not saying that the MRCP headers are aclean way of solving your problem. But I think they DO solve your exact problems. So I was just pointing out that this requirement is covered SPEECHSC through its reference to MRCP. Now in the SPEECHSC protocol, whether we use the MRCP mechanism to solve this requirment or not is a separate issue. Now coming to your comments below. Brian Wyld wrote: > Hi Sarvi, > > I don't think either of these mechanisms covers the requirement. > > 1/ they are somewhat obscure - the need is for a specific mapping > between the MRCP transactions and a call start/end identification. > In general an MRCP session is associated with a single call. Now if we choose to reuse a single MRCP session to multiple subsequent calls, thats where the Channel-Reset-Header comes into play. This ofcourse assumes that during the course of a call there is an MRCP session assoiated with that call, and that MRCP session will not be used for other calls. This covers 1 & 2 here. > 2/ the channel reset allows the idea that the SETUP/TEARDOWN does not > match to the call start/end, but does not help in matching requests to > calls > > 3/ the Context-Block from the server is passed back in the next SETUP > - so if the client wishes to have a single SETUP spanning multiple > calls this does not help. Also, the need is for the client to notify > the server of the call delimitations, rather than the server mapping > SETUPs to calls.... My reason for 3 is that this helps when you are switching between one media server and another, and we know the call is the same and hence the audio pipe is the same(just the audio, not the ports). > > I think there is a need for a specific requirement for instance: > "The speechsc protocol MUST provide a means for the client to assign > an identifier to a call session, and to communicate this to the > speechsc server as being associated with a particular media > session. The speechsc protocol MUST provide a means to associate all > requests (ie ASR/TTS/SV/SI operation requests) to a specific call > session id. " > > This information would not change the functional operation of the > protocol; the server would then be free to either ignore this > information, use it for billing, or use it to enforce a particular > legal license mapping (eg start-call for a specific media session > means that only requests with the same id are accepted on that session > until the end-call releases it.) We do have a Session-ID that can be used for billing and stuff. And the requirements for call association, which are primarily to learn audio line charactersitcs of the call for better performance is covered by the Context block and Channel-Reset headers. We can always design a cleaner approach in SpeechSC that these to methods used in MRCP. I am just avoiding having to make changes to SpeechSC requirements which is in a relative state of completion, and mainly because I see your requirements as already covered by reference to MRCP. Sarvi > > Brian > > > > --------------070806060600060407020900 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I am confused with you requirements.

I am not saying that the MRCP headers are aclean way of solving your problem. But I think they DO solve your exact problems. So I was just pointing out that this requirement is covered SPEECHSC through its reference to MRCP.

Now in the SPEECHSC protocol, whether we use the MRCP mechanism to solve this requirment or not is a separate issue.

Now coming to your comments below.

Brian Wyld wrote:
Hi Sarvi,
 
I don't think either of these mechanisms covers the requirement.
 
1/ they are somewhat obscure - the need is for a specific mapping between the MRCP transactions and a call start/end identification.
 
In general an MRCP session is associated with a single call.  Now if we choose to reuse a single MRCP session to multiple subsequent calls, thats where the Channel-Reset-Header comes into play.
This ofcourse assumes that during the course of a call there is an MRCP session assoiated with that call, and that MRCP session will not be used for other calls. This covers 1 & 2 here.
2/ the channel reset allows the idea that the SETUP/TEARDOWN does not match to the call start/end, but does not help in matching requests to calls
 
3/ the Context-Block from the server is passed back in the next SETUP - so if the client wishes to have a single SETUP spanning multiple calls this does not help. Also, the need is for the client to notify the server of the call delimitations, rather than the server mapping SETUPs to calls....
My reason for 3 is that this helps when you are switching between one media server and another, and we know the call is the same and hence the audio pipe is the same(just the audio, not the ports).
 
I think there is a need for a specific requirement for instance:
"The speechsc protocol MUST provide a means for the client to assign an identifier to a call session, and to communicate this to the speechsc server as being associated with a particular media session. The speechsc protocol MUST provide a means to associate all requests (ie ASR/TTS/SV/SI operation requests) to a specific call session id. "
 
This information would not change the functional operation of the protocol; the server would then be free to either ignore this information, use it for billing, or use it to enforce a particular legal license mapping (eg start-call for a specific media session means that only requests with the same id are accepted on that session until the end-call releases it.)
We do have a Session-ID that can be used for billing and stuff. And the requirements for call association, which are primarily to learn audio line charactersitcs of the call for better performance is covered by the Context block and Channel-Reset headers.

We can always design a cleaner approach in SpeechSC that these to methods used in MRCP.

I am just avoiding having to make changes to SpeechSC requirements which is in a relative state of completion, and mainly because I see your requirements as already covered by reference to MRCP.

Sarvi
 
Brian
 
 



--------------070806060600060407020900-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Mar 28 07:26:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25762 for ; Fri, 28 Mar 2003 07:26:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SCm8k32620 for speechsc-archive@odin.ietf.org; Fri, 28 Mar 2003 07:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SCm8O32617 for ; Fri, 28 Mar 2003 07:48:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25752 for ; Fri, 28 Mar 2003 07:25:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SCm4O32590; Fri, 28 Mar 2003 07:48:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SCjSO32519 for ; Fri, 28 Mar 2003 07:45:28 -0500 Received: from kraid.nerim.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25708 for ; Fri, 28 Mar 2003 07:23:11 -0500 (EST) Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37]) by kraid.nerim.net (Postfix) with ESMTP id 5B36A40F77; Fri, 28 Mar 2003 13:25:31 +0100 (CET) Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 4E9CD3B6CA; Fri, 28 Mar 2003 07:25:58 -0500 (EST) Reply-To: From: "Brian Wyld" To: "'Sarvi Shanmugham'" Cc: "'Eric Burger'" , "'IETF SPEECHSC (E-mail)'" Subject: RE: [Speechsc] Agenda for Speechsc Date: Fri, 28 Mar 2003 13:22:14 +0100 Message-ID: <011c01c2f524$ab234b80$8300a8c0@hq.eloquant.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011D_01C2F52D.0CE7B380" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3E84075B.5010406@cisco.com> 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_011D_01C2F52D.0CE7B380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sarvi, Ok, I see your point. However, I still think it would be better to have an explicit requirement as the use cases of the MRCP header are not very clear. I'm perhaps also confused as to the term "MRCP session". I see an RTSP session (ie SETUP/TEARDOWN) which is related to the media, but this RTSP session can be used sequentially by multiple different MRCP transactions. The Channel-Reset-Header allows the client to ensure that the media session is "clean" for its MRCP transaction, but offers no indication to the server as to the relationship between MRCP transactions. Between two MRCP RECOGNISE requests, I guess I don't see any way to associate them (whether on the same RTSP session or on different ones)? Brian -----Message d'origine----- De : Sarvi Shanmugham [mailto:sarvi@cisco.com] Envoye : Friday, March 28, 2003 09:27 A : brian.wyld@eloquant.com Cc : 'Eric Burger'; 'IETF SPEECHSC (E-mail)' Objet : Re: [Speechsc] Agenda for Speechsc I am confused with you requirements. I am not saying that the MRCP headers are aclean way of solving your problem. But I think they DO solve your exact problems. So I was just pointing out that this requirement is covered SPEECHSC through its reference to MRCP. Now in the SPEECHSC protocol, whether we use the MRCP mechanism to solve this requirment or not is a separate issue. Now coming to your comments below. Brian Wyld wrote: Hi Sarvi, I don't think either of these mechanisms covers the requirement. 1/ they are somewhat obscure - the need is for a specific mapping between the MRCP transactions and a call start/end identification. In general an MRCP session is associated with a single call. Now if we choose to reuse a single MRCP session to multiple subsequent calls, thats where the Channel-Reset-Header comes into play. This ofcourse assumes that during the course of a call there is an MRCP session assoiated with that call, and that MRCP session will not be used for other calls. This covers 1 & 2 here. 2/ the channel reset allows the idea that the SETUP/TEARDOWN does not match to the call start/end, but does not help in matching requests to calls 3/ the Context-Block from the server is passed back in the next SETUP - so if the client wishes to have a single SETUP spanning multiple calls this does not help. Also, the need is for the client to notify the server of the call delimitations, rather than the server mapping SETUPs to calls.... My reason for 3 is that this helps when you are switching between one media server and another, and we know the call is the same and hence the audio pipe is the same(just the audio, not the ports). I think there is a need for a specific requirement for instance: "The speechsc protocol MUST provide a means for the client to assign an identifier to a call session, and to communicate this to the speechsc server as being associated with a particular media session. The speechsc protocol MUST provide a means to associate all requests (ie ASR/TTS/SV/SI operation requests) to a specific call session id. " This information would not change the functional operation of the protocol; the server would then be free to either ignore this information, use it for billing, or use it to enforce a particular legal license mapping (eg start-call for a specific media session means that only requests with the same id are accepted on that session until the end-call releases it.) We do have a Session-ID that can be used for billing and stuff. And the requirements for call association, which are primarily to learn audio line charactersitcs of the call for better performance is covered by the Context block and Channel-Reset headers. We can always design a cleaner approach in SpeechSC that these to methods used in MRCP. I am just avoiding having to make changes to SpeechSC requirements which is in a relative state of completion, and mainly because I see your requirements as already covered by reference to MRCP. Sarvi Brian ------=_NextPart_000_011D_01C2F52D.0CE7B380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Sarvi,
 
Ok, I=20 see your point. However, I still think it would be better to have an = explicit=20 requirement as the use cases of the MRCP header are not very=20 clear.
 
I'm=20 perhaps also confused as to the term "MRCP session". =
 
I see=20 an RTSP session (ie SETUP/TEARDOWN) which is related to the media, but = this RTSP=20 session can be used sequentially by multiple different MRCP = transactions. The=20 Channel-Reset-Header allows the client to ensure that the media session = is=20 "clean" for its MRCP transaction, but offers no indication to the server = as to=20 the relationship between MRCP transactions.
 
Between two MRCP RECOGNISE requests, I guess = I don't=20 see any way to associate them (whether on the same RTSP session or on = different=20 ones)?
 
Brian

 

-----Message d'origine-----
De : Sarvi = Shanmugham=20 [mailto:sarvi@cisco.com]
Envoyé : Friday, March = 28, 2003=20 09:27
À : = brian.wyld@eloquant.com
Cc : 'Eric=20 Burger'; 'IETF SPEECHSC (E-mail)'
Objet : Re: = [Speechsc] Agenda=20 for Speechsc

I am confused with you requirements.=20

I am not saying that the MRCP headers are aclean way of = solving your=20 problem. But I think they DO solve your exact problems. So I was just = pointing=20 out that this requirement is covered SPEECHSC through its reference to = MRCP.

Now in the SPEECHSC protocol, whether we use the MRCP = mechanism=20 to solve this requirment or not is a separate issue.

Now coming = to your=20 comments below.

Brian Wyld wrote:
Hi=20 Sarvi,
 
I=20 don't think either of these mechanisms covers the=20 requirement.
 
1/ they are somewhat obscure - the = need is for=20 a specific mapping between the MRCP transactions and a call = start/end=20 identification.
 
In = general an=20 MRCP session is associated with a single call.  Now if we choose = to reuse=20 a single MRCP session to multiple subsequent calls, thats where the=20 Channel-Reset-Header comes into play.
This ofcourse assumes that = during the=20 course of a call there is an MRCP session assoiated with that call, = and that=20 MRCP session will not be used for other calls. This covers 1 & 2 = here.=20
2/=20 the channel reset allows the idea that the SETUP/TEARDOWN does not = match to=20 the call start/end, but does not help in matching requests to=20 calls
 
3/=20 the Context-Block from the server is passed back in the next SETUP - = so if=20 the client wishes to have a single SETUP spanning multiple calls = this does=20 not help. Also, the need is for the client to notify the server of = the call=20 delimitations, rather than the server mapping SETUPs to=20 calls....
My reason for 3 is that = this helps=20 when you are switching between one media server and another, and we = know the=20 call is the same and hence the audio pipe is the same(just the audio, = not the=20 ports).
 
I=20 think there is a need for a specific requirement for=20 instance:
"The speechsc protocol MUST provide = a means=20 for the client to assign an identifier to a call session, and to = communicate=20 this to the speechsc server as being associated with a particular = media=20 session. The speechsc protocol MUST provide a means to=20 associate all requests (ie ASR/TTS/SV/SI operation = requests) to a=20 specific call session id. "
 
This information would not change the = functional=20 operation of the protocol; the server would then be free to either = ignore=20 this information, use it for billing, or use it to enforce a = particular=20 legal license mapping (eg start-call for a specific media session = means that=20 only requests with the same id are accepted on that session until = the=20 end-call releases it.)
We do have a = Session-ID=20 that can be used for billing and stuff. And the requirements for call=20 association, which are primarily to learn audio line charactersitcs of = the=20 call for better performance is covered by the Context block and = Channel-Reset=20 headers.

We can always design a cleaner approach in SpeechSC = that these=20 to methods used in MRCP.

I am just avoiding having to make = changes to=20 SpeechSC requirements which is in a relative state of completion, and = mainly=20 because I see your requirements as already covered by reference to=20 MRCP.

Sarvi
 
Brian
 
 



------=_NextPart_000_011D_01C2F52D.0CE7B380-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc