From speechsc-bounces@ietf.org Wed May 04 11:58:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMGi-0001Es-72; Wed, 04 May 2005 11:58:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMGg-0001EY-SS for speechsc@megatron.ietf.org; Wed, 04 May 2005 11:58:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23867 for ; Wed, 4 May 2005 11:58:30 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMUk-0002WT-WD for speechsc@ietf.org; Wed, 04 May 2005 12:13:08 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j44FwB4I681514 for ; Wed, 4 May 2005 11:58:11 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j44FwBXs252738 for ; Wed, 4 May 2005 09:58:11 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j44FwBa0029962 for ; Wed, 4 May 2005 09:58:11 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j44FwBUd029955 for ; Wed, 4 May 2005 09:58:11 -0600 To: speechsc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 4 May 2005 11:58:10 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/04/2005 09:58:10, Serialize complete at 05/04/2005 09:58:10 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Have there been any MRCPv2 requirements raised to include support for VoiceXML 2.x "inputmodes" property? How would a VoiceXML vendor implement support for the "inputmodes" property utilizing the current MRCPv2 specification, and should this be added as a change request for a future MRCPv2 revision? The definition of VoiceXML 'inputmodes' is as follows: inputmodes This property determines which input modality to use. The input modes to enable: dtmf and voice. On platforms that support both modes, inputmodes defaults to "dtmf voice". To disable speech recognition, set inputmodes to "dtmf". To disable DTMF, set it to "voice". One use for this would be to turn off speech recognition in noisy environments. Another would be to conserve speech recognition resources by turning them off where the input is always expected to be DTMF. This property does not control the activation of grammars. For instance, voice-only grammars may be active when the inputmode is restricted to DTMF. Those grammars would not be matched, however, because the voice input modality is not active. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed May 04 12:16:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMWg-0003Zw-EL; Wed, 04 May 2005 12:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMWZ-0003Xx-TS for speechsc@megatron.ietf.org; Wed, 04 May 2005 12:15:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25184 for ; Wed, 4 May 2005 12:14:57 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMkd-00031D-Dn for speechsc@ietf.org; Wed, 04 May 2005 12:29:32 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 May 2005 09:14:47 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j44GEeb4001090; Wed, 4 May 2005 09:14:40 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Wed, 4 May 2005 09:15:53 -0700 Message-ID: <6677B3346233B94EBB11C060935101200AFD4C0B@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Thread-Index: AcVQwoW/GwTy+XRAR0SXpNjFpD4GXAAAEIqg From: "Shanmugham, Saravanan" To: "Brett Gavagni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Each recongize that specify which grammars should be active for the RECOGNIZE. So, can this not be achieved by choosing which grammars to activate?=20 I do see that there is one issue though, that the current spec is defined in a way the client may not have to parse the grammar content at all. An this would mean that the client would have to parse atleast the initial portion of the grammar doucment to figure if the mode is DTMF or not. I don't see any issue in adding support for a header field that specifies this option for the RECOGNIZE method. Anyone opposed to this proposal? Thx, Sarvi PS: This then begs the question regarding the "accept" attribute in VXML 2.1. Which also puts the client in a similar possition, only worse. It has to parse through the entire grammar and construct additional grammars that meet the "accept" criteria. In general the philosohy of MRCP has been to keep much of the grammar and language processing on the server side and keep the client simple. I propose that we add a header to support this as well. But define it in such a way that we leave room for recognition vendors that may not want to support it. -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Wednesday, May 04, 2005 8:58 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes" property =20 Have there been any MRCPv2 requirements raised to include=20 support for VoiceXML 2.x "inputmodes" property?=20 =20 How would a VoiceXML vendor implement support for the "inputmodes"=20 property utilizing the current MRCPv2 specification, and=20 should this be added as a change request for a future=20 MRCPv2 revision? =20 The definition of VoiceXML 'inputmodes' is as follows: =20 inputmodes This property determines which input modality to use. The=20 input modes to enable: dtmf and voice. On platforms that support both=20 modes, inputmodes defaults to "dtmf voice". To disable=20 speech recognition, set inputmodes to "dtmf". To disable=20 DTMF, set it to "voice". One use for this would be to turn=20 off speech recognition in noisy environments. Another=20 would be to conserve speech recognition resources by=20 turning them off where the input is always expected to be=20 DTMF. This property does not control the activation of=20 grammars. For instance, voice-only grammars may be active=20 when the inputmode is restricted to DTMF. Those grammars=20 would not be matched, however, because the voice input=20 modality is not active.=20 =20 =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =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 From speechsc-bounces@ietf.org Wed May 04 12:26:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMha-0002IG-4v; Wed, 04 May 2005 12:26:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMhV-0002I8-Qp for speechsc@megatron.ietf.org; Wed, 04 May 2005 12:26:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26465 for ; Wed, 4 May 2005 12:26:14 -0400 (EDT) Received: from vesicle.nsi.edu ([204.128.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMvd-0003N8-1s for speechsc@ietf.org; Wed, 04 May 2005 12:40:53 -0400 Received: from vesicle.nsi.edu (localhost [127.0.0.1]) by vesicle.nsi.edu (8.12.9/8.12.9) with ESMTP id j44GQ3us004621; Wed, 4 May 2005 09:26:03 -0700 Received: (from apache@localhost) by vesicle.nsi.edu (8.12.9/8.12.3/Submit) id j44GQ3tV004620; Wed, 4 May 2005 09:26:03 -0700 X-Authentication-Warning: vesicle.nsi.edu: apache set sender to gal@nsi.edu using -f Received: from 198.133.185.118 (SquirrelMail authenticated user gal) by vesicle.nsi.edu with HTTP; Wed, 4 May 2005 09:26:03 -0700 (PDT) Message-ID: <33057.198.133.185.118.1115223963.squirrel@vesicle.nsi.edu> In-Reply-To: References: Date: Wed, 4 May 2005 09:26:03 -0700 (PDT) Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property From: "Thomas S Gal" To: "Brett Gavagni" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 8bit Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tgal@nsi.edu List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org That seems like a vendor optimization. Also especially since you state that this property DOES NOT affect input grammars, what's the point? You could just use an SRGS grammar with/without the appropriate functionality, and there's certainly no parameters for background noise or noise in any sense, along with all of the other situations in which this would be useful. In my opinion this functionality is already there and in no way limited or constrained by MRCP. -Tom tgal@nsi.edu > Have there been any MRCPv2 requirements raised to include support for > VoiceXML 2.x "inputmodes" property? > > How would a VoiceXML vendor implement support for the "inputmodes" > property utilizing the current MRCPv2 specification, and should this be > added as a change request for a future MRCPv2 revision? > > The definition of VoiceXML 'inputmodes' is as follows: > > inputmodes > This property determines which input modality to use. The input modes to > enable: dtmf and voice. On platforms that support both modes, inputmodes > defaults to "dtmf voice". To disable speech recognition, set inputmodes to > "dtmf". To disable DTMF, set it to "voice". One use for this would be to > turn off speech recognition in noisy environments. Another would be to > conserve speech recognition resources by turning them off where the input > is always expected to be DTMF. This property does not control the > activation of grammars. For instance, voice-only grammars may be active > when the inputmode is restricted to DTMF. Those grammars would not be > matched, however, because the voice input modality is not active. > > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > _______________________________________________ > 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 speechsc-bounces@ietf.org Wed May 04 12:31:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMmC-0003LL-Ae; Wed, 04 May 2005 12:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMmB-0003LD-16 for speechsc@megatron.ietf.org; Wed, 04 May 2005 12:31:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26768 for ; Wed, 4 May 2005 12:31:04 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTN0G-0003UH-Js for speechsc@ietf.org; Wed, 04 May 2005 12:45:43 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 04 May 2005 09:30:55 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j44GUnpT029922; Wed, 4 May 2005 09:30:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Date: Wed, 4 May 2005 09:32:08 -0700 Message-ID: <6677B3346233B94EBB11C060935101200AFD4C40@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Thread-Index: AcVQxk9LEFt5fZIHSEGOquDyYJSjkgAABbNg From: "Shanmugham, Saravanan" To: , "Brett Gavagni" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org It then begs the question, why does VXML have this feils? And what do you suggest a VXML browser developer, that depends on MRCP behind it, do to meet the needs of this header. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Thomas S Gal Sent: Wednesday, May 04, 2005 9:26 AM To: Brett Gavagni Cc: speechsc@ietf.org Subject: Re: [Speechsc] MRCPv2 requirements for VoiceXML=20 "inputmodes" property =20 That seems like a vendor optimization. Also especially=20 since you state that this property DOES NOT affect input=20 grammars, what's the point? You could just use an SRGS=20 grammar with/without the appropriate functionality, and=20 there's certainly no parameters for background noise or=20 noise in any sense, along with all of the other situations=20 in which this would be useful. In my opinion this=20 functionality is already there and in no way limited or=20 constrained by MRCP. =20 -Tom tgal@nsi.edu =20 > Have there been any MRCPv2 requirements raised to=20 include support for=20 > VoiceXML 2.x "inputmodes" property? > > How would a VoiceXML vendor implement support for the=20 "inputmodes" > property utilizing the current MRCPv2 specification, and=20 should this=20 > be added as a change request for a future MRCPv2 revision? > > The definition of VoiceXML 'inputmodes' is as follows: > > inputmodes > This property determines which input modality to use.=20 The input modes=20 > to > enable: dtmf and voice. On platforms that support both modes,=20 > inputmodes defaults to "dtmf voice". To disable speech=20 recognition,=20 > set inputmodes to "dtmf". To disable DTMF, set it to=20 "voice". One use=20 > for this would be to turn off speech recognition in noisy=20 > environments. Another would be to conserve speech recognition=20 > resources by turning them off where the input is always=20 expected to be=20 > DTMF. This property does not control the activation of=20 grammars. For=20 > instance, voice-only grammars may be active when the=20 inputmode is=20 > restricted to DTMF. Those grammars would not be matched,=20 however, because the voice input modality is not active. > > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > =20 =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 From speechsc-bounces@ietf.org Wed May 04 12:33:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMo3-0003zq-Lb; Wed, 04 May 2005 12:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMo2-0003z5-AK for speechsc@megatron.ietf.org; Wed, 04 May 2005 12:33:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26991 for ; Wed, 4 May 2005 12:32:59 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTN29-0003XS-ES for speechsc@ietf.org; Wed, 04 May 2005 12:47:38 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 04 May 2005 09:32:52 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j44GWlb4009151; Wed, 4 May 2005 09:32:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Date: Wed, 4 May 2005 09:33:59 -0700 Message-ID: <6677B3346233B94EBB11C060935101200AFD4C45@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Thread-Index: AcVM87kZq1uaMLTCQLep0os1wqrnRwD0vOxw From: "Shanmugham, Saravanan" To: "Brett Gavagni" , "Thomas Gal" X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Reifenrath, Klaus" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Could you propose exact text as to how you like to modify and clarify the use of this field. If that works for most others, I will update the specfication. Thanks, Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Friday, April 29, 2005 12:40 PM To: Thomas Gal Cc: speechsc@ietf.org; 'Reifenrath, Klaus' Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition=20 clarification =20 I'll re-iterate the objection; if a client wants the=20 recognition to last for a timeout, then it should be able=20 to specify this condition.=20 =20 The current wording in the specification doesn't clearly=20 indicate that a client request to START-INPUT-TIMERS is=20 invalid for Recognition-Mode:=20 hotword. =20 The Recognizer State Machine should be clearly documented=20 for both distinct recognition mode if the interpretation=20 is expected to be inconsistent. =20 Inconsistency usually add to the challenge of implementing=20 a specification and facilitating interoperability. =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 "Thomas Gal" 04/29/2005 02:58 PM =20 To Brett Gavagni/West Palm Beach/IBM@IBMUS, "'Reifenrath, Klaus'"=20 cc Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification =20 =20 =20 =20 =20 =20 Hotword mode recognition is specifically=20 the case where there's no timeout and you want to be=20 actively listening. I don't really see any problem. But to=20 be pragmatic...... =20 Obviously in the case where there is a=20 limit to the time frame in which the client will want that=20 recognition to occur, they can then send a CANCEL which as=20 you point out may leave holes if there are faulty clients. This doesn't prevent the server from having it's own set=20 of limits for such things, which should obviously be set=20 in the context of the application.=20 Now I wouldn't have a problem with a special hotword mode=20 timeout parameter (or just honoring the other timeout=20 values) to help in that case, but I also don't see why=20 that can't just be an implementation dependant parameter=20 that doesn't need to be specified or investigated in this=20 protocol. Chances are any services/products sold using=20 this protocol will be based on per-port licensing or some=20 other metric which will assure that it's in the best=20 interest of the user to not be wasting recognition=20 resources, as speech recognition is hardware intensive=20 already. The fact remains that having any sort of real=20 timeout value which limits the recognition scope to=20 something short of the complete "speech transaction" (lets=20 say phone call or whatever) makes it become just a regular old recognition and=20 specifically NOT HOTWORD mode recognition as people define it. =20 Personally I agree with Klaus that timeout values should=20 be errors in the context of Hotword recognitions. =20 -Tom =20 =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Friday, April 29, 2005 11:02 AM To: Reifenrath, Klaus Cc: speechsc@ietf.org Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition=20 clarification =20 The following statement is a bit convoluted in the current=20 draft specification w.r.t. hotword mode. =20 "It does not timeout nor generate a no-match and will complete=20 only for a successful match of grammar."=20 =20 The current draft specification doesn't detail that the=20 timeout headers are invalid for a RECOGNIZE request with=20 Recognition-Mode: hotword. =20 What would justify a server not honoring timeouts if a=20 client has the ability to specify timeout values?=20 =20 The hotword statement listed above also raises concerns in=20 terms of a server providing a robust implementation. An=20 implementing server would have to entirely rely on a=20 client to terminate a recognition request where=20 =20 a hotword isn't matched. The complete reliance on a client=20 has a whole separate set of issues for a server to=20 facilitate redundancy. =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 "Reifenrath, Klaus" 04/28/2005 09:59 AM =20 To Brett Gavagni/West Palm Beach/IBM@IBMUS cc speechsc@ietf.org Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification =20 =20 =20 =20 =20 =20 I think the server should return with status code 402=20 (method not valid in=20 =20 this state). =20 Klaus =20 From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Donnerstag, 28. April 2005 15:39 To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 Hotword Mode Recognition clarification =20 =20 Hi,=20 =20 There's room for interpretation in the following section=20 of the current=20 draft of MRCPv2.=20 =20 p53 of the draft-ietf-speechsc-mrcpv2-06.txt=20 Hotword Mode Recognition=20 Hotword mode is where the recognizer looks for a=20 specific speech=20 grammar or dtmf sequence and ignores speech or DTMF=20 that does not=20 match. It does not timeout nor generate a no-match and=20 will complete=20 only for a successful match of grammar.=20 =20 What response should a server generate for a=20 START-INPUT-TIMERS request,=20 when the current session has a recognition in progress in=20 hotword mode?=20 =20 What would justify a server not honoring timeouts if a=20 client has the=20 ability to specify timeout values?=20 =20 Thanks, =20 Brett Gavagni=20 WebSphere Voice Server Development=20 http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 =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 From speechsc-bounces@ietf.org Wed May 04 12:41:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMvw-0006dA-MK; Wed, 04 May 2005 12:41:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMvv-0006ZS-3H for speechsc@megatron.ietf.org; Wed, 04 May 2005 12:41:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27713 for ; Wed, 4 May 2005 12:41:08 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTNA2-0003jZ-KH for speechsc@ietf.org; Wed, 04 May 2005 12:55:47 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 May 2005 09:25:31 -0700 X-IronPort-AV: i="3.92,154,1112598000"; d="scan'208,217"; a="258769273:sNHT1441151156" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j44GPNi0026082; Wed, 4 May 2005 09:25:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] propose adding "media-type" header field in RECOGNIZEorSET-PARAMS/GET-PARAMS methods Date: Wed, 4 May 2005 09:26:43 -0700 Message-ID: <6677B3346233B94EBB11C060935101200AFD4C2F@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] propose adding "media-type" header field in RECOGNIZEorSET-PARAMS/GET-PARAMS methods Thread-Index: AcVM1EeF6F3QJhBHRniGmUHADY5x4wAA+UewAPsQNVA= From: "Shanmugham, Saravanan" To: "Thomas Gal" , "Jenny Yao \(jyao\)" , X-Spam-Score: 0.4 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1355152975==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1355152975== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C550C6.0EE97934" This is a multi-part message in MIME format. ------_=_NextPart_001_01C550C6.0EE97934 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see why not, considering all this behaviour would apply only if the "Save-Waveform" header is set to true and failure to caoture or save the waveform does not necessarily stop the RECOGNIZE operation itself.=20 =20 Anyone opposed to doing this.=20 =20 Thanks, Sarvi _____ =20 From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Thomas Gal Sent: Friday, April 29, 2005 9:47 AM To: 'Jenny Yao (jyao)'; speechsc@ietf.org Subject: RE: [Speechsc] propose adding "media-type" header field in RECOGNIZEorSET-PARAMS/GET-PARAMS methods =09 =09 Though this information could probably be inferred from the filename extension, If we are going to follow/emulate the RECORD methodology than it should also be available as a MIME body to the RECOGNITION COMPLETE/STOP events as well. Otherwise I agree completely. =20 -Tom =20 =09 _____ =20 From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Jenny Yao (jyao) Sent: Friday, April 29, 2005 8:58 AM To: speechsc@ietf.org Subject: [Speechsc] propose adding "media-type" header field in RECOGNIZE orSET-PARAMS/GET-PARAMS methods =20 =20 =20 VoiceXML 2.1 specifies "recording user utterances while attempting recognition". This can be done through recog-only-header "save-waveform" and "waveform-uri" in MRCP V1 and V2. VoiceXML 2.1 also uses recordutterancetype property to specify the media format of the result recording. However, there is no way in MRCP to pass the required media format to the server. We propose using the "Media-Type" header field, currently defined for the recording resource, in the RECOGNIZE method or the SET-PARAMS/GET-PARAMS methods to specify a media type. The Save-Waveform carries a URI pointing to the audio captured during recognition. The captured audio SHOULD be saved with this media-type. =20 Thanks. =20 Jenny ------_=_NextPart_001_01C550C6.0EE97934 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't see why not, considering all this = behaviour=20 would apply only if the "Save-Waveform" header is set to true and = failure=20 to caoture or save the waveform does not necessarily stop the=20 RECOGNIZE operation itself. 
 
Anyone opposed to doing=20 this. 
 
Thanks,
Sarvi

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Thomas=20 Gal
Sent: Friday, April 29, 2005 9:47 AM
To: = 'Jenny Yao=20 (jyao)'; speechsc@ietf.org
Subject: RE: [Speechsc] propose = adding=20 "media-type" header field in RECOGNIZEorSET-PARAMS/GET-PARAMS=20 methods

Though this = information could probably be inferred from the filename extension, If = we are=20 going to follow/emulate the RECORD methodology than it should also be=20 available as a MIME body to the RECOGNITION COMPLETE/STOP events as = well.=20 Otherwise I agree completely.

 

-Tom

 

From:=20 speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Jenny Yao = (jyao)
Sent: Friday, April 29, 2005 = 8:58=20 AM
To:=20 speechsc@ietf.org
Subject:=20 [Speechsc] propose adding "media-type" header field in RECOGNIZE=20 orSET-PARAMS/GET-PARAMS methods

 

 

 

VoiceXML = 2.1 specifies=20 "recording user utterances while attempting recognition". This can be = done=20 through recog-only-header "save-waveform" and "waveform-uri" in MRCP = V1 and=20 V2. VoiceXML 2.1 also uses recordutterancetype property = to specify=20 the media format of the result recording. However, there is = no way=20 in MRCP to pass the required media format to the = server. We=20 propose using the "Media-Type" header field, currently = defined for=20 the recording resource, in the RECOGNIZE method or the = SET-PARAMS/GET-PARAMS=20 methods to specify a media type. The Save-Waveform = carries a=20 URI pointing to the audio captured during recognition. The captured=20 audio SHOULD be saved with this media-type.

 

Thanks.

 

Jenny

= ------_=_NextPart_001_01C550C6.0EE97934-- --===============1355152975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1355152975==-- From speechsc-bounces@ietf.org Wed May 04 14:26:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOaG-0000WM-Eg; Wed, 04 May 2005 14:26:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOaF-0000Vn-9U for speechsc@megatron.ietf.org; Wed, 04 May 2005 14:26:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11290 for ; Wed, 4 May 2005 14:26:51 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOoJ-0007aw-Bg for speechsc@ietf.org; Wed, 04 May 2005 14:41:30 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j44IQY4I052286 for ; Wed, 4 May 2005 14:26:35 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j44IQYmf299212 for ; Wed, 4 May 2005 12:26:34 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j44IQAka009101 for ; Wed, 4 May 2005 12:26:10 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j44IQAHM008923 for ; Wed, 4 May 2005 12:26:10 -0600 In-Reply-To: <6677B3346233B94EBB11C060935101200AFD4C45@vtg-um-e2k1.sj21ad.cisco.com> To: "Shanmugham, Saravanan" MIME-Version: 1.0 Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 4 May 2005 14:26:03 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/04/2005 12:26:09, Serialize complete at 05/04/2005 12:26:09 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: speechsc@ietf.org, "Reifenrath, Klaus" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi, VoiceXML vendors utilizing MRCP for speech resources are dependent on "Recognition-Mode: hotword" to support VoiceXML's "bargeintype=hotword". It would be consistent to have a MRCP server terminate a recognition request (RECOGNITION-COMPLETE) in the case of a timer that is triggered for a "no-input" or "recognition-timeout" in either recognition modes. It would appear inconsistent for a MRCP server to provide timer capability for a "Recognition-Mode: normal" mode ("non-bargein" or a "speech bargein"), and require a VoiceXML vendor to implement their own timers for "Recognition-Mode: hotword". Preferred Proposal: In the case where a MRCP client does not want any timers enabled, the client can specify a long value for the specific timer to be disabled (ie. -1 or some other token). Alternative Proposal: Clarification on the behavior of the recognition timers for both recognition modes would be greatly appreciated, including the clarification of the Recognizer State Machine requirement of generating an error response on START-INPUT-TIMERS when "Recognition-Mode: hotword". Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" 05/04/2005 12:33 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS, "Thomas Gal" cc , "Reifenrath, Klaus" Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Could you propose exact text as to how you like to modify and clarify the use of this field. If that works for most others, I will update the specfication. Thanks, Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Friday, April 29, 2005 12:40 PM To: Thomas Gal Cc: speechsc@ietf.org; 'Reifenrath, Klaus' Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification I'll re-iterate the objection; if a client wants the recognition to last for a timeout, then it should be able to specify this condition. The current wording in the specification doesn't clearly indicate that a client request to START-INPUT-TIMERS is invalid for Recognition-Mode: hotword. The Recognizer State Machine should be clearly documented for both distinct recognition mode if the interpretation is expected to be inconsistent. Inconsistency usually add to the challenge of implementing a specification and facilitating interoperability. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Thomas Gal" 04/29/2005 02:58 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS, "'Reifenrath, Klaus'" cc Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Hotword mode recognition is specifically the case where there's no timeout and you want to be actively listening. I don't really see any problem. But to be pragmatic...... Obviously in the case where there is a limit to the time frame in which the client will want that recognition to occur, they can then send a CANCEL which as you point out may leave holes if there are faulty clients. This doesn't prevent the server from having it's own set of limits for such things, which should obviously be set in the context of the application. Now I wouldn't have a problem with a special hotword mode timeout parameter (or just honoring the other timeout values) to help in that case, but I also don't see why that can't just be an implementation dependant parameter that doesn't need to be specified or investigated in this protocol. Chances are any services/products sold using this protocol will be based on per-port licensing or some other metric which will assure that it's in the best interest of the user to not be wasting recognition resources, as speech recognition is hardware intensive already. The fact remains that having any sort of real timeout value which limits the recognition scope to something short of the complete "speech transaction" (lets say phone call or whatever) makes it become just a regular old recognition and specifically NOT HOTWORD mode recognition as people define it. Personally I agree with Klaus that timeout values should be errors in the context of Hotword recognitions. -Tom -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Friday, April 29, 2005 11:02 AM To: Reifenrath, Klaus Cc: speechsc@ietf.org Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification The following statement is a bit convoluted in the current draft specification w.r.t. hotword mode. "It does not timeout nor generate a no-match and will complete only for a successful match of grammar." The current draft specification doesn't detail that the timeout headers are invalid for a RECOGNIZE request with Recognition-Mode: hotword. What would justify a server not honoring timeouts if a client has the ability to specify timeout values? The hotword statement listed above also raises concerns in terms of a server providing a robust implementation. An implementing server would have to entirely rely on a client to terminate a recognition request where a hotword isn't matched. The complete reliance on a client has a whole separate set of issues for a server to facilitate redundancy. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Reifenrath, Klaus" 04/28/2005 09:59 AM To Brett Gavagni/West Palm Beach/IBM@IBMUS cc speechsc@ietf.org Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification I think the server should return with status code 402 (method not valid in this state). Klaus From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Donnerstag, 28. April 2005 15:39 To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Hi, There's room for interpretation in the following section of the current draft of MRCPv2. p53 of the draft-ietf-speechsc-mrcpv2-06.txt Hotword Mode Recognition Hotword mode is where the recognizer looks for a specific speech grammar or dtmf sequence and ignores speech or DTMF that does not match. It does not timeout nor generate a no-match and will complete only for a successful match of grammar. What response should a server generate for a START-INPUT-TIMERS request, when the current session has a recognition in progress in hotword mode? What would justify a server not honoring timeouts if a client has the ability to specify timeout values? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ 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 speechsc-bounces@ietf.org Wed May 04 14:42:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOoq-0005Nj-8Z; Wed, 04 May 2005 14:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTOop-0005Ne-2Y for speechsc@megatron.ietf.org; Wed, 04 May 2005 14:41:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13041 for ; Wed, 4 May 2005 14:41:55 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTP2u-00083d-JY for speechsc@ietf.org; Wed, 04 May 2005 14:56:34 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j44Ifdua320018 for ; Wed, 4 May 2005 14:41:39 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j44Ifdmf368386 for ; Wed, 4 May 2005 12:41:39 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j44Ifd7L020661 for ; Wed, 4 May 2005 12:41:39 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j44Ifdd1020642 for ; Wed, 4 May 2005 12:41:39 -0600 In-Reply-To: <6677B3346233B94EBB11C060935101200AFD4C0B@vtg-um-e2k1.sj21ad.cisco.com> To: "Shanmugham, Saravanan" MIME-Version: 1.0 Subject: RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 4 May 2005 14:41:38 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 05/04/2005 12:41:39, Serialize complete at 05/04/2005 12:41:39 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi Sarvi, I agree with your proposal. You were following exactly where I was going with this point. Another potentially useful addition to the specification, for a MRCP server to specify the grammar mode in the response to a DEFINE-GRAMMAR request. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" 05/04/2005 12:15 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS, cc Subject RE: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Each recongize that specify which grammars should be active for the RECOGNIZE. So, can this not be achieved by choosing which grammars to activate? I do see that there is one issue though, that the current spec is defined in a way the client may not have to parse the grammar content at all. An this would mean that the client would have to parse atleast the initial portion of the grammar doucment to figure if the mode is DTMF or not. I don't see any issue in adding support for a header field that specifies this option for the RECOGNIZE method. Anyone opposed to this proposal? Thx, Sarvi PS: This then begs the question regarding the "accept" attribute in VXML 2.1. Which also puts the client in a similar possition, only worse. It has to parse through the entire grammar and construct additional grammars that meet the "accept" criteria. In general the philosohy of MRCP has been to keep much of the grammar and language processing on the server side and keep the client simple. I propose that we add a header to support this as well. But define it in such a way that we leave room for recognition vendors that may not want to support it. -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Wednesday, May 04, 2005 8:58 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 requirements for VoiceXML "inputmodes" property Have there been any MRCPv2 requirements raised to include support for VoiceXML 2.x "inputmodes" property? How would a VoiceXML vendor implement support for the "inputmodes" property utilizing the current MRCPv2 specification, and should this be added as a change request for a future MRCPv2 revision? The definition of VoiceXML 'inputmodes' is as follows: inputmodes This property determines which input modality to use. The input modes to enable: dtmf and voice. On platforms that support both modes, inputmodes defaults to "dtmf voice". To disable speech recognition, set inputmodes to "dtmf". To disable DTMF, set it to "voice". One use for this would be to turn off speech recognition in noisy environments. Another would be to conserve speech recognition resources by turning them off where the input is always expected to be DTMF. This property does not control the activation of grammars. For instance, voice-only grammars may be active when the inputmode is restricted to DTMF. Those grammars would not be matched, however, because the voice input modality is not active. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ 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 speechsc-bounces@ietf.org Mon May 09 15:55:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVELg-0003bF-8Y; Mon, 09 May 2005 15:55:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVELc-0003Zk-Gz; Mon, 09 May 2005 15:55:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26468; Mon, 9 May 2005 15:55:22 -0400 (EDT) Message-Id: <200505091955.PAA26468@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 09 May 2005 15:55:22 -0400 Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-06.txt X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : Requirements for Distributed Control of ASR, SI/SV and TTS Resources Author(s) : D. Oran Filename : draft-ietf-speechsc-reqts-06.txt Pages : 18 Date : 2005-5-9 This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition - which includes both speaker identification (SI) and speaker verification (SV) - and text-to- speech (TTS). Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speechsc-reqts-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speechsc-reqts-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-9160040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-reqts-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-reqts-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-9160040.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --NextPart-- From speechsc-bounces@ietf.org Tue May 10 21:25:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVfya-0000D1-Mv; Tue, 10 May 2005 21:25:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVfyY-0000Cs-S9 for speechsc@megatron.ietf.org; Tue, 10 May 2005 21:25:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10943 for ; Tue, 10 May 2005 21:25:24 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVgDx-0004bz-PB for speechsc@ietf.org; Tue, 10 May 2005 21:41:23 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j4B1Jmok001812 for ; Tue, 10 May 2005 21:19:48 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 May 2005 21:15:18 -0400 Message-ID: From: Eric Burger To: "IETF SPEECHSC (speechsc@ietf.org)" Date: Tue, 10 May 2005 21:15:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Speechsc] Off topic - Of interest, but NO FOLLOW-UP ON THIS LIST X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org ScanSoft and Nuance (hereby known as Nuance) http://biz.yahoo.com/e/050510/ssft8-k.html _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed May 11 15:50:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxDd-0002Lz-7R; Wed, 11 May 2005 15:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxDY-0002L6-HL; Wed, 11 May 2005 15:50:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13838; Wed, 11 May 2005 15:50:02 -0400 (EDT) Message-Id: <200505111950.PAA13838@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 11 May 2005 15:50:02 -0400 Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-07.txt X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : Requirements for Distributed Control of ASR, SI/SV and TTS Resources Author(s) : D. Oran Filename : draft-ietf-speechsc-reqts-07.txt Pages : 20 Date : 2005-5-11 This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition - which includes both speaker identification (SI) and speaker verification (SV) - and text-to- speech (TTS). Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speechsc-reqts-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speechsc-reqts-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-11160308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-reqts-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-reqts-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-11160308.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --NextPart-- From speechsc-bounces@ietf.org Mon May 16 12:30:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXiUC-00055D-55; Mon, 16 May 2005 12:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXiU4-00053Z-H1 for speechsc@megatron.ietf.org; Mon, 16 May 2005 12:30:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06259 for ; Mon, 16 May 2005 12:30:19 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXiWe-0000qi-Sh for speechsc@ietf.org; Mon, 16 May 2005 12:33:10 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j4GG3Qki028161; Mon, 16 May 2005 12:03:27 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 May 2005 11:58:53 -0400 Message-ID: From: Eric Burger To: "Shanmugham, Saravanan" , "Jenny Yao (jyao)" Subject: RE: [Speechsc] propose adding "media-type" header field in RECOGN IZEorSET-PARAMS/GET-PARAMS methods Date: Mon, 16 May 2005 11:58:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I really, really, really subscribe to "say what you mean." That is, have a media-type header. It is something sorely missing from VoiceXML 2.x. For example, what is the media type of ".DAT"? What is the media type, for that matter, of ".WAV" -- right, go ahead, open the file and read the header... ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Wednesday, May 04, 2005 12:27 PM To: Thomas Gal; Jenny Yao (jyao); speechsc@ietf.org Subject: RE: [Speechsc] propose adding "media-type" header field in RECOGNIZEorSET-PARAMS/GET-PARAMS methods I don't see why not, considering all this behaviour would apply only if the "Save-Waveform" header is set to true and failure to caoture or save the waveform does not necessarily stop the RECOGNIZE operation itself. Anyone opposed to doing this. Thanks, Sarvi ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Thomas Gal Sent: Friday, April 29, 2005 9:47 AM To: 'Jenny Yao (jyao)'; speechsc@ietf.org Subject: RE: [Speechsc] propose adding "media-type" header field in RECOGNIZEorSET-PARAMS/GET-PARAMS methods Though this information could probably be inferred from the filename extension, If we are going to follow/emulate the RECORD methodology than it should also be available as a MIME body to the RECOGNITION COMPLETE/STOP events as well. Otherwise I agree completely. -Tom ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Jenny Yao (jyao) Sent: Friday, April 29, 2005 8:58 AM To: speechsc@ietf.org Subject: [Speechsc] propose adding "media-type" header field in RECOGNIZE orSET-PARAMS/GET-PARAMS methods VoiceXML 2.1 specifies "recording user utterances while attempting recognition". This can be done through recog-only-header "save-waveform" and "waveform-uri" in MRCP V1 and V2. VoiceXML 2.1 also uses recordutterancetype property to specify the media format of the result recording. However, there is no way in MRCP to pass the required media format to the server. We propose using the "Media-Type" header field, currently defined for the recording resource, in the RECOGNIZE method or the SET-PARAMS/GET-PARAMS methods to specify a media type. The Save-Waveform carries a URI pointing to the audio captured during recognition. The captured audio SHOULD be saved with this media-type. Thanks. Jenny _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue May 17 04:30:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXxSy-00077N-CW; Tue, 17 May 2005 04:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXxSw-00077I-0d for speechsc@megatron.ietf.org; Tue, 17 May 2005 04:30:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22754 for ; Tue, 17 May 2005 04:30:11 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXxjc-0006sO-Kf for speechsc@ietf.org; Tue, 17 May 2005 04:47:29 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j4H8Q89S001435 for ; Tue, 17 May 2005 04:26:08 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 May 2005 04:21:35 -0400 Message-ID: From: Eric Burger To: speechsc@ietf.org Date: Tue, 17 May 2005 04:21:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Speechsc] Contiguous Request-ID's X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Section 5.1, Request: Why must request-id's be contiguous? Monotonically increasing makes sense. Do we have a mechanism for handling out-of-order requests? However, contiguous request-id's imply some mechanism for dealing with missing requests, which I don't think we have. I would either fill-in the mechanisms (with justification for the complexity) or relax the requirements appropriately. Either: 1. Keep contiguous (incrementing by 1). Explain why. Explain mechanisms for handling missing and out-of-order requests. 2. Keep monotonically increasing. Explain mechanisms for handling out-of-order requests. 3. Keep unique. I vote for #3, unless there are use cases for ordering requests that arrive over reliable, ordered transports (TCP, SCTP-Connection-Mode). _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue May 17 09:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY2WF-0007H2-Dc; Tue, 17 May 2005 09:53:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY2WD-0007GS-LF for speechsc@megatron.ietf.org; Tue, 17 May 2005 09:53:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24892 for ; Tue, 17 May 2005 09:53:55 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY2my-0008NQ-Jp for speechsc@ietf.org; Tue, 17 May 2005 10:11:17 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 17 May 2005 06:53:48 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4HDrjrA011370; Tue, 17 May 2005 06:53:45 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Contiguous Request-ID's Date: Tue, 17 May 2005 06:55:14 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B31EBBF@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Contiguous Request-ID's Thread-Index: AcVau0KUmD32T668SwORs4jEtBIdYwALAuvQ From: "Shanmugham, Saravanan" To: "Eric Burger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I don't mind rmoving these restrictions. But I don't see what this change gets us or avoids. Is there anything specific you are trying address here. If not, I would be inclined to leave it as is.=20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, May 17, 2005 1:21 AM To: speechsc@ietf.org Subject: [Speechsc] Contiguous Request-ID's =20 Section 5.1, Request: Why must request-id's be contiguous? Monotonically=20 increasing makes sense. Do we have a mechanism for handling out-of-order requests?=20 However, contiguous request-id's imply some mechanism for=20 dealing with missing requests, which I don't think we=20 have. I would either fill-in the mechanisms (with=20 justification for the complexity) or relax the=20 requirements appropriately. Either: =20 1. Keep contiguous (incrementing by 1). Explain why. =20 Explain mechanisms for handling missing and out-of-order requests. =20 2. Keep monotonically increasing. Explain mechanisms for=20 handling out-of-order requests. =20 3. Keep unique. =20 I vote for #3, unless there are use cases for ordering=20 requests that arrive over reliable, ordered transports=20 (TCP, SCTP-Connection-Mode). =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 From speechsc-bounces@ietf.org Tue May 17 17:19:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY9TV-0002Bq-1l; Tue, 17 May 2005 17:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY9TT-0002B6-Ig for speechsc@megatron.ietf.org; Tue, 17 May 2005 17:19:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21419 for ; Tue, 17 May 2005 17:19:32 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY9kD-0003UK-Ty for speechsc@ietf.org; Tue, 17 May 2005 17:36:58 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j4HL5aGx028956; Tue, 17 May 2005 17:05:36 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 May 2005 17:01:03 -0400 Message-ID: From: Eric Burger To: "Shanmugham, Saravanan" Subject: RE: [Speechsc] Contiguous Request-ID's Date: Tue, 17 May 2005 17:00:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Consider what happens if there is wording in the spec that says Request-ID's MUST be contiguous. Let us say a server receives an out-of-order Request-ID. Moreover, the spec remains silent on what to do. I can imagine that some servers will happily accept the request. They "know" that there really is not a requirement for contiguous Request-ID's. It doesn't matter. I can imagine that other servers, especially those written by folks that were not involved in this conversation, that will reject the request. The spec says Request-ID's MUST be contiguous, and clearly something very bad has happened -- a message got lost over a reliable transport connection. Now things get even more interesting. Since something 'very bad' happened, and the spec is silent, some servers will reject the request, while others will tear down the entire MRCPv2 session. Others may kill all MRCPv2 sessions with that server. The point is that if we don't specify actions, we will get incompatible implementations. > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Tuesday, May 17, 2005 9:55 AM > To: Eric Burger; speechsc@ietf.org > Subject: RE: [Speechsc] Contiguous Request-ID's > > I don't mind rmoving these restrictions. But I don't see what > this change gets us or avoids. Is there anything specific you > are trying address here. If not, I would be inclined to leave > it as is. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger > Sent: Tuesday, May 17, 2005 1:21 AM > To: speechsc@ietf.org > Subject: [Speechsc] Contiguous Request-ID's > > Section 5.1, Request: > Why must request-id's be contiguous? Monotonically > increasing makes sense. > Do we have a mechanism for handling out-of-order requests? > However, contiguous request-id's imply some mechanism for > dealing with missing requests, which I don't think we > have. I would either fill-in the mechanisms (with > justification for the complexity) or relax the > requirements appropriately. Either: > > 1. Keep contiguous (incrementing by 1). Explain why. > Explain mechanisms for handling missing and out-of-order > requests. > > 2. Keep monotonically increasing. Explain mechanisms for > handling out-of-order requests. > > 3. Keep unique. > > I vote for #3, unless there are use cases for ordering > requests that arrive over reliable, ordered transports > (TCP, SCTP-Connection-Mode). > > _______________________________________________ > 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 speechsc-bounces@ietf.org Tue May 17 17:25:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY9Yn-0003Zx-LS; Tue, 17 May 2005 17:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY9Ym-0003Zr-K4 for speechsc@megatron.ietf.org; Tue, 17 May 2005 17:25:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21823 for ; Tue, 17 May 2005 17:25:01 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY9pZ-0003mG-SO for speechsc@ietf.org; Tue, 17 May 2005 17:42:27 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j4HLKuGx000181 for ; Tue, 17 May 2005 17:20:56 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 May 2005 17:16:23 -0400 Message-ID: From: Eric Burger To: speechsc@ietf.org Date: Tue, 17 May 2005 17:16:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Speechsc] Version header in responses X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org The current text (Section 5.2) states that the response to a request MUST have the same version header as the request. Why? If we have a version header at all, shouldn't it convey the actual version of the server? Clearly, the server understands the client if it generates a response at all. Moreover, the client can then chose if the server is of the 'right' version to do the transaction. Conversely, I would offer that if we can deal with this loss of information (the actual server version), then the version header itself is redundant and should be dropped from the specification. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue May 17 20:06:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYC4g-0001Lt-UD; Tue, 17 May 2005 20:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYC4f-0001Lg-75 for speechsc@megatron.ietf.org; Tue, 17 May 2005 20:06:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05733 for ; Tue, 17 May 2005 20:06:07 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYCLU-0004Ec-OQ for speechsc@ietf.org; Tue, 17 May 2005 20:23:34 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 17 May 2005 17:05:58 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4I05trA019113; Tue, 17 May 2005 17:05:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Version header in responses Date: Tue, 17 May 2005 17:07:25 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B31F2D1@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Version header in responses Thread-Index: AcVbJzjKCp2LZRp2TNyD5BUB9TDbYAAElP7Q From: "Shanmugham, Saravanan" To: "Eric Burger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I believe what the text intended to mean was that the version string sent by the client in the request MUST match the version string sent by the server in the response for the 2 entities to fully understand each other. It does not mean that the server MUST respond with the same exact string sent by the client. It just means that they MUST match for them to completely understand each other. We can clarify this in the text. Thanks, Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, May 17, 2005 2:16 PM To: speechsc@ietf.org Subject: [Speechsc] Version header in responses =20 The current text (Section 5.2) states that the response to=20 a request MUST have the same version header as the request. =20 Why? If we have a version header at all, shouldn't it=20 convey the actual version of the server? Clearly, the=20 server understands the client if it generates a response=20 at all. Moreover, the client can then chose if the server=20 is of the 'right' version to do the transaction. =20 Conversely, I would offer that if we can deal with this=20 loss of information (the actual server version), then the=20 version header itself is redundant and should be dropped=20 from the specification. =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 From speechsc-bounces@ietf.org Wed May 18 04:46:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYKCX-0005Od-BW; Wed, 18 May 2005 04:46:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYKCV-0005NT-0R for speechsc@megatron.ietf.org; Wed, 18 May 2005 04:46:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19288 for ; Wed, 18 May 2005 04:46:44 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYKTP-0005pU-QS for speechsc@ietf.org; Wed, 18 May 2005 05:04:16 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 May 2005 01:45:44 -0700 X-IronPort-AV: i="3.93,116,1115017200"; d="scan'208"; a="266621259:sNHT32318904" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4I8jeER029840; Wed, 18 May 2005 01:45:40 -0700 (PDT) Received: from [167.254.254.200] (sjc-vpn5-75.cisco.com [10.21.88.75]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4I8Yv3q000723; Wed, 18 May 2005 01:34:59 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E7C8F96-D71C-4BFC-9CA4-F7CE9254CFDB@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Contiguous Request-ID's Date: Wed, 18 May 2005 00:03:54 -0400 To: Eric Burger X-Mailer: Apple Mail (2.728) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116405301.307965"; x:"432200"; a:"rsa-sha1"; b:"nofws:3378"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"FKYPxd/6/qAjTALxyesTlSEQBLWt3jXRwfdys9Gq5Bbn1302S2Ef7/+GYcKEvsHqmXjvCipE" "WOlg+tFV8WySvZomJedfYrwncD6bOVDVq9nqRLwQ34NjtyTTfSkvSP4nJoRiGmDxQ1+W9Rvpbvk" "GJAGwBxXi5ZpIp27t5M4Cujs="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Contiguous Request-ID's"; c:"Date: Wed, 18 May 2005 00:03:54 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.7 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Shanmugham, Saravanan" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I think the Postel dictum should guide us here which leads me to and to separate transmitter and receiver behavior. Any request-id scheme puts the burden on the receiver to detect duplicates. If there is no ordering requirement on request-ids, then the receiver state needed is O(M), where M is the maximum number of requests that might ever be sent in a session. At the other extreme, requiring contiguous monotonic request sequencing winds up either having startup ambiguity (what is the first request of a session contiguous to?) or also mandating an initial request number (e.g. 1) for a session and opens up all the off-by-one style errors. Specifying monotonic requests tends to be the best compromise - it allows duplicate or misordering-through-transmitter-bug detection with O(1) state at the receiver. Lastly, the size of course needs to be big enough so that you don't need modular arithmetic and window computations for them. So, the above is the long way of saying I think we should do (2), and reject duplicate and out-of-order requests with a well-defined error. Dave. On May 17, 2005, at 5:00 PM, Eric Burger wrote: > Consider what happens if there is wording in the spec that says > Request-ID's > MUST be contiguous. Let us say a server receives an out-of-order > Request-ID. Moreover, the spec remains silent on what to do. > > > I can imagine that some servers will happily accept the request. They > "know" that there really is not a requirement for contiguous > Request-ID's. > It doesn't matter. > > I can imagine that other servers, especially those written by folks > that > were not involved in this conversation, that will reject the > request. The > spec says Request-ID's MUST be contiguous, and clearly something > very bad > has happened -- a message got lost over a reliable transport > connection. > > Now things get even more interesting. Since something 'very bad' > happened, > and the spec is silent, some servers will reject the request, while > others > will tear down the entire MRCPv2 session. Others may kill all MRCPv2 > sessions with that server. > > > The point is that if we don't specify actions, we will get > incompatible > implementations. > > >> -----Original Message----- >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >> Sent: Tuesday, May 17, 2005 9:55 AM >> To: Eric Burger; speechsc@ietf.org >> Subject: RE: [Speechsc] Contiguous Request-ID's >> >> I don't mind rmoving these restrictions. But I don't see what >> this change gets us or avoids. Is there anything specific you >> are trying address here. If not, I would be inclined to leave >> it as is. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger >> Sent: Tuesday, May 17, 2005 1:21 AM >> To: speechsc@ietf.org >> Subject: [Speechsc] Contiguous Request-ID's >> >> Section 5.1, Request: >> Why must request-id's be contiguous? Monotonically >> increasing makes sense. >> Do we have a mechanism for handling out-of-order requests? >> However, contiguous request-id's imply some mechanism for >> dealing with missing requests, which I don't think we >> have. I would either fill-in the mechanisms (with >> justification for the complexity) or relax the >> requirements appropriately. Either: >> >> 1. Keep contiguous (incrementing by 1). Explain why. >> Explain mechanisms for handling missing and out-of-order >> requests. >> >> 2. Keep monotonically increasing. Explain mechanisms for >> handling out-of-order requests. >> >> 3. Keep unique. >> >> I vote for #3, unless there are use cases for ordering >> requests that arrive over reliable, ordered transports >> (TCP, SCTP-Connection-Mode). >> >> _______________________________________________ >> 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 speechsc-bounces@ietf.org Wed May 18 09:40:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOmW-0004gz-MA; Wed, 18 May 2005 09:40:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOmU-0004go-8x for speechsc@megatron.ietf.org; Wed, 18 May 2005 09:40:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20337 for ; Wed, 18 May 2005 09:40:11 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYP3R-0006vS-74 for speechsc@ietf.org; Wed, 18 May 2005 09:57:45 -0400 Received: from postcard.nuance.com ([10.3.6.20]:15302) by letter.nuance.com with esmtp id 1DYOmF-0003Ql-Av for speechsc@ietf.org; Wed, 18 May 2005 06:39:59 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 May 2005 09:39:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 May 2005 09:38:59 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802B97E58@mtb1exch01.nuance.com> Thread-Topic: Questions about MRCPv2 transport protocols Thread-Index: AcVbrvI46dR/tZlxQq+zOAr4yuijRA== From: "Pierre Forgues" To: X-OriginalArrivalTime: 18 May 2005 13:39:01.0204 (UTC) FILETIME=[F32AE940:01C55BAE] X-FromHost: postcard.nuance.com [10.3.6.20]:15302 Lines: 598 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0634ec58aad05a6aa9ac7d4670be9c6c Cc: Pierre Forgues Subject: [Speechsc] Questions about MRCPv2 transport protocols X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0047921728==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0047921728== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55BAE.F29DEDF1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55BAE.F29DEDF1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have 2 questions about the latest MRCPv2 specification. =20 Question-1: The examples in the MRCPv2 specification always show TCP as the transport protocol for SIP messages. Do implementers have to support both TCP and UDP? Note that the large majority of SIP implementations currently use UDP. I guess a related question is that if both need to be supported, which mode will actually be used by client implementations? =20 Question-2: I think the examples in the MRCPv2 specification do not conform to RFC 3264 which states that new m-lines in an SDP should always be added at the end of the existing list. Here is the relevant text (note the text in section 8.1 or RFC 3264): =20 8. Modifying the Session At any point during the session, either participant MAY issue a new offer to modify characteristics of the session. It is fundamental to the operation of the offer/answer model that the exact same offer/answer procedure defined above is used for modifying parameters of an existing session. The offer MAY be identical to the last SDP provided to the other party (which may have been provided in an offer or an answer), or it MAY be different. We refer to the last SDP provided as the "previous SDP". If the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different. If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below. Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. When issuing an offer that modifies the session, the "o=3D" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6. If an SDP is offered, which is different from the previous SDP, the new SDP MUST have a matching media stream for each media stream in the previous SDP. In other words, if the previous SDP had N "m=3D" lines, the new SDP MUST have at least N "m=3D" lines. The i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top. This matching is necessary in order for the answerer to determine which stream in the new SDP corresponds to a stream in the previous SDP. Because of these requirements, the number of "m=3D" lines in a stream never decreases, but either stays the same or increases. Deleted media streams from a previous SDP MUST NOT be removed in a new SDP; however, attributes for these streams need not be present. 8.1 Adding a Media Stream New media streams are created by new additional media descriptions below the existing ones, or by reusing the "slot" used by an old media stream which had been disabled by setting its port to zero. Reusing its slot means that the new media description replaces the old one, but retains its positioning relative to other media descriptions in the SDP. New media descriptions MUST appear below any existing media sections. The rules for formatting these media descriptions are identical to those described in Section 5. When the answerer receives an SDP with more media descriptions than the previous SDP from the offerer, or it receives an SDP with a media stream in a slot where the port was previously zero, the answerer knows that new media streams are being added. These can be rejected or accepted by placing an appropriately structured media description in the answer. The procedures for constructing the new media description in the answer are described in Section 6. =20 =20 =20 If you look at the examples 1, 2 and 3 at the beginning of the MRCP specification, a speech recognizer is added to the session but the m-line for this resource shows up at the beginning of the list. This should be appended at the end. =20 C->S: =20 INVITE sip:mresources@mediaserver.com SIP/2.0 =20 Via: SIP/2.0/TCP client.atlanta.example.com:5060;=20 branch=3Dz9hG4bK74bf9=20 Max-Forwards: 6 =20 To: MediaServer =20 From: sarvi ;tag=3D1928301774 =20 Call-ID: a84b4c76e66710 =20 CSeq: 314163 INVITE =20 Contact: =20 Content-Type: application/sdp =20 Content-Length: ... =20 =20 v=3D0 =20 o=3Dsarvi 2890844526 2890842809 IN IP4 126.16.64.4 =20 s=3D-=20 c=3DIN IP4 224.2.17.12=20 m=3Dapplication 9 TCP/MRCPv2 =20 a=3Dsetup:active=20 a=3Dconnection:existing=20 a=3Dresource:speechrecog=20 a=3Dcmid:1=20 m=3Dapplication 9 TCP/MRCPv2 =20 a=3Dsetup:active=20 a=3Dconnection:existing=20 a=3Dresource:speechsynth=20 a=3Dcmid:1=20 m=3Daudio 49170 RTP/AVP 0 96 =20 a=3Drtpmap:0 pcmu/8000 =20 a=3Drtpmap:96 telephone-event/8000 =20 a=3Dfmtp:96 0-15 =20 a=3Dsendrecv =20 a=3Dmid:1 =20 =20 =20 Pierre=20 =20 =20 ------_=_NextPart_001_01C55BAE.F29DEDF1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, I have 2 questions about the latest MRCPv2 = specification.

 

Question-1: The examples in the MRCPv2 specification = always show TCP as the transport protocol for SIP messages.  Do = implementers have to support both TCP and UDP?  Note that the large majority of SIP implementations currently use UDP.  I guess a related question is = that if both need to be supported, which mode will actually be used by client implementations?

 

Question-2: I think the examples in the MRCPv2 = specification do not conform to RFC 3264 which states that new m-lines in an SDP = should always be added at the end of the existing list.  Here is the = relevant text (note the text in section 8.1 or RFC = 3264):

 

8. Modifying the = Session

   At any point during the session, either participant MAY = issue a new
   offer to modify characteristics of the session.  It is fundamental to
   the operation of the offer/answer model that the exact = same
   offer/answer procedure defined above is used for modifying parameters
   of an existing session.

   The offer MAY be identical to the last SDP provided to the = other
   party (which may have been provided in an offer or an = answer), or it
   MAY be different.  We refer to the last SDP provided = as the "previous
   SDP".  If the offer is the same, the answer MAY = be the same as the
   previous SDP from the answerer, or it MAY be = different.  If the
   offered SDP is different from the previous SDP, some = constraints are
   placed on its construction, discussed below.

   Nearly all aspects of the session can be modified.  = New streams can
   be added, existing streams can be deleted, and parameters = of existing
   streams can change.  When issuing an offer that = modifies the session,
   the "o=3D" line of the new SDP MUST be identical = to that in the
   previous SDP, except that the version in the origin field = MUST
   increment by one from the previous SDP.  If the = version in the origin
   line does not increment, the SDP MUST be identical to the = SDP with
   that version number.  The answerer MUST be prepared to receive an
   offer that contains SDP with a version that has not = changed; this is
   effectively a no-op.  However, the answerer MUST = generate a valid
   answer (which MAY be the same as the previous SDP from the = answerer,
   or MAY be different), according to the procedures defined = in Section
   6.

   If an SDP is offered, which is different from the previous = SDP, the
   new SDP MUST have a matching media stream for each media = stream in
   the previous SDP.  In other words, if the previous SDP = had N "m=3D"
   lines, the new SDP MUST have at least N "m=3D" lines.  The i-th media
   stream in the previous SDP, counting from the top, matches = the i-th
   media stream in the new SDP, counting from the top.  = This matching is
   necessary in order for the answerer to determine which = stream in the
   new SDP corresponds to a stream in the previous SDP.  = Because of
   these requirements, the number of "m=3D" lines in = a stream never
   decreases, but either stays the same or increases.  = Deleted media
   streams from a previous SDP MUST NOT be removed in a new = SDP;
   however, attributes for these streams need not be = present.

8.1 Adding a Media Stream

   New media streams are created by new additional media = descriptions
   below the existing ones, or by = reusing the "slot" used by an old
   media stream which had been disabled by setting its port to = zero.

   Reusing its slot means that the new media description = replaces the
   old one, but retains its positioning relative to other = media
   descriptions in  the SDP.  New media descriptions = MUST appear below
   any existing media sections.  The rules for formatting = these media
   descriptions are identical to those described in Section = 5.

   When the answerer receives an SDP with more media = descriptions than
   the previous SDP from the offerer, or it receives an SDP = with a media
   stream in a slot where the port was previously zero, the = answerer
   knows that new media streams are being added.  These = can be rejected
   or accepted by placing an appropriately structured media description
   in the answer.  The procedures for constructing the = new media
   description in the answer are described in Section = 6.

 

 

 

If you look at the examples 1, 2 and 3 at the = beginning of the MRCP specification, a speech recognizer is added to the session but = the m-line for this resource shows up at the beginning of the list. =  This should be appended at the end.

 

   C->S:  =

       &nbs=
p;  INVITE sip:mresources@mediaserver.com SIP/2.0  =

       &nbs=
p;  Via: SIP/2.0/TCP client.atlanta.example.com:5060; =

       &nbs=
p;       branch=3Dz9hG4bK74bf9 =

       &nbs=
p;  Max-Forwards: 6  =

       &nbs=
p;  To: MediaServer =
<sip:mresources@mediaserver.com>  =

       &nbs=
p;  From: sarvi =
<sip:sarvi@cisco.com>;tag=3D1928301774  =

       &nbs=
p;  Call-ID: a84b4c76e66710  =

       &nbs=
p;  CSeq: 314163 INVITE  =

       &nbs=
p;  Contact: <sip:sarvi@cisco.com>  =

       &nbs=
p;  Content-Type: application/sdp  =

       &nbs=
p;  Content-Length: ...  =

       &nbs=
p;        
       &nbs=
p;  v=3D0  
       &nbs=
p;  o=3Dsarvi 2890844526 2890842809 IN IP4 126.16.64.4  =

       &nbs=
p;  s=3D- 
       &nbs=
p;  c=3DIN IP4 224.2.17.12 =

     =
;     m=3Dapplication 9 TCP/MRCPv2  =

     =
;     a=3Dsetup:active =

     =
;     a=3Dconnection:existing =

     =
;     a=3Dresource:speechrecog =

     =
;     a=3Dcmid:1 =

       &nbs=
p;  m=3Dapplication 9 TCP/MRCPv2  =

       &nbs=
p;  a=3Dsetup:active 
       &nbs=
p;  a=3Dconnection:existing =

       &nbs=
p;  a=3Dresource:speechsynth =

       &nbs=
p;  a=3Dcmid:1 
       &nbs=
p;  m=3Daudio 49170 RTP/AVP 0 96  =

       &nbs=
p;  a=3Drtpmap:0 pcmu/8000  =

       &nbs=
p;  a=3Drtpmap:96 telephone-event/8000  =

       &nbs=
p;  a=3Dfmtp:96 0-15  =

       &nbs=
p;  a=3Dsendrecv  =

       &nbs=
p;  a=3Dmid:1

 

 

 

Pierre =

 

 

------_=_NextPart_001_01C55BAE.F29DEDF1-- --===============0047921728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0047921728==-- From speechsc-bounces@ietf.org Wed May 18 10:46:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPox-0002Rt-Vj; Wed, 18 May 2005 10:46:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPow-0002Ro-NM for speechsc@megatron.ietf.org; Wed, 18 May 2005 10:46:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27858 for ; Wed, 18 May 2005 10:46:48 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQ5u-0002TX-HR for speechsc@ietf.org; Wed, 18 May 2005 11:04:23 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 18 May 2005 07:46:41 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4IEkcnC011546; Wed, 18 May 2005 07:46:39 -0700 (PDT) Received: from [167.254.254.200] (sjc-vpn5-75.cisco.com [10.21.88.75]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4IEZsF3003000; Wed, 18 May 2005 07:35:55 -0700 In-Reply-To: <7DE7C4EF3B7C8B4B82955191378290D802B97E58@mtb1exch01.nuance.com> References: <7DE7C4EF3B7C8B4B82955191378290D802B97E58@mtb1exch01.nuance.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D74409F-57BE-453F-A271-C1AA69125CCD@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols Date: Wed, 18 May 2005 10:46:28 -0400 To: Pierre Forgues X-Mailer: Apple Mail (2.728) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116426958.609666"; x:"432200"; a:"rsa-sha1"; b:"nofws:4875"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"L/cy7IgHhT5GB90bdYIdQSAaWHx5BNoFAcEKMMnqiAMO4URR9Dr/tdzjOEtlKeAqomW6aB39" "ra6cdxdAUvVSvininWAmx7Z4S548qftH6AKFJdF8s1A2jHH5mNxFUu5NqtTnCLpGyiOe00jt6py" "Bhcc8FJG/8gfzCbQ5ArTkwsw="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols"; c:"Date: Wed, 18 May 2005 10:46:28 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org On May 18, 2005, at 9:38 AM, Pierre Forgues wrote: > Hi, I have 2 questions about the latest MRCPv2 specification. > > > > Question-1: The examples in the MRCPv2 specification always show > TCP as the transport protocol for SIP messages. Do implementers > have to support both TCP and UDP? For SIP, right? MRCP of course only runs on a reliable transport, with TCP/TLS being mandatory to implement. This requirement is completely independent of what transport SIP is running over. Am I missing something in your question? > Note that the large majority of SIP implementations currently use > UDP. I guess a related question is that if both need to be > supported, which mode will actually be used by client implementations? Yes, and all MSRP implementations use TCP. MRCP is as independent of the the transport SIP runs on as is MSRP, or any other media session established through SIP. Am I missing something? > > > Question-2: I think the examples in the MRCPv2 specification do not > conform to RFC 3264 which states that new m-lines in an SDP should > always be added at the end of the existing list. Here is the > relevant text (note the text in section 8.1 or RFC 3264): > > > > 8. Modifying the Session > > At any point during the session, either participant MAY issue a new > offer to modify characteristics of the session. It is > fundamental to > the operation of the offer/answer model that the exact same > offer/answer procedure defined above is used for modifying > parameters > of an existing session. > > The offer MAY be identical to the last SDP provided to the other > party (which may have been provided in an offer or an answer), > or it > MAY be different. We refer to the last SDP provided as the > "previous > SDP". If the offer is the same, the answer MAY be the same as the > previous SDP from the answerer, or it MAY be different. If the > offered SDP is different from the previous SDP, some constraints > are > placed on its construction, discussed below. > > Nearly all aspects of the session can be modified. New streams can > be added, existing streams can be deleted, and parameters of > existing > streams can change. When issuing an offer that modifies the > session, > the "o=" line of the new SDP MUST be identical to that in the > previous SDP, except that the version in the origin field MUST > increment by one from the previous SDP. If the version in the > origin > line does not increment, the SDP MUST be identical to the SDP with > that version number. The answerer MUST be prepared to receive an > offer that contains SDP with a version that has not changed; > this is > effectively a no-op. However, the answerer MUST generate a valid > answer (which MAY be the same as the previous SDP from the > answerer, > or MAY be different), according to the procedures defined in > Section > 6. > > If an SDP is offered, which is different from the previous SDP, the > new SDP MUST have a matching media stream for each media stream in > the previous SDP. In other words, if the previous SDP had N "m=" > lines, the new SDP MUST have at least N "m=" lines. The i-th media > stream in the previous SDP, counting from the top, matches the i-th > media stream in the new SDP, counting from the top. This > matching is > necessary in order for the answerer to determine which stream in > the > new SDP corresponds to a stream in the previous SDP. Because of > these requirements, the number of "m=" lines in a stream never > decreases, but either stays the same or increases. Deleted media > streams from a previous SDP MUST NOT be removed in a new SDP; > however, attributes for these streams need not be present. > > 8.1 Adding a Media Stream > > New media streams are created by new additional media descriptions > below the existing ones, or by reusing the "slot" used by an old > media stream which had been disabled by setting its port to zero. > > Reusing its slot means that the new media description replaces the > old one, but retains its positioning relative to other media > descriptions in the SDP. New media descriptions MUST appear below > any existing media sections. The rules for formatting these media > descriptions are identical to those described in Section 5. > > When the answerer receives an SDP with more media descriptions than > the previous SDP from the offerer, or it receives an SDP with a > media > stream in a slot where the port was previously zero, the answerer > knows that new media streams are being added. These can be > rejected > or accepted by placing an appropriately structured media > description > in the answer. The procedures for constructing the new media > description in the answer are described in Section 6. > > > > > > > > If you look at the examples 1, 2 and 3 at the beginning of the MRCP > specification, a speech recognizer is added to the session but the > m-line for this resource shows up at the beginning of the list. > This should be appended at the end. > > Good catch! > C->S: INVITE sip:mresources@mediaserver.com SIP/ > 2.0 Via: SIP/2.0/TCP client.atlanta.example.com: > 5060; branch=z9hG4bK74bf9 Max-Forwards: > 6 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=application 9 TCP/MRCPv2 a=setup:active > a=connection:existing a=resource:speechrecog > a=cmid:1 m=application 9 TCP/MRCPv2 > a=setup:active a=connection:existing > a=resource:speechsynth a=cmid:1 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 a=mid:1 > > > > > > > Pierre > > > > > > _______________________________________________ > 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 speechsc-bounces@ietf.org Wed May 18 11:04:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQ5X-0007V6-W9; Wed, 18 May 2005 11:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQ5X-0007Uy-6D for speechsc@megatron.ietf.org; Wed, 18 May 2005 11:03:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29372 for ; Wed, 18 May 2005 11:03:56 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQMU-0003TN-2o for speechsc@ietf.org; Wed, 18 May 2005 11:21:31 -0400 Received: from postcard.nuance.com ([10.3.6.20]:16547) by letter.nuance.com with esmtp id 1DYQ5M-0004tt-8n; Wed, 18 May 2005 08:03:48 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 May 2005 11:02:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols Date: Wed, 18 May 2005 11:02:23 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802B97EC5@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] Questions about MRCPv2 transport protocols Thread-Index: AcVbuEv3hbpAhS73SRK9P+DpN4/gDgAAY+oA From: "Pierre Forgues" To: "David R. Oran" X-OriginalArrivalTime: 18 May 2005 15:02:49.0961 (UTC) FILETIME=[A88A5590:01C55BBA] X-FromHost: postcard.nuance.com [10.3.6.20]:16547 Lines: 191 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi David, my question was for SIP messages specifically. I understand the MRCP channel is a reliable TCP connection. So my question as a developer of an MRCPv2 server is that we will receive SIP Invite messages and respond likewise with capabilities. These SIP exchanges can occur over TCP or UDP. So my question is do we need to support BOTH TCP and UDP? I am guessing the specification is very "general" and therefore would require that implementations need to support both because this is what the SIP RFC suggest. However, practically I was wondering whether implementers would bother with both TCP and UDP. I noticed all of the examples in the spec seem to use TCP only " Via: SIP/2.0/TCP client.atlanta.example.com" Pierre -----Original Message----- From: David R. Oran [mailto:oran@cisco.com]=20 Sent: Wednesday, May 18, 2005 10:46 AM To: Pierre Forgues Cc: IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols On May 18, 2005, at 9:38 AM, Pierre Forgues wrote: > Hi, I have 2 questions about the latest MRCPv2 specification. > > > > Question-1: The examples in the MRCPv2 specification always show =20 > TCP as the transport protocol for SIP messages. Do implementers =20 > have to support both TCP and UDP? For SIP, right? MRCP of course only runs on a reliable transport, =20 with TCP/TLS being mandatory to implement. This requirement is =20 completely independent of what transport SIP is running over. Am I =20 missing something in your question? > Note that the large majority of SIP implementations currently use =20 > UDP. I guess a related question is that if both need to be =20 > supported, which mode will actually be used by client implementations? Yes, and all MSRP implementations use TCP. MRCP is as independent of =20 the the transport SIP runs on as is MSRP, or any other media session =20 established through SIP. Am I missing something? > > > Question-2: I think the examples in the MRCPv2 specification do not =20 > conform to RFC 3264 which states that new m-lines in an SDP should =20 > always be added at the end of the existing list. Here is the =20 > relevant text (note the text in section 8.1 or RFC 3264): > > > > 8. Modifying the Session > > At any point during the session, either participant MAY issue a new > offer to modify characteristics of the session. It is =20 > fundamental to > the operation of the offer/answer model that the exact same > offer/answer procedure defined above is used for modifying =20 > parameters > of an existing session. > > The offer MAY be identical to the last SDP provided to the other > party (which may have been provided in an offer or an answer), =20 > or it > MAY be different. We refer to the last SDP provided as the =20 > "previous > SDP". If the offer is the same, the answer MAY be the same as the > previous SDP from the answerer, or it MAY be different. If the > offered SDP is different from the previous SDP, some constraints =20 > are > placed on its construction, discussed below. > > Nearly all aspects of the session can be modified. New streams can > be added, existing streams can be deleted, and parameters of =20 > existing > streams can change. When issuing an offer that modifies the =20 > session, > the "o=3D" line of the new SDP MUST be identical to that in the > previous SDP, except that the version in the origin field MUST > increment by one from the previous SDP. If the version in the =20 > origin > line does not increment, the SDP MUST be identical to the SDP with > that version number. The answerer MUST be prepared to receive an > offer that contains SDP with a version that has not changed; =20 > this is > effectively a no-op. However, the answerer MUST generate a valid > answer (which MAY be the same as the previous SDP from the =20 > answerer, > or MAY be different), according to the procedures defined in =20 > Section > 6. > > If an SDP is offered, which is different from the previous SDP, the > new SDP MUST have a matching media stream for each media stream in > the previous SDP. In other words, if the previous SDP had N "m=3D" > lines, the new SDP MUST have at least N "m=3D" lines. The i-th = media > stream in the previous SDP, counting from the top, matches the i-th > media stream in the new SDP, counting from the top. This =20 > matching is > necessary in order for the answerer to determine which stream in =20 > the > new SDP corresponds to a stream in the previous SDP. Because of > these requirements, the number of "m=3D" lines in a stream never > decreases, but either stays the same or increases. Deleted media > streams from a previous SDP MUST NOT be removed in a new SDP; > however, attributes for these streams need not be present. > > 8.1 Adding a Media Stream > > New media streams are created by new additional media descriptions > below the existing ones, or by reusing the "slot" used by an old > media stream which had been disabled by setting its port to zero. > > Reusing its slot means that the new media description replaces the > old one, but retains its positioning relative to other media > descriptions in the SDP. New media descriptions MUST appear below > any existing media sections. The rules for formatting these media > descriptions are identical to those described in Section 5. > > When the answerer receives an SDP with more media descriptions than > the previous SDP from the offerer, or it receives an SDP with a =20 > media > stream in a slot where the port was previously zero, the answerer > knows that new media streams are being added. These can be =20 > rejected > or accepted by placing an appropriately structured media =20 > description > in the answer. The procedures for constructing the new media > description in the answer are described in Section 6. > > > > > > > > If you look at the examples 1, 2 and 3 at the beginning of the MRCP =20 > specification, a speech recognizer is added to the session but the =20 > m-line for this resource shows up at the beginning of the list. =20 > This should be appended at the end. > > Good catch! > C->S: INVITE sip:mresources@mediaserver.com SIP/=20 > 2.0 Via: SIP/2.0/TCP client.atlanta.example.com:=20 > 5060; branch=3Dz9hG4bK74bf9 Max-Forwards: =20 > 6 To: MediaServer =20 > From: sarvi =20 > ;tag=3D1928301774 Call-ID: =20 > a84b4c76e66710 CSeq: 314163 INVITE Contact: =20 > Content-Type: application/=20 > sdp Content-Length: ... =20 > v=3D0 o=3Dsarvi 2890844526 2890842809 IN IP4 =20 > 126.16.64.4 s=3D- c=3DIN IP4 224.2.17.12 = =20 > m=3Dapplication 9 TCP/MRCPv2 a=3Dsetup:active =20 > a=3Dconnection:existing a=3Dresource:speechrecog =20 > a=3Dcmid:1 m=3Dapplication 9 TCP/MRCPv2 =20 > a=3Dsetup:active a=3Dconnection:existing =20 > a=3Dresource:speechsynth a=3Dcmid:1 m=3Daudio = 49170 =20 > RTP/AVP 0 96 a=3Drtpmap:0 pcmu/8000 a=3Drtpmap:96 = telephone-=20 > event/8000 a=3Dfmtp:96 0-15 =20 > a=3Dsendrecv a=3Dmid:1 > > > > > > > Pierre > > > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed May 18 11:22:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQNl-0005TH-Vo; Wed, 18 May 2005 11:22:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQNk-0005Rb-Ge for speechsc@megatron.ietf.org; Wed, 18 May 2005 11:22:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01316 for ; Wed, 18 May 2005 11:22:45 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQei-0004aw-EP for speechsc@ietf.org; Wed, 18 May 2005 11:40:21 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 18 May 2005 08:22:36 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4IFMXrA026381; Wed, 18 May 2005 08:22:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols Date: Wed, 18 May 2005 08:24:05 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B31F514@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Questions about MRCPv2 transport protocols Thread-Index: AcVbuEv3hbpAhS73SRK9P+DpN4/gDgAAY+oAAAC847A= From: "Shanmugham, Saravanan" To: "Pierre Forgues" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org The SIP client associated with the MRCP server should be a fully compliant SIP client and we are not adding/removing anything from that spec.=20 Infact, when I think about it we might have to add additionally that the SIP client associated with MRCP must also implement TLS if we are to meet security considerations for Speaker Verification and Idenitifcation. =20 Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Pierre Forgues Sent: Wednesday, May 18, 2005 8:02 AM To: David R. Oran Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols =20 Hi David, my question was for SIP messages specifically. =20 I understand the MRCP channel is a reliable TCP connection. =20 So my question as a developer of an MRCPv2 server is that=20 we will receive SIP Invite messages and respond likewise=20 with capabilities. These SIP exchanges can occur over TCP or UDP. So my=20 question is do we need to support BOTH TCP and UDP? I am=20 guessing the specification is very "general" and therefore=20 would require that implementations need to support both=20 because this is what the SIP RFC suggest. =20 However, practically I was wondering whether implementers=20 would bother with both TCP and UDP. I noticed all of the=20 examples in the spec seem to use TCP only =20 " Via: SIP/2.0/TCP client.atlanta.example.com" =20 Pierre =20 -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Wednesday, May 18, 2005 10:46 AM To: Pierre Forgues Cc: IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols =20 =20 On May 18, 2005, at 9:38 AM, Pierre Forgues wrote: =20 > Hi, I have 2 questions about the latest MRCPv2 specification. > > > > Question-1: The examples in the MRCPv2 specification=20 always show =20 > TCP as the transport protocol for SIP messages. Do=20 implementers =20 > have to support both TCP and UDP? For SIP, right? MRCP of course only runs on a reliable transport, =20 with TCP/TLS being mandatory to implement. This requirement is =20 completely independent of what transport SIP is running=20 over. Am I =20 missing something in your question? > Note that the large majority of SIP implementations=20 currently use =20 > UDP. I guess a related question is that if both need to be =20 > supported, which mode will actually be used by client=20 implementations? Yes, and all MSRP implementations use TCP. MRCP is as=20 independent of =20 the the transport SIP runs on as is MSRP, or any other=20 media session =20 established through SIP. Am I missing something? > > > Question-2: I think the examples in the MRCPv2=20 specification do not =20 > conform to RFC 3264 which states that new m-lines in an=20 SDP should =20 > always be added at the end of the existing list. Here is the =20 > relevant text (note the text in section 8.1 or RFC 3264): > > > > 8. Modifying the Session > > At any point during the session, either participant=20 MAY issue a new > offer to modify characteristics of the session. It is =20 > fundamental to > the operation of the offer/answer model that the exact same > offer/answer procedure defined above is used for modifying =20 > parameters > of an existing session. > > The offer MAY be identical to the last SDP provided=20 to the other > party (which may have been provided in an offer or an=20 answer), =20 > or it > MAY be different. We refer to the last SDP provided as the =20 > "previous > SDP". If the offer is the same, the answer MAY be=20 the same as the > previous SDP from the answerer, or it MAY be=20 different. If the > offered SDP is different from the previous SDP, some=20 constraints =20 > are > placed on its construction, discussed below. > > Nearly all aspects of the session can be modified. =20 New streams can > be added, existing streams can be deleted, and parameters of =20 > existing > streams can change. When issuing an offer that modifies the =20 > session, > the "o=3D" line of the new SDP MUST be identical to that in = the > previous SDP, except that the version in the origin field MUST > increment by one from the previous SDP. If the=20 version in the =20 > origin > line does not increment, the SDP MUST be identical to=20 the SDP with > that version number. The answerer MUST be prepared=20 to receive an > offer that contains SDP with a version that has not changed; =20 > this is > effectively a no-op. However, the answerer MUST=20 generate a valid > answer (which MAY be the same as the previous SDP from the =20 > answerer, > or MAY be different), according to the procedures defined in =20 > Section > 6. > > If an SDP is offered, which is different from the=20 previous SDP, the > new SDP MUST have a matching media stream for each=20 media stream in > the previous SDP. In other words, if the previous=20 SDP had N "m=3D" > lines, the new SDP MUST have at least N "m=3D" lines. =20 The i-th media > stream in the previous SDP, counting from the top,=20 matches the i-th > media stream in the new SDP, counting from the top. This =20 > matching is > necessary in order for the answerer to determine=20 which stream in =20 > the > new SDP corresponds to a stream in the previous SDP. =20 Because of > these requirements, the number of "m=3D" lines in a stream = never > decreases, but either stays the same or increases. =20 Deleted media > streams from a previous SDP MUST NOT be removed in a new SDP; > however, attributes for these streams need not be present. > > 8.1 Adding a Media Stream > > New media streams are created by new additional media=20 descriptions > below the existing ones, or by reusing the "slot"=20 used by an old > media stream which had been disabled by setting its=20 port to zero. > > Reusing its slot means that the new media description=20 replaces the > old one, but retains its positioning relative to other media > descriptions in the SDP. New media descriptions=20 MUST appear below > any existing media sections. The rules for=20 formatting these media > descriptions are identical to those described in Section 5. > > When the answerer receives an SDP with more media=20 descriptions than > the previous SDP from the offerer, or it receives an=20 SDP with a =20 > media > stream in a slot where the port was previously zero,=20 the answerer > knows that new media streams are being added. These can be =20 > rejected > or accepted by placing an appropriately structured media =20 > description > in the answer. The procedures for constructing the new media > description in the answer are described in Section 6. > > > > > > > > If you look at the examples 1, 2 and 3 at the beginning=20 of the MRCP =20 > specification, a speech recognizer is added to the=20 session but the =20 > m-line for this resource shows up at the beginning of=20 the list. =20 > This should be appended at the end. > > Good catch! =20 > C->S: INVITE sip:mresources@mediaserver.com SIP/=20 > 2.0 Via: SIP/2.0/TCP client.atlanta.example.com:=20 > 5060; branch=3Dz9hG4bK74bf9 =20 Max-Forwards: =20 > 6 To: MediaServer =20 > From: sarvi =20 > ;tag=3D1928301774 Call-ID: =20 > a84b4c76e66710 CSeq: 314163 INVITE =20 Contact: =20 > Content-Type: application/=20 > sdp Content-Length: ... =20 > v=3D0 o=3Dsarvi 2890844526 2890842809 IN IP4 =20 > 126.16.64.4 s=3D- c=3DIN IP4=20 224.2.17.12 =20 > m=3Dapplication 9 TCP/MRCPv2 a=3Dsetup:active = =20 > a=3Dconnection:existing a=3Dresource:speechrecog =20 =20 > a=3Dcmid:1 m=3Dapplication 9 TCP/MRCPv2 =20 > a=3Dsetup:active a=3Dconnection:existing =20 > a=3Dresource:speechsynth a=3Dcmid:1 =20 m=3Daudio 49170 =20 > RTP/AVP 0 96 a=3Drtpmap:0 pcmu/8000 =20 a=3Drtpmap:96 telephone-=20 > event/8000 a=3Dfmtp:96 0-15 =20 > a=3Dsendrecv a=3Dmid:1 > > > > > > > Pierre > > > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > =20 =20 =20 =20 =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 From speechsc-bounces@ietf.org Wed May 18 11:32:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQXB-0000Sq-C5; Wed, 18 May 2005 11:32:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQX9-0000Sl-Ht for speechsc@megatron.ietf.org; Wed, 18 May 2005 11:32:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02419 for ; Wed, 18 May 2005 11:32:28 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQo7-0005IM-SU for speechsc@ietf.org; Wed, 18 May 2005 11:50:04 -0400 Received: from postcard.nuance.com ([10.3.6.20]:17029) by letter.nuance.com with esmtp id 1DYQX0-0005Sy-6U; Wed, 18 May 2005 08:32:22 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 May 2005 11:31:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols Date: Wed, 18 May 2005 11:31:22 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802B97EE4@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] Questions about MRCPv2 transport protocols Thread-Index: AcVbuEv3hbpAhS73SRK9P+DpN4/gDgAAY+oAAAC847AAAEBTwA== From: "Pierre Forgues" To: "Shanmugham, Saravanan" , "David R. Oran" X-OriginalArrivalTime: 18 May 2005 15:31:23.0853 (UTC) FILETIME=[A6197FD0:01C55BBE] X-FromHost: postcard.nuance.com [10.3.6.20]:17029 Lines: 290 X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I personally don't see the need for securing the SIP channel as the only information going across are addition and removal of resources. My preference would be to stay as standard as possible. The MRCP channel is the one bearing sensitive information. Regarding TCP versus UDP for SIP, I guess I will have to ask various client-side implementers individually. Even though the SIP spec allows both, I wonder if we should simplify implementations by selecting one method in particular. This would greatly reduce interoperability combinations across vendors. If the consensus by everyone is to allow both, then no problem - it's more interoperability work. =20 Pierre -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Wednesday, May 18, 2005 11:24 AM To: Pierre Forgues; David R. Oran Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols The SIP client associated with the MRCP server should be a fully compliant SIP client and we are not adding/removing anything from that spec.=20 Infact, when I think about it we might have to add additionally that the SIP client associated with MRCP must also implement TLS if we are to meet security considerations for Speaker Verification and Idenitifcation. =20 Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Pierre Forgues Sent: Wednesday, May 18, 2005 8:02 AM To: David R. Oran Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols =20 Hi David, my question was for SIP messages specifically. =20 I understand the MRCP channel is a reliable TCP connection. =20 So my question as a developer of an MRCPv2 server is that=20 we will receive SIP Invite messages and respond likewise=20 with capabilities. These SIP exchanges can occur over TCP or UDP. So my=20 question is do we need to support BOTH TCP and UDP? I am=20 guessing the specification is very "general" and therefore=20 would require that implementations need to support both=20 because this is what the SIP RFC suggest. =20 However, practically I was wondering whether implementers=20 would bother with both TCP and UDP. I noticed all of the=20 examples in the spec seem to use TCP only =20 " Via: SIP/2.0/TCP client.atlanta.example.com" =20 Pierre =20 -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Wednesday, May 18, 2005 10:46 AM To: Pierre Forgues Cc: IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols =20 =20 On May 18, 2005, at 9:38 AM, Pierre Forgues wrote: =20 > Hi, I have 2 questions about the latest MRCPv2 specification. > > > > Question-1: The examples in the MRCPv2 specification=20 always show =20 > TCP as the transport protocol for SIP messages. Do=20 implementers =20 > have to support both TCP and UDP? For SIP, right? MRCP of course only runs on a reliable transport, =20 with TCP/TLS being mandatory to implement. This requirement is =20 completely independent of what transport SIP is running=20 over. Am I =20 missing something in your question? > Note that the large majority of SIP implementations=20 currently use =20 > UDP. I guess a related question is that if both need to be =20 > supported, which mode will actually be used by client=20 implementations? Yes, and all MSRP implementations use TCP. MRCP is as=20 independent of =20 the the transport SIP runs on as is MSRP, or any other=20 media session =20 established through SIP. Am I missing something? > > > Question-2: I think the examples in the MRCPv2=20 specification do not =20 > conform to RFC 3264 which states that new m-lines in an=20 SDP should =20 > always be added at the end of the existing list. Here is the =20 > relevant text (note the text in section 8.1 or RFC 3264): > > > > 8. Modifying the Session > > At any point during the session, either participant=20 MAY issue a new > offer to modify characteristics of the session. It is =20 > fundamental to > the operation of the offer/answer model that the exact same > offer/answer procedure defined above is used for modifying =20 > parameters > of an existing session. > > The offer MAY be identical to the last SDP provided=20 to the other > party (which may have been provided in an offer or an=20 answer), =20 > or it > MAY be different. We refer to the last SDP provided as the =20 > "previous > SDP". If the offer is the same, the answer MAY be=20 the same as the > previous SDP from the answerer, or it MAY be=20 different. If the > offered SDP is different from the previous SDP, some=20 constraints =20 > are > placed on its construction, discussed below. > > Nearly all aspects of the session can be modified. =20 New streams can > be added, existing streams can be deleted, and parameters of =20 > existing > streams can change. When issuing an offer that modifies the =20 > session, > the "o=3D" line of the new SDP MUST be identical to that in = the > previous SDP, except that the version in the origin field MUST > increment by one from the previous SDP. If the=20 version in the =20 > origin > line does not increment, the SDP MUST be identical to=20 the SDP with > that version number. The answerer MUST be prepared=20 to receive an > offer that contains SDP with a version that has not changed; =20 > this is > effectively a no-op. However, the answerer MUST=20 generate a valid > answer (which MAY be the same as the previous SDP from the =20 > answerer, > or MAY be different), according to the procedures defined in =20 > Section > 6. > > If an SDP is offered, which is different from the=20 previous SDP, the > new SDP MUST have a matching media stream for each=20 media stream in > the previous SDP. In other words, if the previous=20 SDP had N "m=3D" > lines, the new SDP MUST have at least N "m=3D" lines. =20 The i-th media > stream in the previous SDP, counting from the top,=20 matches the i-th > media stream in the new SDP, counting from the top. This =20 > matching is > necessary in order for the answerer to determine=20 which stream in =20 > the > new SDP corresponds to a stream in the previous SDP. =20 Because of > these requirements, the number of "m=3D" lines in a stream = never > decreases, but either stays the same or increases. =20 Deleted media > streams from a previous SDP MUST NOT be removed in a new SDP; > however, attributes for these streams need not be present. > > 8.1 Adding a Media Stream > > New media streams are created by new additional media=20 descriptions > below the existing ones, or by reusing the "slot"=20 used by an old > media stream which had been disabled by setting its=20 port to zero. > > Reusing its slot means that the new media description=20 replaces the > old one, but retains its positioning relative to other media > descriptions in the SDP. New media descriptions=20 MUST appear below > any existing media sections. The rules for=20 formatting these media > descriptions are identical to those described in Section 5. > > When the answerer receives an SDP with more media=20 descriptions than > the previous SDP from the offerer, or it receives an=20 SDP with a =20 > media > stream in a slot where the port was previously zero,=20 the answerer > knows that new media streams are being added. These can be =20 > rejected > or accepted by placing an appropriately structured media =20 > description > in the answer. The procedures for constructing the new media > description in the answer are described in Section 6. > > > > > > > > If you look at the examples 1, 2 and 3 at the beginning=20 of the MRCP =20 > specification, a speech recognizer is added to the=20 session but the =20 > m-line for this resource shows up at the beginning of=20 the list. =20 > This should be appended at the end. > > Good catch! =20 > C->S: INVITE sip:mresources@mediaserver.com SIP/=20 > 2.0 Via: SIP/2.0/TCP client.atlanta.example.com:=20 > 5060; branch=3Dz9hG4bK74bf9 =20 Max-Forwards: =20 > 6 To: MediaServer =20 > From: sarvi =20 > ;tag=3D1928301774 Call-ID: =20 > a84b4c76e66710 CSeq: 314163 INVITE =20 Contact: =20 > Content-Type: application/=20 > sdp Content-Length: ... =20 > v=3D0 o=3Dsarvi 2890844526 2890842809 IN IP4 =20 > 126.16.64.4 s=3D- c=3DIN IP4=20 224.2.17.12 =20 > m=3Dapplication 9 TCP/MRCPv2 a=3Dsetup:active = =20 > a=3Dconnection:existing a=3Dresource:speechrecog =20 =20 > a=3Dcmid:1 m=3Dapplication 9 TCP/MRCPv2 =20 > a=3Dsetup:active a=3Dconnection:existing =20 > a=3Dresource:speechsynth a=3Dcmid:1 =20 m=3Daudio 49170 =20 > RTP/AVP 0 96 a=3Drtpmap:0 pcmu/8000 =20 a=3Drtpmap:96 telephone-=20 > event/8000 a=3Dfmtp:96 0-15 =20 > a=3Dsendrecv a=3Dmid:1 > > > > > > > Pierre > > > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > =20 =20 =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed May 18 12:04:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYR1r-0001B5-B9; Wed, 18 May 2005 12:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYR1p-0001Az-SJ for speechsc@megatron.ietf.org; Wed, 18 May 2005 12:04:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05848 for ; Wed, 18 May 2005 12:04:11 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYRIo-0007C8-DA for speechsc@ietf.org; Wed, 18 May 2005 12:21:47 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 18 May 2005 09:04:04 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4IG41nC011647; Wed, 18 May 2005 09:04:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols Date: Wed, 18 May 2005 09:05:33 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B31F55D@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Questions about MRCPv2 transport protocols Thread-Index: AcVbuEv3hbpAhS73SRK9P+DpN4/gDgAAY+oAAAC847AAAEBTwAABNJDw From: "Shanmugham, Saravanan" To: "Pierre Forgues" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org On Security/TLS I would wait to hear what Dave/Eric have to say. I think UDP would be the scalable one. But I am thinking TCP might help when working across a NAT. My understanding was that that's why SIP clients implement TCP. Sarvi -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com]=20 Sent: Wednesday, May 18, 2005 8:31 AM To: Shanmugham, Saravanan; David R. Oran Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols =20 I personally don't see the need for securing the SIP=20 channel as the only information going across are addition=20 and removal of resources. My preference would be to stay=20 as standard as possible. The MRCP channel is the one=20 bearing sensitive information. =20 Regarding TCP versus UDP for SIP, I guess I will have to=20 ask various client-side implementers individually. Even=20 though the SIP spec allows both, I wonder if we should=20 simplify implementations by selecting one method in=20 particular. This would greatly reduce interoperability=20 combinations across vendors. If the consensus by everyone=20 is to allow both, then no problem - it's more=20 interoperability work. =20 =20 Pierre =20 =20 =20 -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Wednesday, May 18, 2005 11:24 AM To: Pierre Forgues; David R. Oran Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols =20 The SIP client associated with the MRCP server should be a=20 fully compliant SIP client and we are not adding/removing=20 anything from that spec.=20 =20 Infact, when I think about it we might have to add=20 additionally that the SIP client associated with MRCP must=20 also implement TLS if we are to meet security=20 considerations for Speaker Verification and Idenitifcation. =20 =20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Pierre Forgues Sent: Wednesday, May 18, 2005 8:02 AM To: David R. Oran Cc: IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] Questions about MRCPv2=20 transport protocols =20 Hi David, my question was for SIP messages specifically. =20 I understand the MRCP channel is a reliable TCP connection. =20 So my question as a developer of an MRCPv2 server is that=20 we will receive SIP Invite messages and respond likewise=20 with capabilities. These SIP exchanges can occur over TCP or UDP. So my=20 question is do we need to support BOTH TCP and UDP? I am=20 guessing the specification is very "general" and therefore=20 would require that implementations need to support both=20 because this is what the SIP RFC suggest. =20 However, practically I was wondering whether implementers=20 would bother with both TCP and UDP. I noticed all of the=20 examples in the spec seem to use TCP only =20 " Via: SIP/2.0/TCP client.atlanta.example.com" =20 Pierre =20 -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Wednesday, May 18, 2005 10:46 AM To: Pierre Forgues Cc: IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] Questions about MRCPv2=20 transport protocols =20 =20 On May 18, 2005, at 9:38 AM, Pierre Forgues wrote: =20 > Hi, I have 2 questions about the latest MRCPv2=20 specification. > > > > Question-1: The examples in the MRCPv2 specification=20 always show =20 > TCP as the transport protocol for SIP messages. Do=20 implementers =20 > have to support both TCP and UDP? For SIP, right? MRCP of course only runs on a=20 reliable transport, =20 with TCP/TLS being mandatory to implement. This=20 requirement is =20 completely independent of what transport SIP is running=20 over. Am I =20 missing something in your question? > Note that the large majority of SIP implementations=20 currently use =20 > UDP. I guess a related question is that if both=20 need to be =20 > supported, which mode will actually be used by client=20 implementations? Yes, and all MSRP implementations use TCP. MRCP is as=20 independent of =20 the the transport SIP runs on as is MSRP, or any other=20 media session =20 established through SIP. Am I missing something? > > > Question-2: I think the examples in the MRCPv2=20 specification do not =20 > conform to RFC 3264 which states that new m-lines in an=20 SDP should =20 > always be added at the end of the existing list. =20 Here is the =20 > relevant text (note the text in section 8.1 or RFC 3264): > > > > 8. Modifying the Session > > At any point during the session, either participant=20 MAY issue a new > offer to modify characteristics of the session. It is =20 > fundamental to > the operation of the offer/answer model that the=20 exact same > offer/answer procedure defined above is used for=20 modifying =20 > parameters > of an existing session. > > The offer MAY be identical to the last SDP provided=20 to the other > party (which may have been provided in an offer or an=20 answer), =20 > or it > MAY be different. We refer to the last SDP=20 provided as the =20 > "previous > SDP". If the offer is the same, the answer MAY be=20 the same as the > previous SDP from the answerer, or it MAY be=20 different. If the > offered SDP is different from the previous SDP, some=20 constraints =20 > are > placed on its construction, discussed below. > > Nearly all aspects of the session can be modified. =20 New streams can > be added, existing streams can be deleted, and=20 parameters of =20 > existing > streams can change. When issuing an offer that=20 modifies the =20 > session, > the "o=3D" line of the new SDP MUST be identical=20 to that in the > previous SDP, except that the version in the=20 origin field MUST > increment by one from the previous SDP. If the=20 version in the =20 > origin > line does not increment, the SDP MUST be identical to=20 the SDP with > that version number. The answerer MUST be prepared=20 to receive an > offer that contains SDP with a version that has=20 not changed; =20 > this is > effectively a no-op. However, the answerer MUST=20 generate a valid > answer (which MAY be the same as the previous=20 SDP from the =20 > answerer, > or MAY be different), according to the=20 procedures defined in =20 > Section > 6. > > If an SDP is offered, which is different from the=20 previous SDP, the > new SDP MUST have a matching media stream for each=20 media stream in > the previous SDP. In other words, if the previous=20 SDP had N "m=3D" > lines, the new SDP MUST have at least N "m=3D" lines. =20 The i-th media > stream in the previous SDP, counting from the top,=20 matches the i-th > media stream in the new SDP, counting from the=20 top. This =20 > matching is > necessary in order for the answerer to determine=20 which stream in =20 > the > new SDP corresponds to a stream in the previous SDP. =20 Because of > these requirements, the number of "m=3D" lines in=20 a stream never > decreases, but either stays the same or increases. =20 Deleted media > streams from a previous SDP MUST NOT be removed=20 in a new SDP; > however, attributes for these streams need not=20 be present. > > 8.1 Adding a Media Stream > > New media streams are created by new additional media=20 descriptions > below the existing ones, or by reusing the "slot"=20 used by an old > media stream which had been disabled by setting its=20 port to zero. > > Reusing its slot means that the new media description=20 replaces the > old one, but retains its positioning relative to=20 other media > descriptions in the SDP. New media descriptions=20 MUST appear below > any existing media sections. The rules for=20 formatting these media > descriptions are identical to those described in=20 Section 5. > > When the answerer receives an SDP with more media=20 descriptions than > the previous SDP from the offerer, or it receives an=20 SDP with a =20 > media > stream in a slot where the port was previously zero,=20 the answerer > knows that new media streams are being added. =20 These can be =20 > rejected > or accepted by placing an appropriately=20 structured media =20 > description > in the answer. The procedures for constructing=20 the new media > description in the answer are described in Section 6. > > > > > > > > If you look at the examples 1, 2 and 3 at the beginning=20 of the MRCP =20 > specification, a speech recognizer is added to the=20 session but the =20 > m-line for this resource shows up at the beginning of=20 the list. =20 > This should be appended at the end. > > Good catch! =20 > C->S: INVITE=20 sip:mresources@mediaserver.com SIP/=20 > 2.0 Via: SIP/2.0/TCP client.atlanta.example.com:=20 > 5060; branch=3Dz9hG4bK74bf9 =20 Max-Forwards: =20 > 6 To: MediaServer =20 > From: sarvi =20 > ;tag=3D1928301774 Call-ID: =20 > a84b4c76e66710 CSeq: 314163 INVITE =20 Contact: =20 > Content-Type: application/=20 > sdp Content-Length: ... =20 =20 > v=3D0 o=3Dsarvi 2890844526 2890842809 IN IP4 =20 > 126.16.64.4 s=3D- c=3DIN IP4=20 224.2.17.12 =20 > m=3Dapplication 9 TCP/MRCPv2 =20 a=3Dsetup:active =20 > a=3Dconnection:existing a=3Dresource:speechrecog = =20 > a=3Dcmid:1 m=3Dapplication 9 TCP/MRCPv2 = =20 > a=3Dsetup:active a=3Dconnection:existing = =20 > a=3Dresource:speechsynth a=3Dcmid:1 =20 m=3Daudio 49170 =20 > RTP/AVP 0 96 a=3Drtpmap:0 pcmu/8000 =20 a=3Drtpmap:96 telephone-=20 > event/8000 a=3Dfmtp:96 0-15 =20 > a=3Dsendrecv a=3Dmid:1 > > > > > > > Pierre > > > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > =20 =20 =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed May 18 13:06:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYS0H-0006Jb-FB; Wed, 18 May 2005 13:06:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYS06-0006JG-1e for speechsc@megatron.ietf.org; Wed, 18 May 2005 13:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13202 for ; Wed, 18 May 2005 13:06:26 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYSH4-0001iq-Ry for speechsc@ietf.org; Wed, 18 May 2005 13:24:03 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 May 2005 10:06:21 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4IH6HPo027592; Wed, 18 May 2005 10:06:17 -0700 (PDT) Received: from [167.254.254.200] (sjc-vpn6-540.cisco.com [10.21.122.28]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j4IGtWx0004464; Wed, 18 May 2005 09:55:33 -0700 In-Reply-To: <6677B3346233B94EBB11C060935101200B31F55D@vtg-um-e2k1.sj21ad.cisco.com> References: <6677B3346233B94EBB11C060935101200B31F55D@vtg-um-e2k1.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols Date: Wed, 18 May 2005 13:06:07 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.728) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1116435337.9872"; x:"432200"; a:"rsa-sha1"; b:"nofws:8717"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"TkbRiF3x4PSqFHUnEVLd6+/KGZ5c/k7f1ZvOKMw65xPlkcodHWzC9zTyZGD0Z2SCXa7h7DoL" "b3f1iBqHTQ+diYErF+LiVhmPE7W1H3yGrsTiuQ2fu6OTb/zESguavfHJ2gpAUjfHWK/zYBo4W0q" "AYHfQdUrrToORzyCu0kySJcI="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols"; c:"Date: Wed, 18 May 2005 13:06:07 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" , Pierre Forgues X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org On May 18, 2005, at 12:05 PM, Shanmugham, Saravanan wrote: > On Security/TLS I would wait to hear what Dave/Eric have to say. > I think we should not wade into the swamp of what security properties much be selected for other protocols unless there is an MRCP-specific vulnerability introduced. At the moment I can't think of one with SIP. In the case of RTP however, there are specific vulnerabilities and I think we cover those. > I think UDP would be the scalable one. But I am thinking TCP might > help > when working across a NAT. My understanding was that that's why SIP > clients implement TCP. > There are a number of reasons for SIP clients implementing TCP. Fragmentation is one, congestion control is another, NAT traversal is a third (although STUN can and should be used with SIP over UDP to solve that - TCP still doesn't help with the outside-to-inside session initiation problem SIP has), and security is a fourth (unless DTLS is used, which there is as yet no SIP specification for how to use). > Sarvi > > -----Original Message----- > From: Pierre Forgues [mailto:forgues@nuance.com] > Sent: Wednesday, May 18, 2005 8:31 AM > To: Shanmugham, Saravanan; David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 transport > protocols > > I personally don't see the need for securing the SIP > channel as the only information going across are addition > and removal of resources. My preference would be to stay > as standard as possible. The MRCP channel is the one > bearing sensitive information. > > Regarding TCP versus UDP for SIP, I guess I will have to > ask various client-side implementers individually. Even > though the SIP spec allows both, I wonder if we should > simplify implementations by selecting one method in > particular. This would greatly reduce interoperability > combinations across vendors. If the consensus by everyone > is to allow both, then no problem - it's more > interoperability work. > > Pierre > > > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Wednesday, May 18, 2005 11:24 AM > To: Pierre Forgues; David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 transport > protocols > > The SIP client associated with the MRCP server should be a > fully compliant SIP client and we are not adding/removing > anything from that spec. > > Infact, when I think about it we might have to add > additionally that the SIP client associated with MRCP must > also implement TLS if we are to meet security > considerations for Speaker Verification and Idenitifcation. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Pierre > Forgues > Sent: Wednesday, May 18, 2005 8:02 AM > To: David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 > transport protocols > > Hi David, my question was for SIP messages specifically. > I understand the MRCP channel is a reliable TCP connection. > > So my question as a developer of an MRCPv2 server is that > we will receive SIP Invite messages and respond likewise > with capabilities. > These SIP exchanges can occur over TCP or UDP. So my > question is do we need to support BOTH TCP and UDP? I am > guessing the specification is very "general" and therefore > would require that implementations need to support both > because this is what the SIP RFC suggest. > > However, practically I was wondering whether implementers > would bother with both TCP and UDP. I noticed all of the > examples in the spec seem to use TCP only > > " Via: SIP/2.0/TCP client.atlanta.example.com" > > Pierre > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Wednesday, May 18, 2005 10:46 AM > To: Pierre Forgues > Cc: IETF SPEECHSC (E-mail) > Subject: Re: [Speechsc] Questions about MRCPv2 > transport protocols > > > On May 18, 2005, at 9:38 AM, Pierre Forgues wrote: > > >> Hi, I have 2 questions about the latest MRCPv2 >> > specification. > >> >> >> >> Question-1: The examples in the MRCPv2 specification >> > always show > >> TCP as the transport protocol for SIP messages. Do >> > implementers > >> have to support both TCP and UDP? >> > For SIP, right? MRCP of course only runs on a > reliable transport, > with TCP/TLS being mandatory to implement. This > requirement is > completely independent of what transport SIP is running > over. Am I > missing something in your question? > >> Note that the large majority of SIP implementations >> > currently use > >> UDP. I guess a related question is that if both >> > need to be > >> supported, which mode will actually be used by client >> > implementations? > Yes, and all MSRP implementations use TCP. MRCP is as > independent of > the the transport SIP runs on as is MSRP, or any other > media session > established through SIP. Am I missing something? > >> >> >> Question-2: I think the examples in the MRCPv2 >> > specification do not > >> conform to RFC 3264 which states that new m-lines in an >> > SDP should > >> always be added at the end of the existing list. >> > Here is the > >> relevant text (note the text in section 8.1 or RFC 3264): >> >> >> >> 8. Modifying the Session >> >> At any point during the session, either participant >> > MAY issue a new > >> offer to modify characteristics of the session. It is >> fundamental to >> the operation of the offer/answer model that the >> > exact same > >> offer/answer procedure defined above is used for >> > modifying > >> parameters >> of an existing session. >> >> The offer MAY be identical to the last SDP provided >> > to the other > >> party (which may have been provided in an offer or an >> > answer), > >> or it >> MAY be different. We refer to the last SDP >> > provided as the > >> "previous >> SDP". If the offer is the same, the answer MAY be >> > the same as the > >> previous SDP from the answerer, or it MAY be >> > different. If the > >> offered SDP is different from the previous SDP, some >> > constraints > >> are >> placed on its construction, discussed below. >> >> Nearly all aspects of the session can be modified. >> > New streams can > >> be added, existing streams can be deleted, and >> > parameters of > >> existing >> streams can change. When issuing an offer that >> > modifies the > >> session, >> the "o=" line of the new SDP MUST be identical >> > to that in the > >> previous SDP, except that the version in the >> > origin field MUST > >> increment by one from the previous SDP. If the >> > version in the > >> origin >> line does not increment, the SDP MUST be identical to >> > the SDP with > >> that version number. The answerer MUST be prepared >> > to receive an > >> offer that contains SDP with a version that has >> > not changed; > >> this is >> effectively a no-op. However, the answerer MUST >> > generate a valid > >> answer (which MAY be the same as the previous >> > SDP from the > >> answerer, >> or MAY be different), according to the >> > procedures defined in > >> Section >> 6. >> >> If an SDP is offered, which is different from the >> > previous SDP, the > >> new SDP MUST have a matching media stream for each >> > media stream in > >> the previous SDP. In other words, if the previous >> > SDP had N "m=" > >> lines, the new SDP MUST have at least N "m=" lines. >> > The i-th media > >> stream in the previous SDP, counting from the top, >> > matches the i-th > >> media stream in the new SDP, counting from the >> > top. This > >> matching is >> necessary in order for the answerer to determine >> > which stream in > >> the >> new SDP corresponds to a stream in the previous SDP. >> > Because of > >> these requirements, the number of "m=" lines in >> > a stream never > >> decreases, but either stays the same or increases. >> > Deleted media > >> streams from a previous SDP MUST NOT be removed >> > in a new SDP; > >> however, attributes for these streams need not >> > be present. > >> >> 8.1 Adding a Media Stream >> >> New media streams are created by new additional media >> > descriptions > >> below the existing ones, or by reusing the "slot" >> > used by an old > >> media stream which had been disabled by setting its >> > port to zero. > >> >> Reusing its slot means that the new media description >> > replaces the > >> old one, but retains its positioning relative to >> > other media > >> descriptions in the SDP. New media descriptions >> > MUST appear below > >> any existing media sections. The rules for >> > formatting these media > >> descriptions are identical to those described in >> > Section 5. > >> >> When the answerer receives an SDP with more media >> > descriptions than > >> the previous SDP from the offerer, or it receives an >> > SDP with a > >> media >> stream in a slot where the port was previously zero, >> > the answerer > >> knows that new media streams are being added. >> > These can be > >> rejected >> or accepted by placing an appropriately >> > structured media > >> description >> in the answer. The procedures for constructing >> > the new media > >> description in the answer are described in Section 6. >> >> >> >> >> >> >> >> If you look at the examples 1, 2 and 3 at the beginning >> > of the MRCP > >> specification, a speech recognizer is added to the >> > session but the > >> m-line for this resource shows up at the beginning of >> > the list. > >> This should be appended at the end. >> >> >> > Good catch! > > >> C->S: INVITE >> > sip:mresources@mediaserver.com SIP/ > >> 2.0 Via: SIP/2.0/TCP client.atlanta.example.com: >> 5060; branch=z9hG4bK74bf9 >> > Max-Forwards: > >> 6 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=application 9 TCP/MRCPv2 >> > a=setup:active > >> a=connection:existing a=resource:speechrecog >> > > >> a=cmid:1 m=application 9 TCP/MRCPv2 >> a=setup:active a=connection:existing >> a=resource:speechsynth a=cmid:1 >> > 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 a=mid:1 >> >> >> >> >> >> >> Pierre >> >> >> >> >> >> _______________________________________________ >> 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 speechsc-bounces@ietf.org Wed May 18 13:38:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSUv-0006np-NR; Wed, 18 May 2005 13:38:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSUt-0006nk-PK for speechsc@megatron.ietf.org; Wed, 18 May 2005 13:38:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16322 for ; Wed, 18 May 2005 13:38:18 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYSlq-00035Z-9I for speechsc@ietf.org; Wed, 18 May 2005 13:55:50 -0400 Received: from postcard.nuance.com ([10.3.6.20]:18996) by letter.nuance.com with esmtp id 1DYSUh-0007O8-8i; Wed, 18 May 2005 10:38:07 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 May 2005 13:37:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols Date: Wed, 18 May 2005 13:37:05 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802B97F28@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] Questions about MRCPv2 transport protocols Thread-Index: AcVby83zMk8t0w1PSkCxkj387AanegAA9f/g From: "Pierre Forgues" To: "David R. Oran" , "Shanmugham, Saravanan" X-OriginalArrivalTime: 18 May 2005 17:37:08.0795 (UTC) FILETIME=[373C48B0:01C55BD0] X-FromHost: postcard.nuance.com [10.3.6.20]:18996 Lines: 520 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3da7e5d5ca82d58872786934e4963616 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Agreed on the security swamp. We will assume standard SIP channels with no extra security. You also make excellent points for favoring TCP. Anyway, if we are not going to restrict it to TCP at the MRCP specification level, then it will leave interpretation to either TCP or UDP. I will follow-up with implementers to see if we really need to support (and test interoperability) for both UDP and TCP. Pierre -----Original Message----- From: David R. Oran [mailto:oran@cisco.com]=20 Sent: Wednesday, May 18, 2005 1:06 PM To: Shanmugham, Saravanan Cc: Pierre Forgues; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols On May 18, 2005, at 12:05 PM, Shanmugham, Saravanan wrote: > On Security/TLS I would wait to hear what Dave/Eric have to say. > I think we should not wade into the swamp of what security properties =20 much be selected for other protocols unless there is an MRCP-specific =20 vulnerability introduced. At the moment I can't think of one with =20 SIP. In the case of RTP however, there are specific vulnerabilities =20 and I think we cover those. > I think UDP would be the scalable one. But I am thinking TCP might =20 > help > when working across a NAT. My understanding was that that's why SIP > clients implement TCP. > There are a number of reasons for SIP clients implementing TCP. =20 Fragmentation is one, congestion control is another, NAT traversal is =20 a third (although STUN can and should be used with SIP over UDP to =20 solve that - TCP still doesn't help with the outside-to-inside =20 session initiation problem SIP has), and security is a fourth (unless =20 DTLS is used, which there is as yet no SIP specification for how to =20 use). > Sarvi > > -----Original Message----- > From: Pierre Forgues [mailto:forgues@nuance.com] > Sent: Wednesday, May 18, 2005 8:31 AM > To: Shanmugham, Saravanan; David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 transport =20 > protocols > > I personally don't see the need for securing the SIP > channel as the only information going across are addition > and removal of resources. My preference would be to stay > as standard as possible. The MRCP channel is the one > bearing sensitive information. > > Regarding TCP versus UDP for SIP, I guess I will have to > ask various client-side implementers individually. Even > though the SIP spec allows both, I wonder if we should > simplify implementations by selecting one method in > particular. This would greatly reduce interoperability > combinations across vendors. If the consensus by everyone > is to allow both, then no problem - it's more > interoperability work. > > Pierre > > > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Wednesday, May 18, 2005 11:24 AM > To: Pierre Forgues; David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 transport =20 > protocols > > The SIP client associated with the MRCP server should be a > fully compliant SIP client and we are not adding/removing > anything from that spec. > > Infact, when I think about it we might have to add > additionally that the SIP client associated with MRCP must > also implement TLS if we are to meet security > considerations for Speaker Verification and Idenitifcation. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Pierre =20 > Forgues > Sent: Wednesday, May 18, 2005 8:02 AM > To: David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 > transport protocols > > Hi David, my question was for SIP messages specifically. > I understand the MRCP channel is a reliable TCP connection. > > So my question as a developer of an MRCPv2 server is that > we will receive SIP Invite messages and respond likewise > with capabilities. > These SIP exchanges can occur over TCP or UDP. So my > question is do we need to support BOTH TCP and UDP? I am > guessing the specification is very "general" and therefore > would require that implementations need to support both > because this is what the SIP RFC suggest. > > However, practically I was wondering whether implementers > would bother with both TCP and UDP. I noticed all of the > examples in the spec seem to use TCP only > > " Via: SIP/2.0/TCP client.atlanta.example.com" > > Pierre > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Wednesday, May 18, 2005 10:46 AM > To: Pierre Forgues > Cc: IETF SPEECHSC (E-mail) > Subject: Re: [Speechsc] Questions about MRCPv2 > transport protocols > > > On May 18, 2005, at 9:38 AM, Pierre Forgues wrote: > > >> Hi, I have 2 questions about the latest MRCPv2 >> > specification. > >> >> >> >> Question-1: The examples in the MRCPv2 specification >> > always show > >> TCP as the transport protocol for SIP messages. Do >> > implementers > >> have to support both TCP and UDP? >> > For SIP, right? MRCP of course only runs on a > reliable transport, > with TCP/TLS being mandatory to implement. This > requirement is > completely independent of what transport SIP is running > over. Am I > missing something in your question? > >> Note that the large majority of SIP implementations >> > currently use > >> UDP. I guess a related question is that if both >> > need to be > >> supported, which mode will actually be used by client >> > implementations? > Yes, and all MSRP implementations use TCP. MRCP is as > independent of > the the transport SIP runs on as is MSRP, or any other > media session > established through SIP. Am I missing something? > >> >> >> Question-2: I think the examples in the MRCPv2 >> > specification do not > >> conform to RFC 3264 which states that new m-lines in an >> > SDP should > >> always be added at the end of the existing list. >> > Here is the > >> relevant text (note the text in section 8.1 or RFC 3264): >> >> >> >> 8. Modifying the Session >> >> At any point during the session, either participant >> > MAY issue a new > >> offer to modify characteristics of the session. It is >> fundamental to >> the operation of the offer/answer model that the >> > exact same > >> offer/answer procedure defined above is used for >> > modifying > >> parameters >> of an existing session. >> >> The offer MAY be identical to the last SDP provided >> > to the other > >> party (which may have been provided in an offer or an >> > answer), > >> or it >> MAY be different. We refer to the last SDP >> > provided as the > >> "previous >> SDP". If the offer is the same, the answer MAY be >> > the same as the > >> previous SDP from the answerer, or it MAY be >> > different. If the > >> offered SDP is different from the previous SDP, some >> > constraints > >> are >> placed on its construction, discussed below. >> >> Nearly all aspects of the session can be modified. >> > New streams can > >> be added, existing streams can be deleted, and >> > parameters of > >> existing >> streams can change. When issuing an offer that >> > modifies the > >> session, >> the "o=3D" line of the new SDP MUST be identical >> > to that in the > >> previous SDP, except that the version in the >> > origin field MUST > >> increment by one from the previous SDP. If the >> > version in the > >> origin >> line does not increment, the SDP MUST be identical to >> > the SDP with > >> that version number. The answerer MUST be prepared >> > to receive an > >> offer that contains SDP with a version that has >> > not changed; > >> this is >> effectively a no-op. However, the answerer MUST >> > generate a valid > >> answer (which MAY be the same as the previous >> > SDP from the > >> answerer, >> or MAY be different), according to the >> > procedures defined in > >> Section >> 6. >> >> If an SDP is offered, which is different from the >> > previous SDP, the > >> new SDP MUST have a matching media stream for each >> > media stream in > >> the previous SDP. In other words, if the previous >> > SDP had N "m=3D" > >> lines, the new SDP MUST have at least N "m=3D" lines. >> > The i-th media > >> stream in the previous SDP, counting from the top, >> > matches the i-th > >> media stream in the new SDP, counting from the >> > top. This > >> matching is >> necessary in order for the answerer to determine >> > which stream in > >> the >> new SDP corresponds to a stream in the previous SDP. >> > Because of > >> these requirements, the number of "m=3D" lines in >> > a stream never > >> decreases, but either stays the same or increases. >> > Deleted media > >> streams from a previous SDP MUST NOT be removed >> > in a new SDP; > >> however, attributes for these streams need not >> > be present. > >> >> 8.1 Adding a Media Stream >> >> New media streams are created by new additional media >> > descriptions > >> below the existing ones, or by reusing the "slot" >> > used by an old > >> media stream which had been disabled by setting its >> > port to zero. > >> >> Reusing its slot means that the new media description >> > replaces the > >> old one, but retains its positioning relative to >> > other media > >> descriptions in the SDP. New media descriptions >> > MUST appear below > >> any existing media sections. The rules for >> > formatting these media > >> descriptions are identical to those described in >> > Section 5. > >> >> When the answerer receives an SDP with more media >> > descriptions than > >> the previous SDP from the offerer, or it receives an >> > SDP with a > >> media >> stream in a slot where the port was previously zero, >> > the answerer > >> knows that new media streams are being added. >> > These can be > >> rejected >> or accepted by placing an appropriately >> > structured media > >> description >> in the answer. The procedures for constructing >> > the new media > >> description in the answer are described in Section 6. >> >> >> >> >> >> >> >> If you look at the examples 1, 2 and 3 at the beginning >> > of the MRCP > >> specification, a speech recognizer is added to the >> > session but the > >> m-line for this resource shows up at the beginning of >> > the list. > >> This should be appended at the end. >> >> >> > Good catch! > > >> C->S: INVITE >> > sip:mresources@mediaserver.com SIP/ > >> 2.0 Via: SIP/2.0/TCP client.atlanta.example.com: >> 5060; branch=3Dz9hG4bK74bf9 >> > Max-Forwards: > >> 6 To: MediaServer >> From: sarvi >> ;tag=3D1928301774 Call-ID: >> a84b4c76e66710 CSeq: 314163 INVITE >> > Contact: > >> Content-Type: application/ >> sdp Content-Length: ... >> > > >> v=3D0 o=3Dsarvi 2890844526 2890842809 IN IP4 >> 126.16.64.4 s=3D- c=3DIN IP4 >> > 224.2.17.12 > >> m=3Dapplication 9 TCP/MRCPv2 >> > a=3Dsetup:active > >> a=3Dconnection:existing a=3Dresource:speechrecog >> > > >> a=3Dcmid:1 m=3Dapplication 9 TCP/MRCPv2 >> a=3Dsetup:active a=3Dconnection:existing >> a=3Dresource:speechsynth a=3Dcmid:1 >> > m=3Daudio 49170 > >> RTP/AVP 0 96 a=3Drtpmap:0 pcmu/8000 >> > a=3Drtpmap:96 telephone- > >> event/8000 a=3Dfmtp:96 0-15 >> a=3Dsendrecv a=3Dmid:1 >> >> >> >> >> >> >> Pierre >> >> >> >> >> >> _______________________________________________ >> 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 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed May 18 13:52:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSiv-0002u6-O0; Wed, 18 May 2005 13:52:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYSiu-0002ty-SW; Wed, 18 May 2005 13:52:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17723; Wed, 18 May 2005 13:52:45 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYSzs-0003gK-0V; Wed, 18 May 2005 14:10:21 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4IHqR0c154062; Wed, 18 May 2005 13:52:27 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4IHqRrR222178; Wed, 18 May 2005 11:52:27 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4IHqRHe008843; Wed, 18 May 2005 11:52:27 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4IHqRnF008840; Wed, 18 May 2005 11:52:27 -0600 In-Reply-To: <7DE7C4EF3B7C8B4B82955191378290D802B97F28@mtb1exch01.nuance.com> To: "Pierre Forgues" MIME-Version: 1.0 Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 18 May 2005 13:52:24 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 05/18/2005 11:52:27, Serialize complete at 05/18/2005 11:52:27 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bd14a31ed5bce9138736cf0e98bb014 Cc: "IETF SPEECHSC \(E-mail\)" , "Shanmugham, Saravanan" , "David R. Oran" , speechsc-bounces@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi, I would vote to not add convolution to the MRCPv2 specification with transport specifics for the session control, but rather leverage the referenced specification for these specific details (in this particular case RFC 3261). Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ (561) 862-2097 T/L (975) gavagni@us.ibm.com "Pierre Forgues" Sent by: speechsc-bounces@ietf.org 05/18/2005 01:37 PM To "David R. Oran" , "Shanmugham, Saravanan" cc "IETF SPEECHSC \(E-mail\)" Subject RE: [Speechsc] Questions about MRCPv2 transport protocols Agreed on the security swamp. We will assume standard SIP channels with no extra security. You also make excellent points for favoring TCP. Anyway, if we are not going to restrict it to TCP at the MRCP specification level, then it will leave interpretation to either TCP or UDP. I will follow-up with implementers to see if we really need to support (and test interoperability) for both UDP and TCP. Pierre -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Wednesday, May 18, 2005 1:06 PM To: Shanmugham, Saravanan Cc: Pierre Forgues; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols On May 18, 2005, at 12:05 PM, Shanmugham, Saravanan wrote: > On Security/TLS I would wait to hear what Dave/Eric have to say. > I think we should not wade into the swamp of what security properties much be selected for other protocols unless there is an MRCP-specific vulnerability introduced. At the moment I can't think of one with SIP. In the case of RTP however, there are specific vulnerabilities and I think we cover those. > I think UDP would be the scalable one. But I am thinking TCP might > help > when working across a NAT. My understanding was that that's why SIP > clients implement TCP. > There are a number of reasons for SIP clients implementing TCP. Fragmentation is one, congestion control is another, NAT traversal is a third (although STUN can and should be used with SIP over UDP to solve that - TCP still doesn't help with the outside-to-inside session initiation problem SIP has), and security is a fourth (unless DTLS is used, which there is as yet no SIP specification for how to use). > Sarvi > > -----Original Message----- > From: Pierre Forgues [mailto:forgues@nuance.com] > Sent: Wednesday, May 18, 2005 8:31 AM > To: Shanmugham, Saravanan; David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 transport > protocols > > I personally don't see the need for securing the SIP > channel as the only information going across are addition > and removal of resources. My preference would be to stay > as standard as possible. The MRCP channel is the one > bearing sensitive information. > > Regarding TCP versus UDP for SIP, I guess I will have to > ask various client-side implementers individually. Even > though the SIP spec allows both, I wonder if we should > simplify implementations by selecting one method in > particular. This would greatly reduce interoperability > combinations across vendors. If the consensus by everyone > is to allow both, then no problem - it's more > interoperability work. > > Pierre > > > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Wednesday, May 18, 2005 11:24 AM > To: Pierre Forgues; David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 transport > protocols > > The SIP client associated with the MRCP server should be a > fully compliant SIP client and we are not adding/removing > anything from that spec. > > Infact, when I think about it we might have to add > additionally that the SIP client associated with MRCP must > also implement TLS if we are to meet security > considerations for Speaker Verification and Idenitifcation. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Pierre > Forgues > Sent: Wednesday, May 18, 2005 8:02 AM > To: David R. Oran > Cc: IETF SPEECHSC (E-mail) > Subject: RE: [Speechsc] Questions about MRCPv2 > transport protocols > > Hi David, my question was for SIP messages specifically. > I understand the MRCP channel is a reliable TCP connection. > > So my question as a developer of an MRCPv2 server is that > we will receive SIP Invite messages and respond likewise > with capabilities. > These SIP exchanges can occur over TCP or UDP. So my > question is do we need to support BOTH TCP and UDP? I am > guessing the specification is very "general" and therefore > would require that implementations need to support both > because this is what the SIP RFC suggest. > > However, practically I was wondering whether implementers > would bother with both TCP and UDP. I noticed all of the > examples in the spec seem to use TCP only > > " Via: SIP/2.0/TCP client.atlanta.example.com" > > Pierre > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Wednesday, May 18, 2005 10:46 AM > To: Pierre Forgues > Cc: IETF SPEECHSC (E-mail) > Subject: Re: [Speechsc] Questions about MRCPv2 > transport protocols > > > On May 18, 2005, at 9:38 AM, Pierre Forgues wrote: > > >> Hi, I have 2 questions about the latest MRCPv2 >> > specification. > >> >> >> >> Question-1: The examples in the MRCPv2 specification >> > always show > >> TCP as the transport protocol for SIP messages. Do >> > implementers > >> have to support both TCP and UDP? >> > For SIP, right? MRCP of course only runs on a > reliable transport, > with TCP/TLS being mandatory to implement. This > requirement is > completely independent of what transport SIP is running > over. Am I > missing something in your question? > >> Note that the large majority of SIP implementations >> > currently use > >> UDP. I guess a related question is that if both >> > need to be > >> supported, which mode will actually be used by client >> > implementations? > Yes, and all MSRP implementations use TCP. MRCP is as > independent of > the the transport SIP runs on as is MSRP, or any other > media session > established through SIP. Am I missing something? > >> >> >> Question-2: I think the examples in the MRCPv2 >> > specification do not > >> conform to RFC 3264 which states that new m-lines in an >> > SDP should > >> always be added at the end of the existing list. >> > Here is the > >> relevant text (note the text in section 8.1 or RFC 3264): >> >> >> >> 8. Modifying the Session >> >> At any point during the session, either participant >> > MAY issue a new > >> offer to modify characteristics of the session. It is >> fundamental to >> the operation of the offer/answer model that the >> > exact same > >> offer/answer procedure defined above is used for >> > modifying > >> parameters >> of an existing session. >> >> The offer MAY be identical to the last SDP provided >> > to the other > >> party (which may have been provided in an offer or an >> > answer), > >> or it >> MAY be different. We refer to the last SDP >> > provided as the > >> "previous >> SDP". If the offer is the same, the answer MAY be >> > the same as the > >> previous SDP from the answerer, or it MAY be >> > different. If the > >> offered SDP is different from the previous SDP, some >> > constraints > >> are >> placed on its construction, discussed below. >> >> Nearly all aspects of the session can be modified. >> > New streams can > >> be added, existing streams can be deleted, and >> > parameters of > >> existing >> streams can change. When issuing an offer that >> > modifies the > >> session, >> the "o=" line of the new SDP MUST be identical >> > to that in the > >> previous SDP, except that the version in the >> > origin field MUST > >> increment by one from the previous SDP. If the >> > version in the > >> origin >> line does not increment, the SDP MUST be identical to >> > the SDP with > >> that version number. The answerer MUST be prepared >> > to receive an > >> offer that contains SDP with a version that has >> > not changed; > >> this is >> effectively a no-op. However, the answerer MUST >> > generate a valid > >> answer (which MAY be the same as the previous >> > SDP from the > >> answerer, >> or MAY be different), according to the >> > procedures defined in > >> Section >> 6. >> >> If an SDP is offered, which is different from the >> > previous SDP, the > >> new SDP MUST have a matching media stream for each >> > media stream in > >> the previous SDP. In other words, if the previous >> > SDP had N "m=" > >> lines, the new SDP MUST have at least N "m=" lines. >> > The i-th media > >> stream in the previous SDP, counting from the top, >> > matches the i-th > >> media stream in the new SDP, counting from the >> > top. This > >> matching is >> necessary in order for the answerer to determine >> > which stream in > >> the >> new SDP corresponds to a stream in the previous SDP. >> > Because of > >> these requirements, the number of "m=" lines in >> > a stream never > >> decreases, but either stays the same or increases. >> > Deleted media > >> streams from a previous SDP MUST NOT be removed >> > in a new SDP; > >> however, attributes for these streams need not >> > be present. > >> >> 8.1 Adding a Media Stream >> >> New media streams are created by new additional media >> > descriptions > >> below the existing ones, or by reusing the "slot" >> > used by an old > >> media stream which had been disabled by setting its >> > port to zero. > >> >> Reusing its slot means that the new media description >> > replaces the > >> old one, but retains its positioning relative to >> > other media > >> descriptions in the SDP. New media descriptions >> > MUST appear below > >> any existing media sections. The rules for >> > formatting these media > >> descriptions are identical to those described in >> > Section 5. > >> >> When the answerer receives an SDP with more media >> > descriptions than > >> the previous SDP from the offerer, or it receives an >> > SDP with a > >> media >> stream in a slot where the port was previously zero, >> > the answerer > >> knows that new media streams are being added. >> > These can be > >> rejected >> or accepted by placing an appropriately >> > structured media > >> description >> in the answer. The procedures for constructing >> > the new media > >> description in the answer are described in Section 6. >> >> >> >> >> >> >> >> If you look at the examples 1, 2 and 3 at the beginning >> > of the MRCP > >> specification, a speech recognizer is added to the >> > session but the > >> m-line for this resource shows up at the beginning of >> > the list. > >> This should be appended at the end. >> >> >> > Good catch! > > >> C->S: INVITE >> > sip:mresources@mediaserver.com SIP/ > >> 2.0 Via: SIP/2.0/TCP client.atlanta.example.com: >> 5060; branch=z9hG4bK74bf9 >> > Max-Forwards: > >> 6 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=application 9 TCP/MRCPv2 >> > a=setup:active > >> a=connection:existing a=resource:speechrecog >> > > >> a=cmid:1 m=application 9 TCP/MRCPv2 >> a=setup:active a=connection:existing >> a=resource:speechsynth a=cmid:1 >> > 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 a=mid:1 >> >> >> >> >> >> >> Pierre >> >> >> >> >> >> _______________________________________________ >> 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 speechsc-bounces@ietf.org Wed May 18 18:15:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYWpQ-0005Pz-Ej; Wed, 18 May 2005 18:15:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYWpO-0005L9-H4 for speechsc@megatron.ietf.org; Wed, 18 May 2005 18:15:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28363 for ; Wed, 18 May 2005 18:15:43 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYX6Q-0003DT-AK for speechsc@ietf.org; Wed, 18 May 2005 18:33:22 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j4IM95l4009613; Wed, 18 May 2005 18:09:05 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 May 2005 18:04:31 -0400 Message-ID: From: Eric Burger To: "David R. Oran" Subject: RE: [Speechsc] Contiguous Request-ID's Date: Wed, 18 May 2005 18:04:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: speechsc@ietf.org, "Shanmugham, Saravanan" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Works for me. > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Wednesday, May 18, 2005 12:04 AM > To: Eric Burger > Cc: Shanmugham, Saravanan; speechsc@ietf.org > Subject: Re: [Speechsc] Contiguous Request-ID's > > I think the Postel dictum should guide us here which leads me > to and to separate transmitter and receiver behavior. Any > request-id scheme puts the burden on the receiver to detect > duplicates. If there is no ordering requirement on > request-ids, then the receiver state needed is O(M), where M > is the maximum number of requests that might ever be sent in > a session. At the other extreme, requiring contiguous > monotonic request sequencing winds up either having startup > ambiguity (what is the first request of a session contiguous > to?) or also mandating an initial request number (e.g. 1) for > a session and opens up all the off-by-one style errors. > > Specifying monotonic requests tends to be the best compromise > - it allows duplicate or misordering-through-transmitter-bug > detection with O(1) state at the receiver. Lastly, the size > of course needs to be big enough so that you don't need > modular arithmetic and window computations for them. > > So, the above is the long way of saying I think we should do > (2), and reject duplicate and out-of-order requests with a > well-defined error. > > Dave. > > On May 17, 2005, at 5:00 PM, Eric Burger wrote: > > > Consider what happens if there is wording in the spec that says > > Request-ID's MUST be contiguous. Let us say a server receives an > > out-of-order Request-ID. Moreover, the spec remains silent > on what to > > do. > > > > > > I can imagine that some servers will happily accept the > request. They > > "know" that there really is not a requirement for contiguous > > Request-ID's. > > It doesn't matter. > > > > I can imagine that other servers, especially those written by folks > > that were not involved in this conversation, that will reject the > > request. The spec says Request-ID's MUST be contiguous, > and clearly > > something very bad has happened -- a message got lost over > a reliable > > transport connection. > > > > Now things get even more interesting. Since something 'very bad' > > happened, > > and the spec is silent, some servers will reject the request, while > > others will tear down the entire MRCPv2 session. Others > may kill all > > MRCPv2 sessions with that server. > > > > > > The point is that if we don't specify actions, we will get > > incompatible > > implementations. > > > > > >> -----Original Message----- > >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > >> Sent: Tuesday, May 17, 2005 9:55 AM > >> To: Eric Burger; speechsc@ietf.org > >> Subject: RE: [Speechsc] Contiguous Request-ID's > >> > >> I don't mind rmoving these restrictions. But I don't see what > >> this change gets us or avoids. Is there anything specific you > >> are trying address here. If not, I would be inclined to leave > >> it as is. > >> > >> Sarvi > >> > >> -----Original Message----- > >> From: speechsc-bounces@ietf.org > >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Eric Burger > >> Sent: Tuesday, May 17, 2005 1:21 AM > >> To: speechsc@ietf.org > >> Subject: [Speechsc] Contiguous Request-ID's > >> > >> Section 5.1, Request: > >> Why must request-id's be contiguous? Monotonically > >> increasing makes sense. > >> Do we have a mechanism for handling out-of-order requests? > >> However, contiguous request-id's imply some mechanism for > >> dealing with missing requests, which I don't think we > >> have. I would either fill-in the mechanisms (with > >> justification for the complexity) or relax the > >> requirements appropriately. Either: > >> > >> 1. Keep contiguous (incrementing by 1). Explain why. > >> Explain mechanisms for handling missing and out-of-order > >> requests. > >> > >> 2. Keep monotonically increasing. Explain mechanisms for > >> handling out-of-order requests. > >> > >> 3. Keep unique. > >> > >> I vote for #3, unless there are use cases for ordering > >> requests that arrive over reliable, ordered transports > >> (TCP, SCTP-Connection-Mode). _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed May 25 03:57:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqlJ-0001iV-Ua; Wed, 25 May 2005 03:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqlI-0001iL-Nr for speechsc@megatron.ietf.org; Wed, 25 May 2005 03:57:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16724 for ; Wed, 25 May 2005 03:57:07 -0400 (EDT) Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dar3d-0005Bo-7w for Speechsc@ietf.org; Wed, 25 May 2005 04:16:06 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH10079ICPGTC@tid.hi.inet> for Speechsc@ietf.org; Wed, 25 May 2005 09:56:05 +0200 (MEST) Received: from tid.es (valldigna.hi.inet [10.95.12.129]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH10079FCPGTC@tid.hi.inet> for Speechsc@ietf.org; Wed, 25 May 2005 09:56:04 +0200 (MEST) Date: Wed, 25 May 2005 09:53:24 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Bernat_Vercher?= To: Speechsc@ietf.org Message-id: <42942EF4.9060902@tid.es> Organization: =?iso-8859-1?Q?Telef=F3nica_I=2BD?= MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: es-es, es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:1.6) Gecko/20040113 X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:16 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Cc: Subject: [Speechsc] Question for Voice-category X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hello all: In page 37 of the current draft, it appears the definition of the "Voice-Parameters" as: voice-parameter = "Voice-" voice-param-name ":" voice-param-value CRLF voice-param-name is any one of the attribute names under the voice element specified in W3C's Speech Synthesis Markup Language Specification[10]. I've not been able to find "category" in the current SSML Specification. Where is the voice-category defined? Thanks: Jesus. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu May 26 10:37:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbJU5-0006yD-Ly; Thu, 26 May 2005 10:37:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbJU4-0006xI-AE for speechsc@megatron.ietf.org; Thu, 26 May 2005 10:37:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03557 for ; Thu, 26 May 2005 10:37:13 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbJmZ-0002U1-OI for Speechsc@ietf.org; Thu, 26 May 2005 10:56:30 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IH300B3XPCJ7B@dns2.cselt.it> for Speechsc@ietf.org; Thu, 26 May 2005 16:24:19 +0200 (MEST) Received: from EXC05A.cselt.it ([163.162.36.249]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 16:35:44 +0200 Date: Thu, 26 May 2005 16:36:47 +0200 From: Baggia Paolo Subject: RE: [Speechsc] Question for Voice-category To: =?iso-8859-1?Q?Jes=FAs_Bernat_Vercher?= , Speechsc@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Speechsc] Question for Voice-category Thread-Index: AcVg/9qmJLxxpNeCQeGt/a7maBs4JAA/AQyw Content-class: urn:content-classes:message X-OriginalArrivalTime: 26 May 2005 14:35:44.0890 (UTC) FILETIME=[333A2DA0:01C56200] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: Baggia Paolo X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Dear Jesus, I think the "voice-category" is small bug in the MRCPv2. It was in SSML Spec times ago in WD, see: http://www.w3.org/TR/2001/WD-speech-synthesis-20010103/ But it is no more there in the following WD: http://www.w3.org/TR/2002/WD-speech-synthesis-20020405/ and from them to the W3C Rec. So the example need to be fixed with some other attributes present in the W3C Recommendation in: http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/#S3.2.1 such as: "age", "variant", etc. Paolo. -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org]On Behalf Of Jes=FAs Bernat Vercher Sent: Wednesday, May 25, 2005 9:53 AM To: Speechsc@ietf.org Subject: [Speechsc] Question for Voice-category Hello all: In page 37 of the current draft, it appears the definition of the=20 "Voice-Parameters" as: voice-parameter =3D "Voice-" voice-param-name ":" voice-param-value CRLF =20 voice-param-name is any one of the attribute names under the voice element specified in W3C's Speech Synthesis Markup Language Specification[10]. I've not been able to find "category" in the current SSML = Specification. Where is the voice-category defined? Thanks: Jesus. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu May 26 12:03:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKpB-0004qF-9i; Thu, 26 May 2005 12:03:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKp9-0004qA-9H for speechsc@megatron.ietf.org; Thu, 26 May 2005 12:03:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08744 for ; Thu, 26 May 2005 12:03:04 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbL7l-0004QL-R4 for speechsc@ietf.org; Thu, 26 May 2005 12:22:22 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 May 2005 09:02:57 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4QG2qbw019555; Thu, 26 May 2005 09:02:52 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Speechsc] Question for Voice-category Date: Thu, 26 May 2005 09:04:39 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B531A26@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Question for Voice-category Thread-Index: AcVg/9qmJLxxpNeCQeGt/a7maBs4JAA/AQywAAQa3MA= From: "Shanmugham, Saravanan" To: "Baggia Paolo" , =?iso-8859-1?Q?Jes=FAs_Bernat_Vercher?= , X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Will cover that in the next draft. Thanks for the pointer. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Baggia Paolo Sent: Thursday, May 26, 2005 7:37 AM To: Jes=FAs Bernat Vercher; Speechsc@ietf.org Cc: Baggia Paolo Subject: RE: [Speechsc] Question for Voice-category =20 Dear Jesus, =20 I think the "voice-category" is small bug in the MRCPv2. =20 It was in SSML Spec times ago in WD, see: http://www.w3.org/TR/2001/WD-speech-synthesis-20010103/ =20 But it is no more there in the following WD: http://www.w3.org/TR/2002/WD-speech-synthesis-20020405/ and from them to the W3C Rec. =20 So the example need to be fixed with some other attributes=20 present in the W3C Recommendation in: http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/#S3.2.1 such as: "age", "variant", etc. =20 Paolo. =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org]On Behalf Of Jes=FAs Bernat Vercher Sent: Wednesday, May 25, 2005 9:53 AM To: Speechsc@ietf.org Subject: [Speechsc] Question for Voice-category =20 =20 Hello all: =20 In page 37 of the current draft, it appears the=20 definition of the "Voice-Parameters" as: =20 voice-parameter =3D "Voice-" voice-param-name ":" voice-param-value CRLF =20 voice-param-name is any one of the attribute names=20 under the voice element specified in W3C's Speech Synthesis Markup Language Specification[10]. =20 I've not been able to find "category" in the current=20 SSML Specification. Where is the voice-category defined? =20 Thanks: =20 Jesus. =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 Gruppo Telecom Italia - Direzione e coordinamento di=20 Telecom Italia S.p.A. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to=20 the persons above and may contain confidential=20 information. If you have received the message in error, be=20 informed that any use of the content hereof is prohibited.=20 Please return it immediately to the sender and delete the=20 message. Should you have any questions, please send an=20 e_mail to MailAdmin@tilab.com. Thank you=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =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 From speechsc-bounces@ietf.org Thu May 26 12:09:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKvN-0005YU-W9; Thu, 26 May 2005 12:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKvN-0005YP-6u for speechsc@megatron.ietf.org; Thu, 26 May 2005 12:09:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09223 for ; Thu, 26 May 2005 12:09:30 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbLDy-0004aO-OJ for Speechsc@ietf.org; Thu, 26 May 2005 12:28:48 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IH300056U33C4@dns1.cselt.it> for Speechsc@ietf.org; Thu, 26 May 2005 18:06:39 +0200 (MEST) Received: from EXC05A.cselt.it ([163.162.36.249]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 18:12:31 +0200 Date: Thu, 26 May 2005 18:09:20 +0200 From: Manzone Vittorio To: Speechsc@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: RECOGNIZE queueing: missing event? Thread-Index: AcViDUYp1LgnPHzvTvui4qwSgow5LA== Content-class: urn:content-classes:message X-OriginalArrivalTime: 26 May 2005 16:12:31.0640 (UTC) FILETIME=[B851E980:01C5620D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Subject: [Speechsc] RECOGNIZE queueing: missing event? X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org hi,=20 when server receives a queued RECOGNIZE, it sends a response to client = with PENDING request-state. When actual RECOGNIZE ends, server signal = event to client with RECOGNITION-COMPLETE event, but has actually no = event to signal to the client that new RECOGNIZE has started.=20 In Synthesis resource, this work is done by SPEECH-MARKER event with = marker value=3D"", in Recognition resource, this event is missing. Similar question is present on Verification resource, when both = recognition and verification resources shares the same session: when = server receives a VERIFY, it send a PENDING response to client (it's = waiting for the next RECOGNIZE), but when it receives RECOGNIZE, it has = no event to signal to client that VERIFY has moved to IN-PROGRESS-STATE. In order to solve this problem, we should define some event as = RECOGNITION-STARTED and VERIFICATION-STARTED, which have the meaning of = the moment in which audio samples can be sent to the recognition = resource. Vittorio Manzone=20 +39 011 2913470 vittorio.manzone@loquendo.com Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu May 26 12:09:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKvP-0005ZH-8i; Thu, 26 May 2005 12:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKvO-0005Ys-5X for speechsc@megatron.ietf.org; Thu, 26 May 2005 12:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09226 for ; Thu, 26 May 2005 12:09:31 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbLDy-0004Zi-MZ for Speechsc@ietf.org; Thu, 26 May 2005 12:28:49 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IH300M9KU2XVA@dns1.cselt.it> for Speechsc@ietf.org; Thu, 26 May 2005 18:06:33 +0200 (MEST) Received: from EXC05A.cselt.it ([163.162.36.249]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 18:12:25 +0200 Date: Thu, 26 May 2005 18:09:13 +0200 From: Manzone Vittorio To: Speechsc@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: barge-in-able event clarification Thread-Index: AcViDUJ9zkLKEUA4Q4iTjJ6TaPeIDg== Content-class: urn:content-classes:message X-OriginalArrivalTime: 26 May 2005 16:12:25.0531 (UTC) FILETIME=[B4ADC0B0:01C5620D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Subject: [Speechsc] barge-in-able event clarification X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org hi,=20 we need a clarification about barge-in-able events: in BARGE-IN-OCCURRED method description, only START-OF-SPEECH event is = mentioned as event that can drive barge-in actions. However, in hotword recognition this event will never be generated, and = the only event that can drive barge-in is RECOGNITION-COMPLETE, for = which is not described proxy-sync-id header usage: if client wants to = stop SPEAK method, it can do it with the STOP method only, because it = has no valid proxy-sync-id header to send to the server in a = BARGE-IN-OCCURRED method. In this way, client cannot stop SPEAK methods = depending on Kill-On-Barge-In header. In order to solve this problem, we can consider also = RECOGNITION-COMPLETE as a barge-in-able event, and document = proxy-sync-id usage in its description. In normal recognition (non hotword), START-OF-SPEECH and = RECOGNITION-COMPLETE events should carry the same proxy-sync-id header, = in order to stop synthesis only on the first event. Vittorio Manzone=20 +39 011 2913470 vittorio.manzone@loquendo.com Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu May 26 17:11:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPdn-0006ML-KN; Thu, 26 May 2005 17:11:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPdm-0006MB-ML for speechsc@megatron.ietf.org; Thu, 26 May 2005 17:11:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12819 for ; Thu, 26 May 2005 17:11:39 -0400 (EDT) Received: from mail02.corp.tellme.com ([209.157.157.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbPwQ-0006s8-Qb for Speechsc@ietf.org; Thu, 26 May 2005 17:31:00 -0400 Received: from mail02.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id 77CA6350B for ; Thu, 26 May 2005 14:11:28 -0700 (PDT) Received: from [172.20.51.135] (dhcp172-51-135.corp.tellme.com [172.20.51.135]) by mail02.corp.tellme.com (Postfix) with ESMTP id 4B94C3507 for ; Thu, 26 May 2005 14:11:28 -0700 (PDT) Message-ID: <42963B80.2030500@tellme.com> Date: Thu, 26 May 2005 14:11:28 -0700 From: Corby Anderson User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Speechsc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Subject: [Speechsc] Managing big grammars X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org What are folks' thoughts on how we could manage big grammars with MRCP? There are two usage cases that I'm interested in: a Large Grammar that takes several seconds to compile, and a Jumbo Grammar that takes many many minutes to compile. A Large Grammar might contain several hundred or thousand entries. A Jumbo Grammar might contain hundreds of thousands of entries. For a Jumbo Grammar, there's no way that a user can wait for a grammar to be uploaded and compiled via the DEFINE-GRAMMAR or RECOGNIZE methods. A grammar that large needs to be pre-compiled so that the DEFINE-GRAMMAR or RECOGNIZE method can simply load the grammar binary. For a Large Grammar, it might be okay to make one user wait a few seconds for the grammar to compile -- but it would be a big win if that compiled grammar were stored with a known name so that /subsequent/ uses of the same grammar don't have to pay the same compilation penalty. Our current speech recognition vendor's api provides methods for checking for the existence of a dynamic grammar, and for compiling a new grammar (named as the client specifies). The api also provides a powerful and flexible way to manage these stored grammars. Is there some MRCP-friendly way for dealing with these types of grammars? If not, then is one being considered? Corby Anderson Tellme Networks, Inc. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue May 31 22:20:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdIq3-0007tP-VJ; Tue, 31 May 2005 22:20:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdIq0-0007sy-EH for speechsc@megatron.ietf.org; Tue, 31 May 2005 22:20:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18377 for ; Tue, 31 May 2005 22:20:06 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdJ9i-0004D1-Vx for speechsc@ietf.org; Tue, 31 May 2005 22:40:32 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j512H4dK007095 for ; Tue, 31 May 2005 22:17:04 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 May 2005 22:12:23 -0400 Message-ID: From: Eric Burger To: speechsc@ietf.org Date: Tue, 31 May 2005 22:12:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Speechsc] Document Status X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org In case people were wondering, we are making progress on the MRCPv2 document. We have just finished converting the document from Word to xml2rfc format. During the conversion, we are cleaning up the language and clarifying the text. A few issues that need discussion will be brought to the list, and a new document should be out shortly. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc