From mailnull@www1.ietf.org Mon May 5 15:13:15 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 PAA12752 for ; Mon, 5 May 2003 15:13:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45JLLU27506 for speechsc-archive@odin.ietf.org; Mon, 5 May 2003 15:21:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45JLL827503 for ; Mon, 5 May 2003 15:21:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12699 for ; Mon, 5 May 2003 15:12:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ClQH-00000L-00 for speechsc-web-archive@ietf.org; Mon, 05 May 2003 15:14:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ClQH-00000C-00 for speechsc-web-archive@ietf.org; Mon, 05 May 2003 15:14:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45JL9827483; Mon, 5 May 2003 15:21:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45JK2827425 for ; Mon, 5 May 2003 15:20:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12530 for ; Mon, 5 May 2003 15:11:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ClOl-0007nO-00 for speechsc@ietf.org; Mon, 05 May 2003 15:13:15 -0400 Received: from valmiki.speechworks.com ([63.113.17.11] helo=speechworks.com) by ietf-mx with esmtp (Exim 4.12) id 19ClOg-0007mz-00 for speechsc@ietf.org; Mon, 05 May 2003 15:13:10 -0400 Received: from vishnu.speechworks.com (mailhost.speechworks.com [63.113.17.2]) by speechworks.com (8.11.6+Sun/8.9.3) with ESMTP id h45JIxv23523; Mon, 5 May 2003 15:19:00 -0400 (EDT) Received: from whitney (localhost [127.0.0.1]) by vishnu.speechworks.com (8.11.6+Sun/8.9.3) with SMTP id h45JCmZ04716; Mon, 5 May 2003 15:12:49 -0400 (EDT) From: "Brian Eberman" To: "Eric Burger" , "IETF SPEECHSC \(E-mail\)" Subject: RE: [Speechsc] Administrative Fiat Date: Mon, 5 May 2003 15:12:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0175_01C31318.C8AD76A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <52F49B5A0E5B0F4781C9C8F7159409E441629C@aster.us.int.genesyslab.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: , This is a multi-part message in MIME format. ------=_NextPart_000_0175_01C31318.C8AD76A0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by speechworks.com id h45JIxv23523 Content-Transfer-Encoding: quoted-printable Eric, Seems to be a bit of a consensus here. What are the next steps to be completed? -Brian E. Director Product Management and Services SpeechWorks International 695 Atlantic Avenue Boston, MA 02111 617 428 4444 -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Rajiv Dharmadhikari Sent: Friday, April 25, 2003 12:51 PM To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Administrative Fiat Brian, Can you resend the final draft of the protocl evaluation analysis to the initial team? What is left to be completed? Let's get it out of the way..= I am willing do complete my part since I don't know BEEP, COBOL and CORBA := -) Thanks, -Rajiv -----Original Message----- From: Brian Wyld [mailto:brian.wyld@eloquant.com] Sent: Friday, April 25, 2003 1:46 AM To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)' Subject: RE: [Speechsc] Administrative Fiat Eric, Sounds good to me...... although I believe there is still a significant b= ase of COBOL applications that may be critical to address....... Or, I contra-propose: 1. the protocol will be RTSP extended to include the current MRCP message= s 'natively', with addition of specific messages for SR/SI, and to define = the 'call session' mapping to the MRCP requests. 2. there will be a web services binding.... (sorry to be serious here) 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 : Thursday, April 24, 2003 17:03 > =C0 : IETF SPEECHSC (E-mail) > Objet : [Speechsc] Administrative Fiat > > > Date: 1 April 2003 > [everything associated with speechsc seems to go out late] > > Since there has been no progress on the protocol analysis > document, I have made the following decisions: > > 1. We need a new protocol. > > 2. Since no one seems to care, the protocol will be based on > BEEP and CORBA. > > 3. To ensure that people use the protocol, we will publish an > ADA binding. > > Unless I hear otherwise, this is the direction we will go. > > -- > - Eric > > > P.S. If I don't hear otherwise, we can consider the work of > the work group complete. > > _______________________________________________ > 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 ------=_NextPart_000_0175_01C31318.C8AD76A0 Content-Type: text/x-vcard; name="Brian Eberman.vcf" Content-Disposition: attachment; filename="Brian Eberman.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Eberman;Brian FN:Brian Eberman ORG:Speechworks International;Product Development TITLE:Director of Engineering, Carrier Technologies and Platforms TEL;WORK;VOICE:(617) 428-4444 TEL;WORK;FAX:617 428 1122 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;617 428 4444;695 Atlantic = Ave=3D0D=3D0A;Boston;MA;02111 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:617 428 4444=3D0D=3D0A695 = Atlantic Ave=3D0D=3D0A=3D0D=3D0ABoston, MA 02111 URL;WORK:http://www.speechworks.com EMAIL;PREF;INTERNET:bse@speechworks.com EMAIL;INTERNET:beberman@bellsouthips.com REV:20020505T175243Z END:VCARD ------=_NextPart_000_0175_01C31318.C8AD76A0-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu May 8 14:21:59 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 OAA02445 for ; Thu, 8 May 2003 14:21:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48IVXi05315 for speechsc-archive@odin.ietf.org; Thu, 8 May 2003 14:31:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48IVX805312 for ; Thu, 8 May 2003 14:31:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02432 for ; Thu, 8 May 2003 14:21:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dq3H-0004tw-00 for speechsc-web-archive@ietf.org; Thu, 08 May 2003 14:23:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dq3H-0004ts-00 for speechsc-web-archive@ietf.org; Thu, 08 May 2003 14:23:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48IVO805288; Thu, 8 May 2003 14:31:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48ISx805095 for ; Thu, 8 May 2003 14:28:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02368 for ; Thu, 8 May 2003 14:18:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dq0n-0004tB-00 for speechsc@ietf.org; Thu, 08 May 2003 14:20:57 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19Dq0m-0004sv-00 for speechsc@ietf.org; Thu, 08 May 2003 14:20:56 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30115; Thu, 08 May 2003 14:24:54 -0400 (EDT) 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, 8 May 2003 14:21:17 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D59E1F3@zoe.office.snowshore.com> Thread-Topic: [Speechsc] Administrative Fiat Thread-Index: AcMTOoiREvgqiEQOSjGefNpmZSNW5wCVAiYw From: "Eric Burger" To: "Brian Eberman" , "IETF SPEECHSC (E-mail)" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48ISx805096 Subject: [Speechsc] speechsc as a first-level protocol 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: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h48IVO805288 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48IVX805312 Content-Transfer-Encoding: 8bit Is there consensus on raising speechsc to being a first-level protocol? That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP? Does anyone strongly object? Would anyone be really upset if it isn't? Is there value to it being a first-level protocol inside an existing protocol? That is, use the session establishment and proxy infrastructure of SIP or RTSP and have speechsc-specific primitives as protocol extensions. > -----Original Message----- > From: Brian Eberman [mailto:bse@speechworks.com] > Sent: Mon, May 05, 2003 3:13 PM > To: Eric Burger; IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Administrative Fiat > > > Eric, > > Seems to be a bit of a consensus here. What are the next steps to be > completed? > > -Brian E. > > Director Product Management and Services > SpeechWorks International > 695 Atlantic Avenue > Boston, MA 02111 > 617 428 4444 > > > -----Original Message----- > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]On Behalf > Of Rajiv Dharmadhikari > Sent: Friday, April 25, 2003 12:51 PM > To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Administrative Fiat > > > Brian, > > Can you resend the final draft of the protocl evaluation > analysis to the > initial team? What is left to be completed? Let's get it out > of the way.. I > am willing do complete my part since I don't know BEEP, COBOL > and CORBA :-) > > Thanks, > > -Rajiv > > -----Original Message----- > From: Brian Wyld [mailto:brian.wyld@eloquant.com] > Sent: Friday, April 25, 2003 1:46 AM > To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)' > Subject: RE: [Speechsc] Administrative Fiat > > > Eric, > > Sounds good to me...... although I believe there is still a > significant base > of COBOL applications that may be critical to address....... > > Or, I contra-propose: > 1. the protocol will be RTSP extended to include the current > MRCP messages > 'natively', with addition of specific messages for SR/SI, > and to define the > 'call session' mapping to the MRCP requests. > > 2. there will be a web services binding.... > > (sorry to be serious here) > > 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é : Thursday, April 24, 2003 17:03 > > À : IETF SPEECHSC (E-mail) > > Objet : [Speechsc] Administrative Fiat > > > > > > Date: 1 April 2003 > > [everything associated with speechsc seems to go out late] > > > > Since there has been no progress on the protocol analysis > > document, I have made the following decisions: > > > > 1. We need a new protocol. > > > > 2. Since no one seems to care, the protocol will be based on > > BEEP and CORBA. > > > > 3. To ensure that people use the protocol, we will publish an > > ADA binding. > > > > Unless I hear otherwise, this is the direction we will go. > > > > -- > > - Eric > > > > > > P.S. If I don't hear otherwise, we can consider the work of > > the work group complete. > > > > _______________________________________________ > > 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu May 8 14:51: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 OAA03337 for ; Thu, 8 May 2003 14:51:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48J1Jn07796 for speechsc-archive@odin.ietf.org; Thu, 8 May 2003 15:01:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48J1I807793 for ; Thu, 8 May 2003 15:01:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03329 for ; Thu, 8 May 2003 14:51:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DqW4-00053O-00 for speechsc-web-archive@ietf.org; Thu, 08 May 2003 14:53:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DqW3-00053L-00 for speechsc-web-archive@ietf.org; Thu, 08 May 2003 14:53:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48J1D807777; Thu, 8 May 2003 15:01:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Irr807348 for ; Thu, 8 May 2003 14:53:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03171 for ; Thu, 8 May 2003 14:43:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DqOs-00051O-00 for speechsc@ietf.org; Thu, 08 May 2003 14:45:50 -0400 Received: from smtp802.mail.sc5.yahoo.com ([66.163.168.181]) by ietf-mx with smtp (Exim 4.12) id 19DqOr-00051L-00 for speechsc@ietf.org; Thu, 08 May 2003 14:45:50 -0400 Received: from n20.vocent.com (HELO safehouse) (karlmutc@pacbell.net@12.40.203.20 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 8 May 2003 18:46:43 -0000 From: "karlmutc" To: "IETF SPEECHSC \(E-mail\)" Cc: "Eric Burger" , "Brian Eberman" Subject: RE: [Speechsc] speechsc as a first-level protocol Date: Thu, 8 May 2003 11:47:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D59E1F3@zoe.office.snowshore.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: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h48J1D807777 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48J1I807793 Content-Transfer-Encoding: 8bit > Is there value to it being a first-level protocol inside an existing protocol? Yes technically. However, pragmatically, the difficulty for users/consumers is getting a usable implementation from the open/free source arena that is free from vendor drag. This requires forethought about how current open source efforts might fit. Ok so I'm putting the cart before the horse but its worth some thought given the complexity of existing VoIP implementations which are available. And where complexity could be a real barrier to adoption. Thanks Karl -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Eric Burger Sent: Thursday, May 08, 2003 11:21 AM To: Brian Eberman; IETF SPEECHSC (E-mail) Subject: [Speechsc] speechsc as a first-level protocol Is there consensus on raising speechsc to being a first-level protocol? That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP? Does anyone strongly object? Would anyone be really upset if it isn't? Is there value to it being a first-level protocol inside an existing protocol? That is, use the session establishment and proxy infrastructure of SIP or RTSP and have speechsc-specific primitives as protocol extensions. > -----Original Message----- > From: Brian Eberman [mailto:bse@speechworks.com] > Sent: Mon, May 05, 2003 3:13 PM > To: Eric Burger; IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Administrative Fiat > > > Eric, > > Seems to be a bit of a consensus here. What are the next steps to be > completed? > > -Brian E. > > Director Product Management and Services > SpeechWorks International > 695 Atlantic Avenue > Boston, MA 02111 > 617 428 4444 > > > -----Original Message----- > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]On Behalf > Of Rajiv Dharmadhikari > Sent: Friday, April 25, 2003 12:51 PM > To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Administrative Fiat > > > Brian, > > Can you resend the final draft of the protocl evaluation > analysis to the > initial team? What is left to be completed? Let's get it out > of the way.. I > am willing do complete my part since I don't know BEEP, COBOL > and CORBA :-) > > Thanks, > > -Rajiv > > -----Original Message----- > From: Brian Wyld [mailto:brian.wyld@eloquant.com] > Sent: Friday, April 25, 2003 1:46 AM > To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)' > Subject: RE: [Speechsc] Administrative Fiat > > > Eric, > > Sounds good to me...... although I believe there is still a > significant base > of COBOL applications that may be critical to address....... > > Or, I contra-propose: > 1. the protocol will be RTSP extended to include the current > MRCP messages > 'natively', with addition of specific messages for SR/SI, > and to define the > 'call session' mapping to the MRCP requests. > > 2. there will be a web services binding.... > > (sorry to be serious here) > > 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é : Thursday, April 24, 2003 17:03 > > À : IETF SPEECHSC (E-mail) > > Objet : [Speechsc] Administrative Fiat > > > > > > Date: 1 April 2003 > > [everything associated with speechsc seems to go out late] > > > > Since there has been no progress on the protocol analysis > > document, I have made the following decisions: > > > > 1. We need a new protocol. > > > > 2. Since no one seems to care, the protocol will be based on > > BEEP and CORBA. > > > > 3. To ensure that people use the protocol, we will publish an > > ADA binding. > > > > Unless I hear otherwise, this is the direction we will go. > > > > -- > > - Eric > > > > > > P.S. If I don't hear otherwise, we can consider the work of > > the work group complete. > > > > _______________________________________________ > > 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 > _______________________________________________ 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 Fri May 9 12:00:23 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 MAA21233 for ; Fri, 9 May 2003 12:00:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49GAO321019 for speechsc-archive@odin.ietf.org; Fri, 9 May 2003 12:10:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49GAO821016 for ; Fri, 9 May 2003 12:10:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21211 for ; Fri, 9 May 2003 11:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EAJn-0005SB-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 12:01:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EAJm-0005S8-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 12:01:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49GAH820991; Fri, 9 May 2003 12:10:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49G9g820910 for ; Fri, 9 May 2003 12:09:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21182 for ; Fri, 9 May 2003 11:59:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EAJ7-0005RR-00 for speechsc@ietf.org; Fri, 09 May 2003 12:01:13 -0400 Received: from smtp-105-friday.nerim.net ([62.4.16.105] helo=kraid.nerim.net) by ietf-mx with esmtp (Exim 4.12) id 19EAJ6-0005RO-00 for speechsc@ietf.org; Fri, 09 May 2003 12:01:12 -0400 Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37]) by kraid.nerim.net (Postfix) with ESMTP id 5CF1940F9D; Fri, 9 May 2003 18:02:07 +0200 (CEST) Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id F0EBD3B6CA; Fri, 9 May 2003 12:14:02 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'Eric Burger'" , "'Brian Eberman'" , "'IETF SPEECHSC (E-mail)'" Subject: RE: [Speechsc] speechsc as a first-level protocol Date: Fri, 9 May 2003 17:58:18 +0200 Message-ID: <14cd01c31643$cf3d8040$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4A3384433CE2AB46A63468CB207E209D59E1F3@zoe.office.snowshore.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: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h49GAH820991 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49GAO821016 Content-Transfer-Encoding: 8bit Sounds good to me IFF we mean by this not neccessarily reinventing the whole thing, but doing a pick-n-mix from current protocols..... Brian (eg, stick the SETUP and TEARDOWN messages from RTSP into MRCP draft, add MRCPSESSIONSTART/MRCPSESSIONEND messages to identify call start/end context and move onto thez virgin territory of SV/SI....) [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é : Thursday, May 08, 2003 20:21 > À : Brian Eberman; IETF SPEECHSC (E-mail) > Objet : [Speechsc] speechsc as a first-level protocol > > > Is there consensus on raising speechsc to being a first-level > protocol? That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP? > > Does anyone strongly object? > > Would anyone be really upset if it isn't? > > Is there value to it being a first-level protocol inside an > existing protocol? That is, use the session establishment > and proxy infrastructure of SIP or RTSP and have > speechsc-specific primitives as protocol extensions. > > > -----Original Message----- > > From: Brian Eberman [mailto:bse@speechworks.com] > > Sent: Mon, May 05, 2003 3:13 PM > > To: Eric Burger; IETF SPEECHSC (E-mail) > > Subject: RE: [Speechsc] Administrative Fiat > > > > > > Eric, > > > > Seems to be a bit of a consensus here. What are the next steps to be > > completed? > > > > -Brian E. > > > > Director Product Management and Services > > SpeechWorks International > > 695 Atlantic Avenue > > Boston, MA 02111 > > 617 428 4444 > > > > > > -----Original Message----- > > From: speechsc-admin@ietf.org > > [mailto:speechsc-admin@ietf.org]On Behalf > > Of Rajiv Dharmadhikari > > Sent: Friday, April 25, 2003 12:51 PM > > To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail) > > Subject: RE: [Speechsc] Administrative Fiat > > > > > > Brian, > > > > Can you resend the final draft of the protocl evaluation > > analysis to the > > initial team? What is left to be completed? Let's get it out > > of the way.. I > > am willing do complete my part since I don't know BEEP, COBOL > > and CORBA :-) > > > > Thanks, > > > > -Rajiv > > > > -----Original Message----- > > From: Brian Wyld [mailto:brian.wyld@eloquant.com] > > Sent: Friday, April 25, 2003 1:46 AM > > To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)' > > Subject: RE: [Speechsc] Administrative Fiat > > > > > > Eric, > > > > Sounds good to me...... although I believe there is still a > > significant base > > of COBOL applications that may be critical to address....... > > > > Or, I contra-propose: > > 1. the protocol will be RTSP extended to include the current > > MRCP messages > > 'natively', with addition of specific messages for SR/SI, > > and to define the > > 'call session' mapping to the MRCP requests. > > > > 2. there will be a web services binding.... > > > > (sorry to be serious here) > > > > 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é : Thursday, April 24, 2003 17:03 > > > À : IETF SPEECHSC (E-mail) > > > Objet : [Speechsc] Administrative Fiat > > > > > > > > > Date: 1 April 2003 > > > [everything associated with speechsc seems to go out late] > > > > > > Since there has been no progress on the protocol analysis > > > document, I have made the following decisions: > > > > > > 1. We need a new protocol. > > > > > > 2. Since no one seems to care, the protocol will be based on > > > BEEP and CORBA. > > > > > > 3. To ensure that people use the protocol, we will publish an > > > ADA binding. > > > > > > Unless I hear otherwise, this is the direction we will go. > > > > > > -- > > > - Eric > > > > > > > > > P.S. If I don't hear otherwise, we can consider the work of > > > the work group complete. > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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 Fri May 9 12:48:13 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 MAA22620 for ; Fri, 9 May 2003 12:48:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49GwGr24394 for speechsc-archive@odin.ietf.org; Fri, 9 May 2003 12:58:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49GwG824391 for ; Fri, 9 May 2003 12:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22592 for ; Fri, 9 May 2003 12:47:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EB45-0005l3-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 12:49:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EB45-0005l0-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 12:49:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Gw5824366; Fri, 9 May 2003 12:58:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49GvR824333 for ; Fri, 9 May 2003 12:57:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22569 for ; Fri, 9 May 2003 12:46:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EB3J-0005kV-00 for speechsc@ietf.org; Fri, 09 May 2003 12:48:57 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19EB3I-0005kE-00 for speechsc@ietf.org; Fri, 09 May 2003 12:48:56 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h49GnEGf007666; Fri, 9 May 2003 09:49:15 -0700 (PDT) Received: from cisco.com (dhcp-128-107-138-223.cisco.com [128.107.138.223]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHA71651; Fri, 9 May 2003 09:49:14 -0700 (PDT) Message-ID: <3EBBDC09.2050406@cisco.com> Date: Fri, 09 May 2003 09:49:13 -0700 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'" , "'Brian Eberman'" , "'IETF SPEECHSC (E-mail)'" Subject: Re: [Speechsc] speechsc as a first-level protocol References: <14cd01c31643$cf3d8040$8300010a@hq.eloquant.com> Content-Type: multipart/alternative; boundary="------------060902010006030401020803" 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: , --------------060902010006030401020803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-5.cisco.com id h49GnEGf007666 Content-Transfer-Encoding: quoted-printable Hi Brian, Great. I am half way through a proposal trying to do exactly=20 that. Since there was not much activity, I thought a proposal document=20 would drive some discussion. So after consulting with Eric, I have been=20 writing a proposal, doing exactly that. As part 1, I have taken out all RTSP tunnelling and related aspects from=20 the currentt MRCP specification, this is done. As Part to 2, I am=20 adding/advocating SIP based INVITE/BYE extensions a choice to create and=20 manage the session. I will hopefully have this proposal done by the beginning of the week=20 after next. Sarvi Brian Wyld wrote: >Sounds good to me IFF we mean by this not neccessarily reinventing the w= hole >thing, but doing a pick-n-mix from current protocols..... > >Brian > > (eg, stick the SETUP and TEARDOWN messages from RTSP into MRCP draft, a= dd >MRCPSESSIONSTART/MRCPSESSIONEND messages to identify call start/end cont= ext >and move onto thez virgin territory of SV/SI....) > > > > >[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] > > =20 > >>-----Message d'origine----- >>De : speechsc-admin@ietf.org >>[mailto:speechsc-admin@ietf.org]De la part >>de Eric Burger >>Envoy=E9 : Thursday, May 08, 2003 20:21 >>=C0 : Brian Eberman; IETF SPEECHSC (E-mail) >>Objet : [Speechsc] speechsc as a first-level protocol >> >> >>Is there consensus on raising speechsc to being a first-level >>protocol? That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP? >> >>Does anyone strongly object? >> >>Would anyone be really upset if it isn't? >> >>Is there value to it being a first-level protocol inside an >>existing protocol? That is, use the session establishment >>and proxy infrastructure of SIP or RTSP and have >>speechsc-specific primitives as protocol extensions. >> >> =20 >> >>>-----Original Message----- >>>From: Brian Eberman [mailto:bse@speechworks.com] >>>Sent: Mon, May 05, 2003 3:13 PM >>>To: Eric Burger; IETF SPEECHSC (E-mail) >>>Subject: RE: [Speechsc] Administrative Fiat >>> >>> >>>Eric, >>> >>>Seems to be a bit of a consensus here. What are the next steps to be >>>completed? >>> >>>-Brian E. >>> >>>Director Product Management and Services >>>SpeechWorks International >>>695 Atlantic Avenue >>>Boston, MA 02111 >>>617 428 4444 >>> >>> >>>-----Original Message----- >>>From: speechsc-admin@ietf.org >>>[mailto:speechsc-admin@ietf.org]On Behalf >>>Of Rajiv Dharmadhikari >>>Sent: Friday, April 25, 2003 12:51 PM >>>To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail) >>>Subject: RE: [Speechsc] Administrative Fiat >>> >>> >>>Brian, >>> >>>Can you resend the final draft of the protocl evaluation >>>analysis to the >>>initial team? What is left to be completed? Let's get it out >>>of the way.. I >>>am willing do complete my part since I don't know BEEP, COBOL >>>and CORBA :-) >>> >>>Thanks, >>> >>>-Rajiv >>> >>>-----Original Message----- >>>From: Brian Wyld [mailto:brian.wyld@eloquant.com] >>>Sent: Friday, April 25, 2003 1:46 AM >>>To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)' >>>Subject: RE: [Speechsc] Administrative Fiat >>> >>> >>>Eric, >>> >>>Sounds good to me...... although I believe there is still a >>>significant base >>>of COBOL applications that may be critical to address....... >>> >>>Or, I contra-propose: >>>1. the protocol will be RTSP extended to include the current >>>MRCP messages >>>'natively', with addition of specific messages for SR/SI, >>>and to define the >>>'call session' mapping to the MRCP requests. >>> >>>2. there will be a web services binding.... >>> >>>(sorry to be serious here) >>> >>>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] >>> >>> =20 >>> >>>>-----Message d'origine----- >>>>De : speechsc-admin@ietf.org >>>>[mailto:speechsc-admin@ietf.org]De la part >>>>de Eric Burger >>>>Envoy=E9 : Thursday, April 24, 2003 17:03 >>>>=C0 : IETF SPEECHSC (E-mail) >>>>Objet : [Speechsc] Administrative Fiat >>>> >>>> >>>>Date: 1 April 2003 >>>>[everything associated with speechsc seems to go out late] >>>> >>>>Since there has been no progress on the protocol analysis >>>>document, I have made the following decisions: >>>> >>>>1. We need a new protocol. >>>> >>>>2. Since no one seems to care, the protocol will be based on >>>>BEEP and CORBA. >>>> >>>>3. To ensure that people use the protocol, we will publish an >>>>ADA binding. >>>> >>>>Unless I hear otherwise, this is the direction we will go. >>>> >>>>-- >>>>- Eric >>>> >>>> >>>>P.S. If I don't hear otherwise, we can consider the work of >>>>the work group complete. >>>> >>>>_______________________________________________ >>>>Speechsc mailing list >>>>Speechsc@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> =20 >>>> >>>_______________________________________________ >>>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 >>> >>> =20 >>> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> =20 >> > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > =20 > --------------060902010006030401020803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Brian,
       Great. I am half way through a proposal trying to do exactly that. Since there was not much activity, I thought a proposal document would drive some discussion. So after consulting with Eric, I have been writing a proposal, doing exactly that.

As part 1, I have taken out all RTSP tunnelling and related aspects from the currentt MRCP specification, this is done.  As Part to 2, I am adding/advocating SIP based INVITE/BYE extensions a choice to create and manage the session.

I will hopefully have this proposal done by the beginning of the week after next.

Sarvi


Brian Wyld wrote:
Sounds good to me IFF we mean by this not neccessarily reinventing the whole
thing, but doing a pick-n-mix from current protocols.....

Brian

 (eg, stick the SETUP and TEARDOWN messages from RTSP into MRCP draft, add
MRCPSESSIONSTART/MRCPSESSIONEND messages to identify call start/end context
and move onto thez virgin territory of SV/SI....)




[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é : Thursday, May 08, 2003 20:21
À : Brian Eberman; IETF SPEECHSC (E-mail)
Objet : [Speechsc] speechsc as a first-level protocol


Is there consensus on raising speechsc to being a first-level
protocol?  That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP?

Does anyone strongly object?

Would anyone be really upset if it isn't?

Is there value to it being a first-level protocol inside an
existing protocol?  That is, use the session establishment
and proxy infrastructure of SIP or RTSP and have
speechsc-specific primitives as protocol extensions.

    
-----Original Message-----
From: Brian Eberman [mailto:bse@speechworks.com]
Sent: Mon, May 05, 2003 3:13 PM
To: Eric Burger; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] Administrative Fiat


Eric,

Seems to be a bit of a consensus here. What are the next steps to be
completed?

-Brian E.

Director Product Management and Services
SpeechWorks International
695 Atlantic Avenue
Boston, MA 02111
617 428 4444


-----Original Message-----
From: speechsc-admin@ietf.org
[mailto:speechsc-admin@ietf.org]On Behalf
Of Rajiv Dharmadhikari
Sent: Friday, April 25, 2003 12:51 PM
To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] Administrative Fiat


Brian,

Can you resend the final draft of the protocl evaluation
analysis to the
initial team? What is left to be completed? Let's get it out
of the way.. I
am willing do complete my part since I don't know BEEP, COBOL
and CORBA :-)

Thanks,

-Rajiv

-----Original Message-----
From: Brian Wyld [mailto:brian.wyld@eloquant.com]
Sent: Friday, April 25, 2003 1:46 AM
To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)'
Subject: RE: [Speechsc] Administrative Fiat


Eric,

Sounds good to me...... although I believe there is still a
significant base
of COBOL applications that may be critical to address.......

Or, I contra-propose:
1. the protocol will be RTSP extended to include the current
MRCP messages
'natively', with addition of specific  messages for SR/SI,
and to define the
'call session' mapping to the MRCP requests.

2. there will be a web services binding....

(sorry to be serious here)

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é : Thursday, April 24, 2003 17:03
À : IETF SPEECHSC (E-mail)
Objet : [Speechsc] Administrative Fiat


Date: 1 April 2003
[everything associated with speechsc seems to go out late]

Since there has been no progress on the protocol analysis
document, I have made the following decisions:

1. We need a new protocol.

2. Since no one seems to care, the protocol will be based on
BEEP and CORBA.

3. To ensure that people use the protocol, we will publish an
ADA binding.

Unless I hear otherwise, this is the direction we will go.

--
- Eric


P.S.  If I don't hear otherwise, we can consider the work of
the work group complete.

_______________________________________________
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

      
_______________________________________________
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

--------------060902010006030401020803-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri May 9 12:53:06 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 MAA22837 for ; Fri, 9 May 2003 12:53:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49H37o24876 for speechsc-archive@odin.ietf.org; Fri, 9 May 2003 13:03:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49H37824873 for ; Fri, 9 May 2003 13:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22824 for ; Fri, 9 May 2003 12:52:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EB8m-0005oH-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 12:54:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EB8m-0005oE-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 12:54:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49H31824849; Fri, 9 May 2003 13:03:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49H2p824807 for ; Fri, 9 May 2003 13:02:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22800 for ; Fri, 9 May 2003 12:52:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EB8X-0005nn-00 for speechsc@ietf.org; Fri, 09 May 2003 12:54:21 -0400 Received: from smtp-105-friday.noc.nerim.net ([62.4.17.105] helo=mallaury.noc.nerim.net) by ietf-mx with esmtp (Exim 4.12) id 19EB8W-0005nk-00 for speechsc@ietf.org; Fri, 09 May 2003 12:54:20 -0400 Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 5810362DFF; Fri, 9 May 2003 18:55:13 +0200 (CEST) Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 2FFF03B6CA; Fri, 9 May 2003 13:07:11 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "'Sarvi Shanmugham'" Cc: "'Eric Burger'" , "'Brian Eberman'" , "'IETF SPEECHSC (E-mail)'" Subject: RE: [Speechsc] speechsc as a first-level protocol Date: Fri, 9 May 2003 18:51:25 +0200 Message-ID: <14e801c3164b$3b0e7f70$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_14E9_01C3165B.FE974F70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3EBBDC09.2050406@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_14E9_01C3165B.FE974F70 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h49H31824849 Content-Transfer-Encoding: quoted-printable Hi, Great! However, I would REALLY like to see separation of the media setup/teardown function and the concept of 'mrcp' session (which could be mapped onto a call nicely). My experience with MRCP so far is that this can be a prickly issue (for those ASR vendors who have strong licensing view about ports and calls!!!= ) Brian -----Message d'origine----- De : Sarvi Shanmugham [mailto:sarvi@cisco.com] Envoy=E9 : Friday, May 09, 2003 18:49 =C0 : brian.wyld@eloquant.com Cc : 'Eric Burger'; 'Brian Eberman'; 'IETF SPEECHSC (E-mail)' Objet : Re: [Speechsc] speechsc as a first-level protocol Hi Brian, Great. I am half way through a proposal trying to do exactly tha= t. Since there was not much activity, I thought a proposal document would dr= ive some discussion. So after consulting with Eric, I have been writing a proposal, doing exactly that. As part 1, I have taken out all RTSP tunnelling and related aspects fro= m the currentt MRCP specification, this is done. As Part to 2, I am adding/advocating SIP based INVITE/BYE extensions a choice to create and manage the session. I will hopefully have this proposal done by the beginning of the week after next. Sarvi Brian Wyld wrote: Sounds good to me IFF we mean by this not neccessarily reinventing the wh= ole thing, but doing a pick-n-mix from current protocols..... Brian (eg, stick the SETUP and TEARDOWN messages from RTSP into MRCP draft, ad= d MRCPSESSIONSTART/MRCPSESSIONEND messages to identify call start/end conte= xt and move onto thez virgin territory of SV/SI....) [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 : Thursday, May 08, 2003 20:21 =C0 : Brian Eberman; IETF SPEECHSC (E-mail) Objet : [Speechsc] speechsc as a first-level protocol Is there consensus on raising speechsc to being a first-level protocol? That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP? Does anyone strongly object? Would anyone be really upset if it isn't? Is there value to it being a first-level protocol inside an existing protocol? That is, use the session establishment and proxy infrastructure of SIP or RTSP and have speechsc-specific primitives as protocol extensions. -----Original Message----- From: Brian Eberman [mailto:bse@speechworks.com] Sent: Mon, May 05, 2003 3:13 PM To: Eric Burger; IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Administrative Fiat Eric, Seems to be a bit of a consensus here. What are the next steps to be completed? -Brian E. Director Product Management and Services SpeechWorks International 695 Atlantic Avenue Boston, MA 02111 617 428 4444 -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf Of Rajiv Dharmadhikari Sent: Friday, April 25, 2003 12:51 PM To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Administrative Fiat Brian, Can you resend the final draft of the protocl evaluation analysis to the initial team? What is left to be completed? Let's get it out of the way.. I am willing do complete my part since I don't know BEEP, COBOL and CORBA :-) Thanks, -Rajiv -----Original Message----- From: Brian Wyld [mailto:brian.wyld@eloquant.com] Sent: Friday, April 25, 2003 1:46 AM To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)' Subject: RE: [Speechsc] Administrative Fiat Eric, Sounds good to me...... although I believe there is still a significant base of COBOL applications that may be critical to address....... Or, I contra-propose: 1. the protocol will be RTSP extended to include the current MRCP messages 'natively', with addition of specific messages for SR/SI, and to define the 'call session' mapping to the MRCP requests. 2. there will be a web services binding.... (sorry to be serious here) 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 : Thursday, April 24, 2003 17:03 =C0 : IETF SPEECHSC (E-mail) Objet : [Speechsc] Administrative Fiat Date: 1 April 2003 [everything associated with speechsc seems to go out late] Since there has been no progress on the protocol analysis document, I have made the following decisions: 1. We need a new protocol. 2. Since no one seems to care, the protocol will be based on BEEP and CORBA. 3. To ensure that people use the protocol, we will publish an ADA binding. Unless I hear otherwise, this is the direction we will go. -- - Eric P.S. If I don't hear otherwise, we can consider the work of the work group complete. _______________________________________________ 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 _______________________________________________ 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_14E9_01C3165B.FE974F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Great!=20 However, I would REALLY like to see separation of the media = setup/teardown=20 function and the concept of 'mrcp' session (which could be mapped onto a = call=20 nicely).
 
My=20 experience with MRCP so far is that this can be a prickly issue (for = those ASR=20 vendors who have strong licensing view about ports and=20 calls!!!)
 
Brian
 

 

-----Message d'origine-----
De : Sarvi = Shanmugham=20 [mailto:sarvi@cisco.com]
Envoy=E9 : Friday, May 09, = 2003=20 18:49
=C0 : brian.wyld@eloquant.com
Cc : = 'Eric=20 Burger'; 'Brian Eberman'; 'IETF SPEECHSC = (E-mail)'
Objet : Re:=20 [Speechsc] speechsc as a first-level protocol

Hi=20 Brian,
       Great. I am half way through a = proposal=20 trying to do exactly that. Since there was not much activity, I = thought a=20 proposal document would drive some discussion. So after consulting = with Eric,=20 I have been writing a proposal, doing exactly that.

As part 1, = I have=20 taken out all RTSP tunnelling and related aspects from the currentt = MRCP=20 specification, this is done.  As Part to 2, I am = adding/advocating SIP=20 based INVITE/BYE extensions a choice to create and manage the=20 session.

I will hopefully have this proposal done by the = beginning of=20 the week after next.

Sarvi


Brian Wyld wrote:
Sounds good to me IFF we mean by this not =
neccessarily reinventing the whole
thing, but doing a pick-n-mix from current protocols.....

Brian

 (eg, stick the SETUP and TEARDOWN messages from RTSP into MRCP draft, =
add
MRCPSESSIONSTART/MRCPSESSIONEND messages to identify call start/end =
context
and move onto thez virgin territory of SV/SI....)




[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 : Thursday, May 08, 2003 20:21
=C0 : Brian Eberman; IETF SPEECHSC (E-mail)
Objet : [Speechsc] speechsc as a first-level protocol


Is there consensus on raising speechsc to being a first-level
protocol?  That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP?

Does anyone strongly object?

Would anyone be really upset if it isn't?

Is there value to it being a first-level protocol inside an
existing protocol?  That is, use the session establishment
and proxy infrastructure of SIP or RTSP and have
speechsc-specific primitives as protocol extensions.

    
-----Original =
Message-----
From: Brian Eberman [mailto:bse@speechworks.com]
Sent: Mon, May 05, 2003 3:13 PM
To: Eric Burger; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] Administrative Fiat


Eric,

Seems to be a bit of a consensus here. What are the next steps to be
completed?

-Brian E.

Director Product Management and Services
SpeechWorks International
695 Atlantic Avenue
Boston, MA 02111
617 428 4444


-----Original Message-----
From: speechsc-admin@ietf.org
[mailto:speechsc-admin@ietf.org]On Behalf
Of Rajiv Dharmadhikari
Sent: Friday, April 25, 2003 12:51 PM
To: brian.wyld@eloquant.com; =
Eric Burger; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] Administrative Fiat


Brian,

Can you resend the final draft of the protocl evaluation
analysis to the
initial team? What is left to be completed? Let's get it out
of the way.. I
am willing do complete my part since I don't know BEEP, COBOL
and CORBA :-)

Thanks,

-Rajiv

-----Original Message-----
From: Brian Wyld [mailto:brian.wyld@eloquant.com]
Sent: Friday, April 25, 2003 1:46 AM
To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)'
Subject: RE: [Speechsc] Administrative Fiat


Eric,

Sounds good to me...... although I believe there is still a
significant base
of COBOL applications that may be critical to address.......

Or, I contra-propose:
1. the protocol will be RTSP extended to include the current
MRCP messages
'natively', with addition of specific  messages for SR/SI,
and to define the
'call session' mapping to the MRCP requests.

2. there will be a web services binding....

(sorry to be serious here)

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 : Thursday, April 24, 2003 17:03
=C0 : IETF SPEECHSC (E-mail)
Objet : [Speechsc] Administrative Fiat


Date: 1 April 2003
[everything associated with speechsc seems to go out late]

Since there has been no progress on the protocol analysis
document, I have made the following decisions:

1. We need a new protocol.

2. Since no one seems to care, the protocol will be based on
BEEP and CORBA.

3. To ensure that people use the protocol, we will publish an
ADA binding.

Unless I hear otherwise, this is the direction we will go.

--
- Eric


P.S.  If I don't hear otherwise, we can consider the work of
the work group complete.

_______________________________________________
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
_______________________________________________
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

    

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

------=_NextPart_000_14E9_01C3165B.FE974F70-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri May 9 13:10:10 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 NAA23530 for ; Fri, 9 May 2003 13:10:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49HKBt26703 for speechsc-archive@odin.ietf.org; Fri, 9 May 2003 13:20:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49HKB826700 for ; Fri, 9 May 2003 13:20:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23502 for ; Fri, 9 May 2003 13:09:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EBPI-0005y4-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 13:11:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EBPI-0005y1-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 13:11:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49HK4826690; Fri, 9 May 2003 13:20:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49HJ9826636 for ; Fri, 9 May 2003 13:19:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23480 for ; Fri, 9 May 2003 13:08:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EBOI-0005xg-00 for speechsc@ietf.org; Fri, 09 May 2003 13:10:38 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19EBOH-0005xL-00 for speechsc@ietf.org; Fri, 09 May 2003 13:10:37 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h49HAsGh011290; Fri, 9 May 2003 10:10:56 -0700 (PDT) Received: from cisco.com (dhcp-128-107-138-223.cisco.com [128.107.138.223]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHA75352; Fri, 9 May 2003 10:10:53 -0700 (PDT) Message-ID: <3EBBE11D.7000605@cisco.com> Date: Fri, 09 May 2003 10:10:53 -0700 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'" , "'Brian Eberman'" , "'IETF SPEECHSC (E-mail)'" Subject: Re: [Speechsc] speechsc as a first-level protocol References: <14e801c3164b$3b0e7f70$8300010a@hq.eloquant.com> Content-Type: multipart/alternative; boundary="------------080602050605060609010403" 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: , --------------080602050605060609010403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-5.cisco.com id h49HAsGh011290 Content-Transfer-Encoding: quoted-printable Absolutely. This will only be an initial proposal. We need to work out ways of differentiating/separating the session to=20 the the Media server and the call that is being treated and figure how=20 to share the media session and use it for different calls. Sarvi Brian Wyld wrote: > Hi, > =20 > Great! However, I would REALLY like to see separation of the media=20 > setup/teardown function and the concept of 'mrcp' session (which could=20 > be mapped onto a call nicely). > =20 > My experience with MRCP so far is that this can be a prickly issue=20 > (for those ASR vendors who have strong licensing view about ports and=20 > calls!!!) > =20 > Brian > =20 > > =20 > > -----Message d'origine----- > De : Sarvi Shanmugham [mailto:sarvi@cisco.com] > Envoy=E9 : Friday, May 09, 2003 18:49 > =C0 : brian.wyld@eloquant.com > Cc : 'Eric Burger'; 'Brian Eberman'; 'IETF SPEECHSC (E-mail)' > Objet : Re: [Speechsc] speechsc as a first-level protocol > > Hi Brian, > Great. I am half way through a proposal trying to do > exactly that. Since there was not much activity, I thought a > proposal document would drive some discussion. So after consulting > with Eric, I have been writing a proposal, doing exactly that. > > As part 1, I have taken out all RTSP tunnelling and related > aspects from the currentt MRCP specification, this is done. As > Part to 2, I am adding/advocating SIP based INVITE/BYE extensions > a choice to create and manage the session. > > I will hopefully have this proposal done by the beginning of the > week after next. > > Sarvi > > > Brian Wyld wrote: > >>Sounds good to me IFF we mean by this not neccessarily reinventing the = whole >>thing, but doing a pick-n-mix from current protocols..... >> >>Brian >> >> (eg, stick the SETUP and TEARDOWN messages from RTSP into MRCP draft, = add >>MRCPSESSIONSTART/MRCPSESSIONEND messages to identify call start/end con= text >>and move onto thez virgin territory of SV/SI....) >> >> >> >> >>[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] >> >> =20 >> >>>-----Message d'origine----- >>>De : speechsc-admin@ietf.org >>>[mailto:speechsc-admin@ietf.org]De la part >>>de Eric Burger >>>Envoy=E9 : Thursday, May 08, 2003 20:21 >>>=C0 : Brian Eberman; IETF SPEECHSC (E-mail) >>>Objet : [Speechsc] speechsc as a first-level protocol >>> >>> >>>Is there consensus on raising speechsc to being a first-level >>>protocol? That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP? >>> >>>Does anyone strongly object? >>> >>>Would anyone be really upset if it isn't? >>> >>>Is there value to it being a first-level protocol inside an >>>existing protocol? That is, use the session establishment >>>and proxy infrastructure of SIP or RTSP and have >>>speechsc-specific primitives as protocol extensions. >>> >>> =20 >>> >>>>-----Original Message----- >>>>From: Brian Eberman [mailto:bse@speechworks.com] >>>>Sent: Mon, May 05, 2003 3:13 PM >>>>To: Eric Burger; IETF SPEECHSC (E-mail) >>>>Subject: RE: [Speechsc] Administrative Fiat >>>> >>>> >>>>Eric, >>>> >>>>Seems to be a bit of a consensus here. What are the next steps to be >>>>completed? >>>> >>>>-Brian E. >>>> >>>>Director Product Management and Services >>>>SpeechWorks International >>>>695 Atlantic Avenue >>>>Boston, MA 02111 >>>>617 428 4444 >>>> >>>> >>>>-----Original Message----- >>>>From: speechsc-admin@ietf.org >>>>[mailto:speechsc-admin@ietf.org]On Behalf >>>>Of Rajiv Dharmadhikari >>>>Sent: Friday, April 25, 2003 12:51 PM >>>>To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail) >>>>Subject: RE: [Speechsc] Administrative Fiat >>>> >>>> >>>>Brian, >>>> >>>>Can you resend the final draft of the protocl evaluation >>>>analysis to the >>>>initial team? What is left to be completed? Let's get it out >>>>of the way.. I >>>>am willing do complete my part since I don't know BEEP, COBOL >>>>and CORBA :-) >>>> >>>>Thanks, >>>> >>>>-Rajiv >>>> >>>>-----Original Message----- >>>>From: Brian Wyld [mailto:brian.wyld@eloquant.com] >>>>Sent: Friday, April 25, 2003 1:46 AM >>>>To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)' >>>>Subject: RE: [Speechsc] Administrative Fiat >>>> >>>> >>>>Eric, >>>> >>>>Sounds good to me...... although I believe there is still a >>>>significant base >>>>of COBOL applications that may be critical to address....... >>>> >>>>Or, I contra-propose: >>>>1. the protocol will be RTSP extended to include the current >>>>MRCP messages >>>>'natively', with addition of specific messages for SR/SI, >>>>and to define the >>>>'call session' mapping to the MRCP requests. >>>> >>>>2. there will be a web services binding.... >>>> >>>>(sorry to be serious here) >>>> >>>>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] >>>> >>>> =20 >>>> >>>>>-----Message d'origine----- >>>>>De : speechsc-admin@ietf.org >>>>>[mailto:speechsc-admin@ietf.org]De la part >>>>>de Eric Burger >>>>>Envoy=E9 : Thursday, April 24, 2003 17:03 >>>>>=C0 : IETF SPEECHSC (E-mail) >>>>>Objet : [Speechsc] Administrative Fiat >>>>> >>>>> >>>>>Date: 1 April 2003 >>>>>[everything associated with speechsc seems to go out late] >>>>> >>>>>Since there has been no progress on the protocol analysis >>>>>document, I have made the following decisions: >>>>> >>>>>1. We need a new protocol. >>>>> >>>>>2. Since no one seems to care, the protocol will be based on >>>>>BEEP and CORBA. >>>>> >>>>>3. To ensure that people use the protocol, we will publish an >>>>>ADA binding. >>>>> >>>>>Unless I hear otherwise, this is the direction we will go. >>>>> >>>>>-- >>>>>- Eric >>>>> >>>>> >>>>>P.S. If I don't hear otherwise, we can consider the work of >>>>>the work group complete. >>>>> >>>>>_______________________________________________ >>>>>Speechsc mailing list >>>>>Speechsc@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> =20 >>>>> >>>>_______________________________________________ >>>>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 >>>> >>>> =20 >>>> >>>_______________________________________________ >>>Speechsc mailing list >>>Speechsc@ietf.org >>>https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> =20 >>> >> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> =20 >> > --------------080602050605060609010403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Absolutely. This will only be an initial proposal.
We need to work out ways of differentiating/separating  the session to the the Media server and the call that is being treated and figure how to share the media  session and use it for different calls.

Sarvi

Brian Wyld wrote:
Hi,
 
Great! However, I would REALLY like to see separation of the media setup/teardown function and the concept of 'mrcp' session (which could be mapped onto a call nicely).
 
My experience with MRCP so far is that this can be a prickly issue (for those ASR vendors who have strong licensing view about ports and calls!!!)
 
Brian
 

 

-----Message d'origine-----
De : Sarvi Shanmugham [mailto:sarvi@cisco.com]
Envoyé : Friday, May 09, 2003 18:49
À : brian.wyld@eloquant.com
Cc : 'Eric Burger'; 'Brian Eberman'; 'IETF SPEECHSC (E-mail)'
Objet : Re: [Speechsc] speechsc as a first-level protocol

Hi Brian,
       Great. I am half way through a proposal trying to do exactly that. Since there was not much activity, I thought a proposal document would drive some discussion. So after consulting with Eric, I have been writing a proposal, doing exactly that.

As part 1, I have taken out all RTSP tunnelling and related aspects from the currentt MRCP specification, this is done.  As Part to 2, I am adding/advocating SIP based INVITE/BYE extensions a choice to create and manage the session.

I will hopefully have this proposal done by the beginning of the week after next.

Sarvi


Brian Wyld wrote:
Sounds good to me IFF we mean by this not neccessarily reinventing the whole
thing, but doing a pick-n-mix from current protocols.....

Brian

 (eg, stick the SETUP and TEARDOWN messages from RTSP into MRCP draft, add
MRCPSESSIONSTART/MRCPSESSIONEND messages to identify call start/end context
and move onto thez virgin territory of SV/SI....)




[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é : Thursday, May 08, 2003 20:21
À : Brian Eberman; IETF SPEECHSC (E-mail)
Objet : [Speechsc] speechsc as a first-level protocol


Is there consensus on raising speechsc to being a first-level
protocol?  That is, it will NOT be embedded in SIP, RTSP, or :-) SNMP?

Does anyone strongly object?

Would anyone be really upset if it isn't?

Is there value to it being a first-level protocol inside an
existing protocol?  That is, use the session establishment
and proxy infrastructure of SIP or RTSP and have
speechsc-specific primitives as protocol extensions.

    
-----Original Message-----
From: Brian Eberman [mailto:bse@speechworks.com]
Sent: Mon, May 05, 2003 3:13 PM
To: Eric Burger; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] Administrative Fiat


Eric,

Seems to be a bit of a consensus here. What are the next steps to be
completed?

-Brian E.

Director Product Management and Services
SpeechWorks International
695 Atlantic Avenue
Boston, MA 02111
617 428 4444


-----Original Message-----
From: speechsc-admin@ietf.org
[mailto:speechsc-admin@ietf.org]On Behalf
Of Rajiv Dharmadhikari
Sent: Friday, April 25, 2003 12:51 PM
To: brian.wyld@eloquant.com; Eric Burger; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] Administrative Fiat


Brian,

Can you resend the final draft of the protocl evaluation
analysis to the
initial team? What is left to be completed? Let's get it out
of the way.. I
am willing do complete my part since I don't know BEEP, COBOL
and CORBA :-)

Thanks,

-Rajiv

-----Original Message-----
From: Brian Wyld [mailto:brian.wyld@eloquant.com]
Sent: Friday, April 25, 2003 1:46 AM
To: 'Eric Burger'; 'IETF SPEECHSC (E-mail)'
Subject: RE: [Speechsc] Administrative Fiat


Eric,

Sounds good to me...... although I believe there is still a
significant base
of COBOL applications that may be critical to address.......

Or, I contra-propose:
1. the protocol will be RTSP extended to include the current
MRCP messages
'natively', with addition of specific  messages for SR/SI,
and to define the
'call session' mapping to the MRCP requests.

2. there will be a web services binding....

(sorry to be serious here)

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é : Thursday, April 24, 2003 17:03
À : IETF SPEECHSC (E-mail)
Objet : [Speechsc] Administrative Fiat


Date: 1 April 2003
[everything associated with speechsc seems to go out late]

Since there has been no progress on the protocol analysis
document, I have made the following decisions:

1. We need a new protocol.

2. Since no one seems to care, the protocol will be based on
BEEP and CORBA.

3. To ensure that people use the protocol, we will publish an
ADA binding.

Unless I hear otherwise, this is the direction we will go.

--
- Eric


P.S.  If I don't hear otherwise, we can consider the work of
the work group complete.

_______________________________________________
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

      
_______________________________________________
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


--------------080602050605060609010403-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri May 9 14:39:23 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 OAA26665 for ; Fri, 9 May 2003 14:39:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49InRA02144 for speechsc-archive@odin.ietf.org; Fri, 9 May 2003 14:49:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49InR802141 for ; Fri, 9 May 2003 14:49:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26658 for ; Fri, 9 May 2003 14:38:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECne-0006aa-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 14:40:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ECnd-0006aW-00 for speechsc-web-archive@ietf.org; Fri, 09 May 2003 14:40:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49InM802126; Fri, 9 May 2003 14:49:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Im8802061 for ; Fri, 9 May 2003 14:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26620 for ; Fri, 9 May 2003 14:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECmO-0006Zk-00 for speechsc@ietf.org; Fri, 09 May 2003 14:39:36 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19ECmN-0006Zh-00 for speechsc@ietf.org; Fri, 09 May 2003 14:39:35 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 9 May 2003 19:43:17 +0100 Received: from gbnewp1014m ([172.25.1.94]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Fri, 9 May 2003 19:40:31 +0100 From: "Neil Deason" To: "'Sarvi Shanmugham'" , Cc: "'Eric Burger'" , "'Brian Eberman'" , "'IETF SPEECHSC \(E-mail\)'" Subject: RE: [Speechsc] speechsc as a first-level protocol Date: Fri, 9 May 2003 11:40:29 -0700 Message-ID: <000601c3165a$77dd10b0$5e0119ac@eu.ubiquity.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C3161F.CB7E38B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3EBBDC09.2050406@cisco.com> X-OriginalArrivalTime: 09 May 2003 18:40:31.0678 (UTC) FILETIME=[783F2DE0:01C3165A] 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: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3161F.CB7E38B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf Of Sarvi Shanmugham Sent: 09 May 2003 09:49 To: brian.wyld@eloquant.com Cc: 'Eric Burger'; 'Brian Eberman'; 'IETF SPEECHSC (E-mail)' Subject: Re: [Speechsc] speechsc as a first-level protocol Hi Brian, Great. I am half way through a proposal trying to do exactly that. Since there was not much activity, I thought a proposal document would drive some discussion. So after consulting with Eric, I have been writing a proposal, doing exactly that. As part 1, I have taken out all RTSP tunnelling and related aspects from the currentt MRCP specification, this is done. As Part to 2, I am adding/advocating SIP based INVITE/BYE extensions a choice to create and manage the session=20 =20 I am glad to see this part being included. I think this is the proper relationship between speechsc and SIP. =20 FYI I wrote a somewhat rough and ready draft on SDP usage for SOAP sessions: =20 =20 http://www.ietf.org/internet-drafts/draft-deason-mmusic-sdp-soap-00.txt =20 If I can be of any help contributing to work on SIP/SDP for 'speechsc' sessions please ask. =20 Cheers, Neil. ------=_NextPart_000_0007_01C3161F.CB7E38B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From:=20 speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf = Of=20 Sarvi Shanmugham
Sent: 09 May 2003 09:49
To:=20 brian.wyld@eloquant.com
Cc: 'Eric Burger'; 'Brian Eberman'; = 'IETF=20 SPEECHSC (E-mail)'
Subject: Re: [Speechsc] speechsc as a = first-level=20 protocol

Hi Brian,
       Great. I am half way = through a=20 proposal trying to do exactly that. Since there was not much activity, = I=20 thought a proposal document would drive some discussion. So after = consulting=20 with Eric, I have been writing a proposal, doing exactly = that.

As part=20 1, I have taken out all RTSP tunnelling and related aspects from the = currentt=20 MRCP specification, this is done.  As Part to 2, I am = adding/advocating=20 SIP based INVITE/BYE extensions a choice to create and manage the = session 
 
I am glad=20 to see this part being included. I think this is the proper = relationship=20 between speechsc and SIP.
 
FYI I = wrote a=20 somewhat rough and ready draft on SDP usage for SOAP=20 sessions:
 
  http://www.ietf.org/internet-drafts/draft-deason-mmusic-sdp-soap-= 00.txt
 
If I can=20 be of any help contributing to work on SIP/SDP for 'speechsc' sessions = please=20 ask.
 
Cheers,
Neil.
------=_NextPart_000_0007_01C3161F.CB7E38B0-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri May 16 13:51:59 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 NAA04989 for ; Fri, 16 May 2003 13:51:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GHJZw29819 for speechsc-archive@odin.ietf.org; Fri, 16 May 2003 13:19:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GHJZB29816 for ; Fri, 16 May 2003 13:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04968 for ; Fri, 16 May 2003 13:51:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GjOU-0001mP-00 for speechsc-web-archive@ietf.org; Fri, 16 May 2003 13:53:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19GjOT-0001mL-00 for speechsc-web-archive@ietf.org; Fri, 16 May 2003 13:53:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GHJRB29801; Fri, 16 May 2003 13:19:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GHFxB29664 for ; Fri, 16 May 2003 13:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04843 for ; Fri, 16 May 2003 13:47:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GjL0-0001k5-00 for speechsc@ietf.org; Fri, 16 May 2003 13:49:46 -0400 Received: from [131.107.8.3] (helo=exchange.microsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19GjKz-0001jt-00 for speechsc@ietf.org; Fri, 16 May 2003 13:49:46 -0400 Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 May 2003 10:50:26 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 May 2003 10:50:26 -0700 Received: from DF-DINGO.platinum.corp.microsoft.com ([10.197.0.81]) by DF-BEG.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6700); Fri, 16 May 2003 10:50:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Fri, 16 May 2003 10:50:25 -0700 Message-ID: <38AACDF10D1B1341AB6F253663424A3188C75D@DF-DINGO.platinum.corp.microsoft.com> Thread-Topic: SpeechSC and audio transmission protocols thread-index: AcMb05/DSzvkcN65TX+SZ7hU6odZZA== From: "Salvador Neto" To: "IETF SPEECHSC \(E-mail\)" , "Eric Burger" Cc: "Hsiao-Wuen Hon" , "Stephen Potter" , "Albert Kooiman" X-OriginalArrivalTime: 16 May 2003 17:50:26.0061 (UTC) FILETIME=[A1A6ABD0:01C31BD3] Subject: [Speechsc] SpeechSC and audio transmission protocols 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: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BD3.A164DBA5" ------_=_NextPart_001_01C31BD3.A164DBA5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 We would like to raise the following concern on audio transmission protocols in SpeechSC, which we had a chance to discuss with Eric Burger a couple of weeks ago in person. =20 We believe that SpeechSC as a control protocol should not define nor dictate what media transmission protocol to use. People should be able to use SpeechSC to negotiate different signal protocols (RTP or TCP for example) according to different needs. In real time communication like text-to-speech, RTP will be an appropriate choice. In a speech recognition service scenario, a guaranteed-delivery protocol like TCP could be more appropriate. One perspective on this is that there is a trade-off between delay and quality of transmission that is dependent on the application, and that SpeechSC itself should not decide that trade-off, if it is to be applicable to different applications (and the one that seems often overlooked in the discussions is a multimodal client/DCR scenario).=20 =20 So, in summary, we believe the current requirement for SpeechSC to only allow RTP is too heavy, and request that it be revisited in light of the above.=20 =20 =20 Thanks, Salva ------_=_NextPart_001_01C31BD3.A164DBA5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We would like to raise the following concern on = audio transmission protocols in SpeechSC, which we had a chance to discuss = with Eric Burger a couple of weeks ago in person.

 

We believe that SpeechSC as a control protocol should = not define nor dictate what media transmission protocol to use. People should be able to use SpeechSC to negotiate different = signal protocols (RTP or TCP for example) according to different needs. In real = time communication like text-to-speech, RTP will be an appropriate choice. In = a speech recognition service scenario, a guaranteed-delivery protocol like = TCP could be more appropriate. One perspective on this is that there is = a trade-off between delay and quality of transmission that is = dependent on the application, and that SpeechSC itself should not decide that = trade-off, if it is to be applicable to different applications (and the one that = seems often overlooked in the discussions is a multimodal client/DCR = scenario).

 

So, in summary, we believe the current requirement for SpeechSC to only allow RTP is too heavy, and request = that it be revisited in light of the above.

 

 

Thanks,
Salva

=00 ------_=_NextPart_001_01C31BD3.A164DBA5-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed May 28 16:57:47 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 QAA23461 for ; Wed, 28 May 2003 16:57:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SKvKq10983 for speechsc-archive@odin.ietf.org; Wed, 28 May 2003 16:57:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKvKB10976 for ; Wed, 28 May 2003 16:57:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23446 for ; Wed, 28 May 2003 16:57:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7xU-0007nR-00 for speechsc-web-archive@ietf.org; Wed, 28 May 2003 16:55:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L7xU-0007nN-00 for speechsc-web-archive@ietf.org; Wed, 28 May 2003 16:55:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKvBB10962; Wed, 28 May 2003 16:57:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SKu6B10915 for ; Wed, 28 May 2003 16:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23280 for ; Wed, 28 May 2003 16:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L7wI-0007kd-00 for speechsc@ietf.org; Wed, 28 May 2003 16:54:26 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19L7wH-0007kN-00 for speechsc@ietf.org; Wed, 28 May 2003 16:54:25 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 28 May 2003 21:58:46 +0100 Received: from gbnewp1014m ([172.25.1.96]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 May 2003 21:56:02 +0100 From: "Neil Deason" To: "'Sarvi Shanmugham'" , Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC Date: Wed, 28 May 2003 13:55:57 -0700 Message-ID: <00d401c3255b$8ade9340$600119ac@eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3ECBEFBE.3000507@cisco.com> X-OriginalArrivalTime: 28 May 2003 20:56:03.0362 (UTC) FILETIME=[8CF4F020:01C3255B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4SKu6B10916 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. I have some comments on the usage of SDP for SPEECHSC part of the draft. + I would suggest an alternative format for the 'm=' line. Use a value for the protocol that designates the underlying transport protocol, this then allows for TCP, TLS, SCTP to be used with speechsc. For the media format use the mime type 'application/speechsc'. Then use two SDP attributes to describe the resource ID and channel ID. An example written this way would therefore be: m=control 32416 TCP application/speechsc a=resourceId:speechrec a=channelId:32AECB234338 + Section 3.2 refers to setting the offerer setting the port to 0 in the SDP when it wants to act as the client in the connection setup procedure. However, setting a port to 0 has a defined meaning that a stream is offered but must not be used according to RFC3264. This an area where alignment with draft-ietf-mmusic-sdp-comedia-05.txt could help. That recommends the offerer use a value of port 9 (the discard port) in its offer. This work also then defines a SDP attribute to define the client/server roles to be used in the connection set up procedure, which could be reused here. + Section 3.2 refers to a client removing a 'm=' line from the SDP description in a session to de-allocate a resource. RFC3264 describes the mode for removing a media stream as continuing to offer it, but with the port set to 0. + The SDP in Example 1 of the draft would not be legal according to RFC 2327 - the SDP in the INVITE is missing a mandatory 'm=' line. This may not be a big deal as it was not clear to me why you would have this preliminary offer/answer prior to establishing the resource control channel. If there is no clear reason the exchange described in Example 1 would be unnecessary and can be removed. + Finally a few nits have crept in: The SIP URL used in the contact header of the examples has an illegal whitespace in it, the SIP messages are missing Via headers. I have revised the examples in the draft accordingly below. They could still use some cleaning up, but hopefully it helps illustrate the above comments. (Example 1 deleted - so pervious Example 2 becomes 1 etc.) Example 1. C->S: INVITE sip:mresources@mediaserver.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 To: MediaServer From: sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: Content-Type: application/sdp Content-Length: ... v=0 o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 s=- c=IN IP4 224.2.17.12 m=control 9 TCP application/speechsc a=direction:active a=resourceId:speechsynth m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=recvonly S->C: SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 To: MediaServer From: sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: Content-Type: application/sdp Content-Length: ... v=0 o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 s=- c=IN IP4 224.2.17.12 m=control 32416 TCP application/speechsc a=direction:passive a=resourceId:speechsynth a=channelId:32AECB234338 m=audio 48260 RTP/AVP 00 96 a=rtpmap:0 pcmu/8000 a=sendonly C->S: ACK sip:speechsc@mediaserver.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 To: MediaServer ;tag=a6c85cf From: Sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314162 ACK Content-Length: 0 Example 2. C->S: INVITE sip:mresources@mediaserver.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 To: MediaServer From: sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314163 INVITE Contact: Content-Type: application/sdp Content-Length: ... v=0 o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 s=- c=IN IP4 224.2.17.12 m=control 9 TCP application/speechsc a=direction:active a=resourceId:speechrec m=control 9 TCP application/speechsc a=direction:active a=resourceId:speechsynth m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=sendrecv S->C: SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 To: MediaServer From: sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314163 INVITE Contact: Content-Type: application/sdp Content-Length: 131 v=0 o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 s=- c=IN IP4 224.2.17.12 m=control 32416 TCP application/speechsc a=direction:passive a=resourceId:speechrec a=channelId:32AECB234338 m=control 32416 TCP application/speechsc a=channelId:32AECB234339 a=resourceId:speechsynth a=direction:passive m=audio 48260 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=sendrecv C->S: ACK sip:speechsc@mediaserver.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 To: MediaServer ;tag=a6c85cf From: Sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314164 ACK Content-Length: 0 Example 3. C->S: INVITE sip:mresources@mediaserver.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 To: MediaServer From: sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314163 INVITE Contact: Content-Type: application/sdp Content-Length: ... v=0 o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 s=- c=IN IP4 224.2.17.12 m=control 0 TCP application/speechsc a=direction:active a=resourceId:speechrec m=control 9 TCP application/speechsc a=direction:active a=resourceId:speechsynth m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=recvonly S->C: SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 To: MediaServer From: sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314163 INVITE Contact: Content-Type: application/sdp Content-Length: 131 v=0 o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 s=- c=IN IP4 224.2.17.12 m=control 0 TCP application/speechsc a=direction:passive a=resourceId:speechrec a=channelId:32AECB234338 m=control 32416 TCP application/speechsc a=resourceId:speechsynth a=channelId:32AECB234339 a=direction:passive m=audio 48260 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=sendonly C->S: ACK sip:speechsc@mediaserver.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 To: MediaServer ;tag=a6c85cf From: Sarvi ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314164 ACK Content-Length: 0 Finally one thing I think the WG needs to be aware of is the proposed new charter of the mmusic WG. A clear motivation there appears to be to draw a line under what gets added to SDP as it is today and what would be waiting for SDP NG. I think a too draconian interpretation of that proposed charter might present a problem here. (As well as in the SIMPLE WG). hth, Neil. -- http://users.rcn.com/neildeason/ > -----Original Message----- > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org] On Behalf Of Sarvi Shanmugham > Sent: 21 May 2003 14:30 > To: speechsc@ietf.org > Subject: [Speechsc] Protpcol proposal for SPEECHSC > > > > > Hi > Please find attached a proposal for a SPEECHSC protocol. This > leverages the MRCP specification. But removes the tunnelling > aspects of > the protocol. I have also submitted this document to the > internet drafts > repository and should be available from there soon. > > The current version does not address SI and SV aspects of the > requirements document. But addresses most of the others. This > document > is meant to be a starting point for a possible direction that the > SPEECHSC protocol could take. Based on interest and comments > received, > we can proceed to add SI and SV capabilities in a following > version of > the draft. > > Any thoughts. > > Sarvi > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu May 29 16:27: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 QAA18249 for ; Thu, 29 May 2003 16:27:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TKR2718815 for speechsc-archive@odin.ietf.org; Thu, 29 May 2003 16:27:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TKR2B18812 for ; Thu, 29 May 2003 16:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18233 for ; Thu, 29 May 2003 16:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LTxg-0002CN-00 for speechsc-web-archive@ietf.org; Thu, 29 May 2003 16:25:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LTxg-0002CK-00 for speechsc-web-archive@ietf.org; Thu, 29 May 2003 16:25:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TKQpB18771; Thu, 29 May 2003 16:26:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TKJkB18564 for ; Thu, 29 May 2003 16:19:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18122 for ; Thu, 29 May 2003 16:19:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LTqf-0002AQ-00 for speechsc@ietf.org; Thu, 29 May 2003 16:18:05 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19LTqe-00029z-00 for speechsc@ietf.org; Thu, 29 May 2003 16:18:04 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h4TKJAAV018651; Thu, 29 May 2003 13:19:10 -0700 (PDT) Received: from cisco.com (dhcp-128-107-138-233.cisco.com [128.107.138.233]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHT80130; Thu, 29 May 2003 13:19:09 -0700 (PDT) Message-ID: <3ED66B3D.60501@cisco.com> Date: Thu, 29 May 2003 13:19:09 -0700 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: Neil Deason CC: speechsc@ietf.org Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC References: <00d401c3255b$8ade9340$600119ac@eu.ubiquity.net> Content-Type: multipart/alternative; boundary="------------030806050600030000020601" 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: , --------------030806050600030000020601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit some comments line. Neil Deason wrote: >Hi. > >I have some comments on the usage of SDP for SPEECHSC part of the draft. > > >+ I would suggest an alternative format for the 'm=' line. Use a value >for the protocol that designates the underlying transport protocol, this >then allows for TCP, TLS, SCTP to be used with speechsc. For the media >format use the mime type 'application/speechsc'. Then use two SDP >attributes to describe the resource ID and channel ID. An example >written this way would therefore be: > > m=control 32416 TCP application/speechsc > a=resourceId:speechrec > a=channelId:32AECB234338 > 1. I am fine with using TCP/SCTP/TLS as the transport field of the m-line and specifiying the channel-id/resource-id as an attribute of the m-line. That said, could you explain what we gain between using a transport of SPEECHSC(whisch specifies what transports are supported) and your suggestion of specifying TCP or SCTP in the transport field of the m-line. My current approach seems similar to examples used where the transport is claimed to be "h323". 2. Channel -id / resource format Do you see problem with the channel id covering the resource identity and the channel identity? I had done it this way, so that we have the option of requesting resource-id "00" to mean, on demand allocation. This returns a channel-id of "32AECB23433800" where 00 means on-demand resource usage. There is no specific resourece that is being reserved or allocated. This then allows an ASR or TTS or SI or SV command to be issued. The just need to have a channel-id of "32AECB234338XX" where XX is the resource identifier. It also has the added benefit of figuring out from the chhanel -id what type of resource is being controlled. >+ Section 3.2 refers to setting the offerer setting the port to 0 in the >SDP when it wants to act as the client in the connection setup >procedure. However, setting a port to 0 has a defined meaning that a >stream is offered but must not be used according to RFC3264. This an >area where alignment with draft-ietf-mmusic-sdp-comedia-05.txt could >help. That recommends the offerer use a value of port 9 (the discard >port) in its offer. This work also then defines a SDP attribute to >define the client/server roles to be used in the connection set up >procedure, which could be reused here. > Agreed. I will make the appropriate changes in the next revision. > >+ Section 3.2 refers to a client removing a 'm=' line from the SDP >description in a session to de-allocate a resource. RFC3264 describes >the mode for removing a media stream as continuing to offer it, but with >the port set to 0. > Agreed. I will make the appropriate changes in the next revision. > >+ The SDP in Example 1 of the draft would not be legal according to RFC >2327 - the SDP in the INVITE is missing a mandatory 'm=' line. This may >not be a big deal as it was not clear to me why you would have this >preliminary offer/answer prior to establishing the resource control >channel. If there is no clear reason the exchange described in Example 1 >would be unnecessary and can be removed. > I was just trying to demonstrate that there could be times in the SIP session when there is no m-lines becuase there is no resources used or media between the client and the server. This may most likely happen mid session than at the beginning. the SIP session may add m-line for the different resources as need and m-lines for audio as needed by the resource. The client could allocate and deallocate resources(m-lines) as needed within in the session. This might mean that there are times, when the client has released the all the individual resources but may want to allocate it as part of the session at a later point. At these points I don't want to have to destroy the whole SIP session and recreate it. Anyway, atleast thats what I was trying to do. If this is illegal in SIP, I will remove it or find an alternative for this. > >+ Finally a few nits have crept in: The SIP URL used in the contact >header of the examples has an illegal whitespace in it, the SIP messages >are missing Via headers. > I will incorporate these into the next revision. Thx, Sarvi > >I have revised the examples in the draft accordingly below. They could >still use some cleaning up, but hopefully it helps illustrate the above >comments. > >(Example 1 deleted - so pervious Example 2 becomes 1 etc.) > >Example 1. > C->S: > INVITE sip:mresources@mediaserver.com SIP/2.0 > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > To: MediaServer > From: sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314161 INVITE > Contact: > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 > s=- > c=IN IP4 224.2.17.12 > m=control 9 TCP application/speechsc > a=direction:active > a=resourceId:speechsynth > m=audio 49170 RTP/AVP 0 96 > a=rtpmap:0 pcmu/8000 > a=recvonly > > S->C: > SIP/2.0 200 OK > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > To: MediaServer > From: sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314161 INVITE > Contact: > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 > s=- > c=IN IP4 224.2.17.12 > m=control 32416 TCP application/speechsc > a=direction:passive > a=resourceId:speechsynth > a=channelId:32AECB234338 > m=audio 48260 RTP/AVP 00 96 > a=rtpmap:0 pcmu/8000 > a=sendonly > > C->S: > ACK sip:speechsc@mediaserver.com SIP/2.0 > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > To: MediaServer ;tag=a6c85cf > From: Sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314162 ACK > Content-Length: 0 > >Example 2. > C->S: > INVITE sip:mresources@mediaserver.com SIP/2.0 > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > To: MediaServer > From: sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314163 INVITE > Contact: > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 > s=- > c=IN IP4 224.2.17.12 > m=control 9 TCP application/speechsc > a=direction:active > a=resourceId:speechrec > m=control 9 TCP application/speechsc > a=direction:active > a=resourceId:speechsynth > m=audio 49170 RTP/AVP 0 96 > a=rtpmap:0 pcmu/8000 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > a=sendrecv > > S->C: > SIP/2.0 200 OK > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > To: MediaServer > From: sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314163 INVITE > Contact: > Content-Type: application/sdp > Content-Length: 131 > > v=0 > o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 > s=- > c=IN IP4 224.2.17.12 > m=control 32416 TCP application/speechsc > a=direction:passive > a=resourceId:speechrec > a=channelId:32AECB234338 > m=control 32416 TCP application/speechsc > a=channelId:32AECB234339 > a=resourceId:speechsynth > a=direction:passive > m=audio 48260 RTP/AVP 0 96 > a=rtpmap:0 pcmu/8000 > a=rtpmap:96 telephone-event/8000 > a=fmtp:96 0-15 > a=sendrecv > > C->S: > ACK sip:speechsc@mediaserver.com SIP/2.0 > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > To: MediaServer ;tag=a6c85cf > From: Sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314164 ACK > Content-Length: 0 > >Example 3. > C->S: > INVITE sip:mresources@mediaserver.com SIP/2.0 > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > To: MediaServer > From: sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314163 INVITE > Contact: > Content-Type: application/sdp > Content-Length: ... > > v=0 > o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 > s=- > c=IN IP4 224.2.17.12 > m=control 0 TCP application/speechsc > a=direction:active > a=resourceId:speechrec > m=control 9 TCP application/speechsc > a=direction:active > a=resourceId:speechsynth > m=audio 49170 RTP/AVP 0 96 > a=rtpmap:0 pcmu/8000 > a=recvonly > > S->C: > SIP/2.0 200 OK > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > To: MediaServer > From: sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314163 INVITE > Contact: > Content-Type: application/sdp > Content-Length: 131 > > v=0 > o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 > s=- > c=IN IP4 224.2.17.12 > m=control 0 TCP application/speechsc > a=direction:passive > a=resourceId:speechrec > a=channelId:32AECB234338 > m=control 32416 TCP application/speechsc > a=resourceId:speechsynth > a=channelId:32AECB234339 > a=direction:passive > m=audio 48260 RTP/AVP 0 96 > a=rtpmap:0 pcmu/8000 > a=sendonly > > C->S: > ACK sip:speechsc@mediaserver.com SIP/2.0 > Via: SIP/2.0/TCP >client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > To: MediaServer ;tag=a6c85cf > From: Sarvi ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314164 ACK > Content-Length: 0 > >Finally one thing I think the WG needs to be aware of is the proposed >new charter of the mmusic WG. A clear motivation there appears to be to >draw a line under what gets added to SDP as it is today and what would >be waiting for SDP NG. I think a too draconian interpretation of that >proposed charter might present a problem here. (As well as in the SIMPLE >WG). > >hth, >Neil. >-- >http://users.rcn.com/neildeason/ > > > >>-----Original Message----- >>From: speechsc-admin@ietf.org >>[mailto:speechsc-admin@ietf.org] On Behalf Of Sarvi Shanmugham >>Sent: 21 May 2003 14:30 >>To: speechsc@ietf.org >>Subject: [Speechsc] Protpcol proposal for SPEECHSC >> >> >> >> >>Hi >> Please find attached a proposal for a SPEECHSC protocol. This >>leverages the MRCP specification. But removes the tunnelling >>aspects of >>the protocol. I have also submitted this document to the >>internet drafts >>repository and should be available from there soon. >> >>The current version does not address SI and SV aspects of the >>requirements document. But addresses most of the others. This >>document >>is meant to be a starting point for a possible direction that the >>SPEECHSC protocol could take. Based on interest and comments >>received, >>we can proceed to add SI and SV capabilities in a following >>version of >>the draft. >> >>Any thoughts. >> >>Sarvi >> >> >> > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > > --------------030806050600030000020601 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit some comments line.

Neil Deason wrote:
Hi.

I have some comments on the usage of SDP for SPEECHSC part of the draft.


+ I would suggest an alternative format for the 'm=' line. Use a value
for the protocol that designates the underlying transport protocol, this
then allows for TCP, TLS, SCTP to be used with speechsc. For the media
format use the mime type 'application/speechsc'. Then use two SDP
attributes to describe the resource ID and channel ID. An example
written this way would therefore be:

		m=control 32416 TCP application/speechsc
		a=resourceId:speechrec
		a=channelId:32AECB234338
1.  I am fine with using TCP/SCTP/TLS as the transport field of the m-line and specifiying the channel-id/resource-id as an attribute of the m-line. That said, could you explain what we gain between using a transport of SPEECHSC(whisch specifies what transports are supported)  and your suggestion of specifying TCP or SCTP in the transport field of the m-line. My current approach seems similar to examples used where the transport is claimed to be "h323".

2. Channel -id / resource format

Do you see problem with the channel id covering the resource identity and
the channel identity?

I had done it this way, so that we have the option of requesting resource-id
"00" to mean, on demand allocation. This returns a channel-id of  "32AECB23433800"
where 00 means on-demand resource usage. There is no specific resourece that
is being reserved or allocated. 



This then allows an ASR or TTS or SI or SV command to be issued. The just
need to have a channel-id of "32AECB234338XX" where XX is the resource identifier.




It also has the added benefit of figuring out from the chhanel -id what type
of resource is being controlled.



  
+ Section 3.2 refers to setting the offerer setting the port to 0 in the
SDP when it wants to act as the client in the connection setup
procedure. However, setting a port to 0 has a defined meaning that a
stream is offered but must not be used according to RFC3264. This an
area where alignment with draft-ietf-mmusic-sdp-comedia-05.txt could
help. That recommends the offerer use a value of port 9 (the discard
port) in its offer. This work also then defines a SDP attribute to
define the client/server roles to be used in the connection set up
procedure, which could be reused here.



Agreed. I will make the appropriate changes in the next revision.



  

+ Section 3.2 refers to a client removing a 'm=' line from the SDP
description in a session to de-allocate a resource. RFC3264 describes
the mode for removing a media stream as continuing to offer it, but with
the port set to 0.



Agreed. I will make the appropriate changes in the next revision.



  

+ The SDP in Example 1 of the draft would not be legal according to RFC
2327 - the SDP in the INVITE is missing a mandatory 'm=' line. This may
not be a big deal as it was not clear to me why you would have this
preliminary offer/answer prior to establishing the resource control
channel. If there is no clear reason the exchange described in Example 1
would be unnecessary and can be removed.



I was just trying to demonstrate that there could be times in the SIP session
when there is no m-lines becuase there is no resources used or media between
the client and the server. This may most likely happen mid session than at
the beginning. the SIP session may add m-line for the different resources
as need and m-lines for audio as needed by the resource. The client could
allocate and deallocate resources(m-lines) as needed within in the session.
This might mean that there are times,  when the client has released the all
the individual resources but may want to allocate it as part of the session
at a later point. At these points I don't want to have to destroy the whole
SIP session and recreate it.

Anyway, atleast thats what I was trying to do. If this is illegal in SIP,
I will remove it or find an alternative for this.



  

+ Finally a few nits have crept in: The SIP URL used in the contact
header of the examples has an illegal whitespace in it, the SIP messages
are missing Via headers.



I will incorporate these into the next revision.



Thx,

Sarvi



  

I have revised the examples in the draft accordingly below. They could
still use some cleaning up, but hopefully it helps illustrate the above
comments.

(Example 1 deleted - so pervious Example 2 becomes 1 etc.)

Example 1.
   C->S: 
           INVITE sip:mresources@mediaserver.com SIP/2.0 
           Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9 
           Max-Forwards: 70 
           To: MediaServer <sip:mresources@mediaserver.com> 
           From: sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314161 INVITE 
           Contact: <sip:sarvi@cisco.com> 
           Content-Type: application/sdp 
           Content-Length: ...
            
           v=0 
           o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 
           s=- 
           c=IN IP4 224.2.17.12
           m=control 9 TCP application/speechsc
	     a=direction:active 
           a=resourceId:speechsynth
           m=audio 49170 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=recvonly 
     
    S->C: 
           SIP/2.0 200 OK 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           To: MediaServer <sip:mresources@mediaserver.com> 
           From: sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314161 INVITE 
           Contact: <sip:sarvi@cisco.com> 
           Content-Type: application/sdp 
           Content-Length: ... 
            
           v=0 
           o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 
           s=- 
           c=IN IP4 224.2.17.12
           m=control 32416 TCP application/speechsc
	     a=direction:passive
	     a=resourceId:speechsynth
	     a=channelId:32AECB234338 
           m=audio 48260 RTP/AVP 00 96 
           a=rtpmap:0 pcmu/8000 
           a=sendonly 
     
    C->S: 
           ACK sip:speechsc@mediaserver.com SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:speechsc@mediaserver.com>;tag=a6c85cf 
           From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314162 ACK 
           Content-Length: 0 

Example 2.
   C->S: 
           INVITE sip:mresources@mediaserver.com SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:mresources@mediaserver.com> 
           From: sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314163 INVITE 
           Contact: <sip:sarvi@cisco.com> 
           Content-Type: application/sdp 
           Content-Length: ... 
            
           v=0 
           o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 
           s=-
           c=IN IP4 224.2.17.12
           m=control 9 TCP application/speechsc
	     a=direction:active 
	     a=resourceId:speechrec
           m=control 9 TCP application/speechsc
	     a=direction:active 
	     a=resourceId:speechsynth
           m=audio 49170 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=rtpmap:96 telephone-event/8000 
           a=fmtp:96 0-15 
           a=sendrecv 
     
    S->C: 
           SIP/2.0 200 OK 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           To: MediaServer <sip:mresources@mediaserver.com> 
           From: sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314163 INVITE 
           Contact: <sip:sarvi@cisco.com> 
           Content-Type: application/sdp 
           Content-Length: 131 
            
           v=0 
           o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 
           s=-
           c=IN IP4 224.2.17.12
           m=control 32416 TCP application/speechsc
	     a=direction:passive
	     a=resourceId:speechrec
	     a=channelId:32AECB234338
           m=control 32416 TCP application/speechsc
	     a=channelId:32AECB234339
	     a=resourceId:speechsynth
	     a=direction:passive
           m=audio 48260 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=rtpmap:96 telephone-event/8000 
           a=fmtp:96 0-15 
           a=sendrecv 
     
    C->S: 
           ACK sip:speechsc@mediaserver.com SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:speechsc@mediaserver.com>;tag=a6c85cf 
           From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314164 ACK 
           Content-Length: 0 

Example 3.
    C->S: 
           INVITE sip:mresources@mediaserver.com SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:mresources@mediaserver.com> 
           From: sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314163 INVITE 
           Contact: <sip:sarvi@cisco.com> 
           Content-Type: application/sdp 
           Content-Length: ...
            
           v=0 
           o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 
           s=-
           c=IN IP4 224.2.17.12
           m=control 0 TCP application/speechsc
	     a=direction:active
	     a=resourceId:speechrec
           m=control 9 TCP application/speechsc
	     a=direction:active
	     a=resourceId:speechsynth	
           m=audio 49170 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=recvonly 
     
    S->C: 
           SIP/2.0 200 OK 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           To: MediaServer <sip:mresources@mediaserver.com> 
           From: sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314163 INVITE 
           Contact: <sip:sarvi@cisco.com> 
           Content-Type: application/sdp 
           Content-Length: 131 
            
           v=0 
           o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 
           s=-
           c=IN IP4 224.2.17.12
           m=control 0 TCP application/speechsc
	     a=direction:passive
	     a=resourceId:speechrec
	     a=channelId:32AECB234338
           m=control 32416 TCP application/speechsc
	     a=resourceId:speechsynth
	     a=channelId:32AECB234339
	     a=direction:passive
           m=audio 48260 RTP/AVP 0 96 
           a=rtpmap:0 pcmu/8000 
           a=sendonly 
     
    C->S: 
           ACK sip:speechsc@mediaserver.com SIP/2.0 
	     Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
           Max-Forwards: 70 
           To: MediaServer <sip:speechsc@mediaserver.com>;tag=a6c85cf 
           From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774 
           Call-ID: a84b4c76e66710 
           CSeq: 314164 ACK 
           Content-Length: 0 

Finally one thing I think the WG needs to be aware of is the proposed
new charter of the mmusic WG. A clear motivation there appears to be to
draw a line under what gets added to SDP as it is today and what would
be waiting for SDP NG. I think a too draconian interpretation of that
proposed charter might present a problem here. (As well as in the SIMPLE
WG).

hth,
Neil.
--
http://users.rcn.com/neildeason/

  

  

    
-----Original Message-----
From: speechsc-admin@ietf.org
[mailto:speechsc-admin@ietf.org] On Behalf Of Sarvi Shanmugham
Sent: 21 May 2003 14:30
To: speechsc@ietf.org
Subject: [Speechsc] Protpcol proposal for SPEECHSC




Hi
     Please find attached a proposal for a SPEECHSC protocol. This
leverages the MRCP specification. But removes the tunnelling 
aspects of 
the protocol. I have also submitted this document to the 
internet drafts 
repository and should be available from there soon.

The current version does not address SI and SV aspects of the
requirements document. But addresses most of the others. This 
document 
is meant to be a starting point for a possible direction that the 
SPEECHSC protocol could take. Based on interest and comments 
received, 
we can proceed to add SI and SV capabilities in a following 
version of 
the draft.

Any thoughts.

Sarvi

    

  

  

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

  








--------------030806050600030000020601--

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