From root@core3.amsl.com Tue Aug 11 11:30:01 2009 Return-Path: X-Original-To: speechsc@ietf.org Delivered-To: speechsc@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AE6B43A6F70; Tue, 11 Aug 2009 11:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090811183001.AE6B43A6F70@core3.amsl.com> Date: Tue, 11 Aug 2009 11:30:01 -0700 (PDT) Cc: speechsc@ietf.org Subject: [Speechsc] I-D Action:draft-ietf-speechsc-mrcpv2-20.txt X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 18:30:01 -0000 --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 : Media Resource Control Protocol Version 2 (MRCPv2) Author(s) : S. Shanmugham, D. Burnett Filename : draft-ietf-speechsc-mrcpv2-20.txt Pages : 217 Date : 2009-08-11 The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-speechsc-mrcpv2-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-11112058.I-D@ietf.org> --NextPart-- From dburnett@voxeo.com Tue Aug 11 11:35:00 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E6F3A6A2F for ; Tue, 11 Aug 2009 11:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvk1+qvGGRIZ for ; Tue, 11 Aug 2009 11:35:00 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 459363A6CE5 for ; Tue, 11 Aug 2009 11:34:18 -0700 (PDT) Received: from [76.111.40.166] (account dburnett HELO [192.168.15.123]) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 50022133 for speechsc@ietf.org; Tue, 11 Aug 2009 18:22:10 +0000 Message-Id: From: Dan Burnett To: "IETF SPEECHSC (E-mail)" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 11 Aug 2009 14:22:10 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [Speechsc] draft-20 changes (in addition to those in Roni's email) X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 18:35:00 -0000 Here are the other changes in draft-20 in addition to those in Roni's email: - Corrected the two typos that Arsen mentioned. - In 11.5.2.8, clarified that the adapted element is only found within the first element (based on Christian Groves' question). - Corrected the remaining mistakes in the RNG schema pointed out recently by Christian Groves. -- dan From dburnett@voxeo.com Tue Aug 11 11:35:01 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB343A6CE5; Tue, 11 Aug 2009 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqsZzR3Xhe2H; Tue, 11 Aug 2009 11:34:53 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 400573A6B1D; Tue, 11 Aug 2009 11:34:14 -0700 (PDT) Received: from [76.111.40.166] (account dburnett HELO [192.168.15.123]) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 50022126; Tue, 11 Aug 2009 18:21:49 +0000 Message-Id: From: Dan Burnett To: Roni Even In-Reply-To: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-125--1022714190 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 11 Aug 2009 14:21:48 -0400 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> X-Mailer: Apple Mail (2.930.3) Cc: speechsc@ietf.org, sarvi@cisco.com, oran@cisco.com, rai@ietf.org Subject: Re: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 18:35:01 -0000 --Apple-Mail-125--1022714190 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 7, 2009, at 3:40 PM, Roni Even wrote: > Hi, > > I was assigned to do a RAI review of the draft. The draft looks =20 > ready for publication to me. I have some comments mostly editorial. > > The only issue I see that is not pure editorial is the issue of the =20= > different parameters like confidence threshold, sensitivity level =20 > (see comments 11, 13, 15, 16 and 17). I think that some =20 > clarification on the semantics and the scale (for example are the =20 > values linearly spaced) as well as when they are useful will be =20 > helpful to implementers. > > 1. In figure 1 Expand the abbreviations TTS, ASR, SV , SI and =20= > how they are related to the media resource types in 3.1 > Done. Added some text explaining Figure 1 and enhanced Figure 1 =20 slightly for clarification. > 2. In figure 1 there is a SIP dialog between the MRCPv2 client =20= > and the media source/sink, what is this dialog, I only saw in =20 > section 4 a dialog between the client and server. > Clarified in the first example of section 4.2 that the SIP dialog with =20= the media source/sink is not shown. > 3. In section 3.2 you have =93For example: =20 > sip:mrcpv2@example.net=94 twice one after the other. > Fixed. > 4. In the example in section 4.2 you =93a=3Dcmid:1=94, cmid is =20= > specified later in the document so maybe you can add some reference =20= > to where it is specified Done. > > 5. In the example is section 4.2 and in following examples you =20= > have =93m=3Daudio 49170 RTP/AVP 0 96=94 but do not have an rtpmap =20 > parameter for mapping 96 (dynamic payload type number) to a media =20 > encoding name. It is not in the first or third examples (Synthesizer only), but it is =20= in the second example (Recognizer). I have removed 96 as an option =20 for the Synthesizer-only examples but let it remain as an addition for =20= the Recognizer example. > > 6. In section 4.3 =93Also note that more that one media session =20= > can be associated with a single resource if need be, but this =20 > scenario is not useful for the current set of resources=94. There is a = =20 > typo the second =93that=94 should be =93than=94. I am also not sure if = the =20 > current syntax in this document can support the mode. > Fixed the typo. > > 7. In section 4.3 =93The formatting of the"cmid" attribute in =20= > SDP RFC3388 [RFC4566]=94. I think you meant SDP grouping and need the =20= > reference to RFC 3388. > I removed the reference altogether because it already exists =20 (correctly) earlier in the paragraph. > > 8. In section 5.1 =93The message-length field specifies the =20 > length of the message, including the start-line=94 is the length in =20= > Bytes, there is no unit specified. Changed "length of the message" to "length of the message in bytes". > > 9. In section 6.3.1, typo you have =93Verfication =93 instead of = =20 > verification. It appears twice in the section. Fixed. > > 10. In the example in section 7 you have =93m=3Daudio 0 RTP/AVP 0 1 = 3=94 =20 > payload type 1 was deleted from the IANA registry, maybe have =20 > another payload type number. I just removed that payload type. It is not germane to the example. > > 11. In section 9.4.1, 9.4.2 and 9.4.3 you specify confidence =20 > threshold, sensitivity level and speed vs accuracy. What is the =20 > scale here; is it linear between 0 and 1. What is the absolute value =20= > of the number, if you receive the same confidence level from two =20 > recognizers are they the same (e.g. when using context block to =20 > switch servers). For the speed vs accuracy, how does the client =20 > know what is the relation between the value and the number of =20 > available sessions, since this seems to be the reason for using this =20= > parameter. > The interpretation of all of these parameters is implementation-=20 specific because the underlying technologies used to implement them =20 vary and can even be proprietary. In practice the speech recognition =20= and synthesis and speaker authentication communities have lived with =20 this state of affairs for many years, and users of other APIs for this =20= technology are well aware of and have built applications that =20 accommodate this variability in interpretation. It is outside the =20 scope of this specification to attempt to standardize interpretations =20= of these values. > 12. In 9.4.9 and in 10.4.8, 11.4.11 what are the values for media-=20= > type-value, you also mention audio and video but it looks to me that =20= > this document only discusses voice. Yes. Although the original intent was to record speech, application =20 authors today are beginning to look at ways to incorporate other audio =20= or video. The intent of the sentences in these sections is to clarify =20= that the specification itself imposes no restriction on the types of =20 media that are allowed. > > 13. In 9.4.35 and 9.4.36 what is the scale for the consistency =20 > here. How does one know what close means. What is the consistency =20 > between different recognizers. The answer to question 11, above, applies here as well. > > 14. In section 9.6.3.3 in the example (figure 2) confidence should =20= > be 0.75 and not 75 Fixed. > > 15. In section 10.4.1 it is not clear how you measure the =20 > sensitivity in order to specify, is it based on some SNR translated =20= > to 0 to 1 scale? The answer to question 11, above, applies here as well. > > 16. In 11.4.6 the same issue with the scale, how does the client =20 > know how to set a value when working with different speaker =20 > verification servers. Ditto. I should point out that in all of these cases the parameters =20 are typically passed directly to the engine, and their interpretations =20= are defined (and described) in the vendors' documentation. The most =20 common MRCPv2 server implementations are by the technology vendors =20 themselves (the providers of the synthesis, recognition, and =20 verification engines). This is commonly understood in this technology =20= industry (meaning those who use this technology regularly). > > 17. In 11.5.2.9 you state that the verification-score is not a =20 > probability, so what is it. How can the client decide if, for =20 > example, 0 is a good score for specifying the threshold. I also =20 > noticed that the values in the example in section 11.5.2.10 are very =20= > precise like 0.98514 is this the expected precision. The examples =20 > here and in section 11.11 do not show the threshold, if the =20 > threshold is required for this flow why not show it in the example? This parameter, as others mentioned above, has only a vendor-specific =20= interpretation. In practice authors interpret these values based both =20= on guidance from the technology vendors and via experimentation on =20 large sets of recorded data. The Min-Verification-Score threshold is not required to be set. In =20 many cases the technology vendor has a fairly good understanding of =20 what the default threshold should be. The verification-score is =20 returned, however, in case the application author determines (through =20= experimentation, as described above) that the default threshold is not =20= producing optimal results for the application. In that case the =20 author can set the threshold to a different value or can set it to -1 =20= and make the determination within the application itself based on the =20= verification-score values. > > 18. In section 12.3 the suggestion is to use SRTP as the mandatory =20= > interoperability mode. If the reason for mandating SRTP is for a =20 > common mode you should also decide on a key exchange mechanism. I =20 > suggest you look at = http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02=20 > for discussion on media security. Based on the discussion between you and Dan York on the list, I will =20 change this: 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 =20= servers (the other end of a media channel may or may not be on the =20 MRCPv2 client). This data includes the user's spoken utterances and =20 the output of text-to-speech operations. MRCPv2 servers MUST support =20 SRTP for protection of audio media sessions. MRCPv2 clients that =20 originate or consume audio similarly MUST support SRTP. Alternative =20 media channel protection MAY be used if desired (e.g. IPSEC). to this: 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 =20= servers (the other end of a media channel may or may not be on the =20 MRCPv2 client). This data includes the user's spoken utterances and =20 the output of text-to-speech operations. MRCPv2 servers MUST support a =20= security mechanism for protection of audio media sessions. MRCPv2 =20 clients that originate or consume audio similarly MUST support a =20 security mechanism for protection of the audio. If appropriate, usage =20= of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is =20 recommended. > > 19. In section13.7.2 you specify the attribute resource as session =20= > level yet in the example in section 4.2 it is a media level =20 > attribute. The same goes for the channel attribute I have corrected both in section 13.7.2 to be media-level. > > Thanks > > Roni Even > > --Apple-Mail-125--1022714190 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Jul 7, 2009, = at 3:40 PM, Roni Even wrote:

Hi,

I was assigned to do a RAI review of the draft.  The draft = looks ready for publication to me. I have some comments mostly = editorial.

The only issue I see that is not pure editorial is the issue of = the different parameters like confidence threshold, sensitivity level = (see comments 11, 13, 15, 16 and 17). I think that some clarification on = the semantics and the scale (for example are the values linearly spaced) = as well as when they are useful will be helpful to = implementers.

1. 


Done.=

 
11.   In section 9.4.1, 9.4.2 and 9.4.3 you specify confidence = threshold, sensitivity level and speed vs accuracy. What is the scale = here; is it linear between 0 and 1. What is the absolute value of the = number, if you receive the same confidence level from two recognizers = are they the same (e.g. when using context block to switch = servers).  For the speed vs accuracy, how does the client know what = is the relation between the value and the number of available sessions, = since this seems to be the reason for using this = parameter.
   In 9.4.9 and in 10.4.8, 11.4.11 what are the values for = media-type-value, you also mention audio and video but it looks to me = that this document only discusses = voice.

Yes. =  Although the original intent was to record speech, application = authors today are beginning to look at ways to incorporate other audio = or video.  The intent of the sentences in these sections is to = clarify that the specification itself imposes no restriction on the = types of media that are allowed.
=

 
15.   In section 10.4.1 it is not clear how you measure the = sensitivity in order to specify, is it based on some SNR translated to 0 = to 1 = scale?

The = answer to question 11, above, applies here as = well.

 
16.   In 11.4.6 the same issue with the scale, how does the = client know how to set a value when working with different speaker = verification = servers.

Ditto.=  I should point out that in all of these cases the parameters are = typically passed directly to the engine, and their interpretations are = defined (and described) in the vendors' documentation.  The most = common MRCPv2 server implementations are by the technology vendors = themselves (the providers of the synthesis, recognition, and = verification engines).  This is commonly understood in this = technology industry (meaning those who use this technology = regularly).

 
17.   In 11.5.2.9 you state that the verification-score is not a = probability, so what is it. How can the client decide if, for example, 0 = is a good score for specifying the threshold.  I also noticed that = the values in the example in section 11.5.2.10 are very precise like = 0.98514 is this the expected precision. The examples here and in section = 11.11 do not show the threshold, if the threshold is required for this = flow why not show it in the = example?

This = parameter, as others mentioned above, has only a vendor-specific = interpretation.  In practice authors interpret these values based = both on guidance from the technology vendors and via experimentation on = large sets of recorded data.

The = Min-Verification-Score threshold is not required to be set.  In = many cases the technology vendor has a fairly good understanding of what = the default threshold should be.  The verification-score is = returned, however, in case the application author determines (through = experimentation, as described above) that the default threshold is not = producing optimal results for the application.  In that case the = author can set the threshold to a different value or can set it to -1 = and make the determination within the application itself based on the = verification-score values.




= = --Apple-Mail-125--1022714190-- From Even.roni@huawei.com Wed Aug 12 00:22:37 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234F73A6A38; Wed, 12 Aug 2009 00:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjkPyqdd83d1; Wed, 12 Aug 2009 00:22:24 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) by core3.amsl.com (Postfix) with ESMTP id 00ACD3A63D3; Wed, 12 Aug 2009 00:22:23 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO9002ZQ5NB8U@szxga01-in.huawei.com>; Wed, 12 Aug 2009 15:18:47 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO900K8S5MYYY@szxga01-in.huawei.com>; Wed, 12 Aug 2009 15:18:46 +0800 (CST) Received: from windows8d787f9 (bzq-79-180-57-195.red.bezeqint.net [79.180.57.195]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO90078S5M7EF@szxml02-in.huawei.com>; Wed, 12 Aug 2009 15:18:41 +0800 (CST) Date: Wed, 12 Aug 2009 10:15:20 +0300 From: Roni Even In-reply-to: To: 'Dan Burnett' Message-id: <027801ca1b1c$c2e8ee80$48bacb80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VAnI9RDuzfD30+DX7QbxZw)" Content-language: en-us Thread-index: AcoasgmJVUUpROjvQ5a54Hub9X2DzAAZj4yw References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> X-Mailman-Approved-At: Wed, 12 Aug 2009 08:12:42 -0700 Cc: speechsc@ietf.org, sarvi@cisco.com, oran@cisco.com, rai@ietf.org Subject: Re: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 07:22:37 -0000 This is a multi-part message in MIME format. --Boundary_(ID_VAnI9RDuzfD30+DX7QbxZw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Dan, I understand your explanation about all these "vendor specific" parameter. I think that since this a standard track document there should be some text explaining the usage of these parameters as well as making a note that since these are vendor specific information you cannot compare the values coming from different vendors As for my comment number 5 on payload type 96. My comment was that if the m-line has a payload type number of 96 you must have a a=rtpmap line mapping 96 to a specific subtype name while for pcmu it is not mandatory to have a=rtpmap like you have in your examples since payload type number 0 is a static payload type number assigned to pcmu Roni Even From: Dan Burnett [mailto:dburnett@voxeo.com] Sent: Tuesday, August 11, 2009 9:22 PM To: Roni Even Cc: sarvi@cisco.com; oran@cisco.com; 'Eric Burger'; speechsc@ietf.org; rai@ietf.org Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19 On Jul 7, 2009, at 3:40 PM, Roni Even wrote: Hi, I was assigned to do a RAI review of the draft. The draft looks ready for publication to me. I have some comments mostly editorial. The only issue I see that is not pure editorial is the issue of the different parameters like confidence threshold, sensitivity level (see comments 11, 13, 15, 16 and 17). I think that some clarification on the semantics and the scale (for example are the values linearly spaced) as well as when they are useful will be helpful to implementers. 1. In figure 1 Expand the abbreviations TTS, ASR, SV , SI and how they are related to the media resource types in 3.1 Done. Added some text explaining Figure 1 and enhanced Figure 1 slightly for clarification. 2. In figure 1 there is a SIP dialog between the MRCPv2 client and the media source/sink, what is this dialog, I only saw in section 4 a dialog between the client and server. Clarified in the first example of section 4.2 that the SIP dialog with the media source/sink is not shown. 3. In section 3.2 you have "For example: sip:mrcpv2@example.net" twice one after the other. Fixed. 4. In the example in section 4.2 you "a=cmid:1", cmid is specified later in the document so maybe you can add some reference to where it is specified Done. 5. In the example is section 4.2 and in following examples you have "m=audio 49170 RTP/AVP 0 96" but do not have an rtpmap parameter for mapping 96 (dynamic payload type number) to a media encoding name. It is not in the first or third examples (Synthesizer only), but it is in the second example (Recognizer). I have removed 96 as an option for the Synthesizer-only examples but let it remain as an addition for the Recognizer example. 6. In section 4.3 "Also note that more that one media session can be associated with a single resource if need be, but this scenario is not useful for the current set of resources". There is a typo the second "that" should be "than". I am also not sure if the current syntax in this document can support the mode. Fixed the typo. 7. In section 4.3 "The formatting of the"cmid" attribute in SDP RFC3388 [RFC4566]". I think you meant SDP grouping and need the reference to RFC 3388. I removed the reference altogether because it already exists (correctly) earlier in the paragraph. 8. In section 5.1 "The message-length field specifies the length of the message, including the start-line" is the length in Bytes, there is no unit specified. Changed "length of the message" to "length of the message in bytes". 9. In section 6.3.1, typo you have "Verfication " instead of verification. It appears twice in the section. Fixed. 10. In the example in section 7 you have "m=audio 0 RTP/AVP 0 1 3" payload type 1 was deleted from the IANA registry, maybe have another payload type number. I just removed that payload type. It is not germane to the example. 11. In section 9.4.1, 9.4.2 and 9.4.3 you specify confidence threshold, sensitivity level and speed vs accuracy. What is the scale here; is it linear between 0 and 1. What is the absolute value of the number, if you receive the same confidence level from two recognizers are they the same (e.g. when using context block to switch servers). For the speed vs accuracy, how does the client know what is the relation between the value and the number of available sessions, since this seems to be the reason for using this parameter. The interpretation of all of these parameters is implementation-specific because the underlying technologies used to implement them vary and can even be proprietary. In practice the speech recognition and synthesis and speaker authentication communities have lived with this state of affairs for many years, and users of other APIs for this technology are well aware of and have built applications that accommodate this variability in interpretation. It is outside the scope of this specification to attempt to standardize interpretations of these values. 12. In 9.4.9 and in 10.4.8, 11.4.11 what are the values for media-type-value, you also mention audio and video but it looks to me that this document only discusses voice. Yes. Although the original intent was to record speech, application authors today are beginning to look at ways to incorporate other audio or video. The intent of the sentences in these sections is to clarify that the specification itself imposes no restriction on the types of media that are allowed. 13. In 9.4.35 and 9.4.36 what is the scale for the consistency here. How does one know what close means. What is the consistency between different recognizers. The answer to question 11, above, applies here as well. 14. In section 9.6.3.3 in the example (figure 2) confidence should be 0.75 and not 75 Fixed. 15. In section 10.4.1 it is not clear how you measure the sensitivity in order to specify, is it based on some SNR translated to 0 to 1 scale? The answer to question 11, above, applies here as well. 16. In 11.4.6 the same issue with the scale, how does the client know how to set a value when working with different speaker verification servers. Ditto. I should point out that in all of these cases the parameters are typically passed directly to the engine, and their interpretations are defined (and described) in the vendors' documentation. The most common MRCPv2 server implementations are by the technology vendors themselves (the providers of the synthesis, recognition, and verification engines). This is commonly understood in this technology industry (meaning those who use this technology regularly). 17. In 11.5.2.9 you state that the verification-score is not a probability, so what is it. How can the client decide if, for example, 0 is a good score for specifying the threshold. I also noticed that the values in the example in section 11.5.2.10 are very precise like 0.98514 is this the expected precision. The examples here and in section 11.11 do not show the threshold, if the threshold is required for this flow why not show it in the example? This parameter, as others mentioned above, has only a vendor-specific interpretation. In practice authors interpret these values based both on guidance from the technology vendors and via experimentation on large sets of recorded data. The Min-Verification-Score threshold is not required to be set. In many cases the technology vendor has a fairly good understanding of what the default threshold should be. The verification-score is returned, however, in case the application author determines (through experimentation, as described above) that the default threshold is not producing optimal results for the application. In that case the author can set the threshold to a different value or can set it to -1 and make the determination within the application itself based on the verification-score values. 18. In section 12.3 the suggestion is to use SRTP as the mandatory interoperability mode. If the reason for mandating SRTP is for a common mode you should also decide on a key exchange mechanism. I suggest you look at http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 for discussion on media security. Based on the discussion between you and Dan York on the list, I will change this: 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support SRTP for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support SRTP. Alternative media channel protection MAY be used if desired (e.g. IPSEC). to this: 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. If appropriate, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. 19. In section13.7.2 you specify the attribute resource as session level yet in the example in section 4.2 it is a media level attribute. The same goes for the channel attribute I have corrected both in section 13.7.2 to be media-level. Thanks Roni Even --Boundary_(ID_VAnI9RDuzfD30+DX7QbxZw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Dan,

I understand your explanation about all these "vendor specific" parameter. I think that since this a standard track document there should be some text explaining the usage of these parameters as well as making a note that since these are vendor specific information you cannot compare the values coming from different vendors

 

 

As for my comment number 5 on payload type 96. My comment was that if the m-line has a payload type number of 96 you must have a a=rtpmap line mapping 96 to a specific subtype name while for pcmu it is not mandatory to have a=rtpmap like you have in your examples since payload type number 0 is a static payload type number assigned to pcmu

 

 

Roni Even

 

From: Dan Burnett [mailto:dburnett@voxeo.com]
Sent: Tuesday, August 11, 2009 9:22 PM
To: Roni Even
Cc: sarvi@cisco.com; oran@cisco.com; 'Eric Burger'; speechsc@ietf.org; rai@ietf.org
Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19

 

 

On Jul 7, 2009, at 3:40 PM, Roni Even wrote:



Hi,

I was assigned to do a RAI review of the draft.  The draft looks ready for publication to me. I have some comments mostly editorial.

The only issue I see that is not pure editorial is the issue of the different parameters like confidence threshold, sensitivity level (see comments 11, 13, 15, 16 and 17). I think that some clarification on the semantics and the scale (for example are the values linearly spaced) as well as when they are useful will be helpful to implementers.

1.       In figure 1 Expand the abbreviations TTS, ASR, SV , SI and how they are related to the media resource types in 3.1

 

Done.  Added some text explaining Figure 1 and enhanced Figure 1 slightly for clarification.

2.       In figure 1 there is a SIP dialog between the MRCPv2 client and the media source/sink, what is this dialog, I only saw in section 4 a dialog between the client and server.

Clarified in the first example of section 4.2 that the SIP dialog with the media source/sink is not shown.

Fixed.



4.       In the example in section 4.2 you “a=cmid:1”, cmid is specified later in the document so maybe you can add some reference to where it is specified

 

Done.



 

5.       In the example is section 4.2 and in following examples you have “m=audio 49170 RTP/AVP 0 96” but do not have an rtpmap parameter for mapping 96 (dynamic payload type number) to a media encoding name.

 

It is not in the first or third examples (Synthesizer only), but it is in the second example (Recognizer).  I have removed 96 as an option for the Synthesizer-only examples but let it remain as an addition for the Recognizer example.



 

6.       In section 4.3 “Also note that more that one media session can be associated with a single resource if need be, but this scenario is not useful for the current set of resources”. There is a typo the second “that” should be “than”. I am also not sure if the current syntax in this document can support the mode.

 

Fixed the typo.



 

7.       In section 4.3 “The formatting of the"cmid" attribute in SDP RFC3388 [RFC4566]”. I think you meant SDP grouping and need the reference to RFC 3388.

 

I removed the reference altogether because it already exists (correctly) earlier in the paragraph.



 

8.       In section 5.1 “The message-length field specifies the length of the message, including the start-line” is the length in Bytes, there is no unit specified.

 

Changed "length of the message" to "length of the message in bytes".



 

9.       In section 6.3.1, typo you have “Verfication “ instead of verification. It appears twice in the section.

 

Fixed.



 

10.   In the example in section 7 you have “m=audio 0 RTP/AVP 0 1 3” payload type 1 was deleted from the IANA registry, maybe have another payload type number.

 

I just removed that payload type.  It is not germane to the example.



 

11.   In section 9.4.1, 9.4.2 and 9.4.3 you specify confidence threshold, sensitivity level and speed vs accuracy. What is the scale here; is it linear between 0 and 1. What is the absolute value of the number, if you receive the same confidence level from two recognizers are they the same (e.g. when using context block to switch servers).  For the speed vs accuracy, how does the client know what is the relation between the value and the number of available sessions, since this seems to be the reason for using this parameter.

 

The interpretation of all of these parameters is implementation-specific because the underlying technologies used to implement them vary and can even be proprietary.  In practice the speech recognition and synthesis and speaker authentication communities have lived with this state of affairs for many years, and users of other APIs for this technology are well aware of and have built applications that accommodate this variability in interpretation.  It is outside the scope of this specification to attempt to standardize interpretations of these values.



12.   In 9.4.9 and in 10.4.8, 11.4.11 what are the values for media-type-value, you also mention audio and video but it looks to me that this document only discusses voice.

 

Yes.  Although the original intent was to record speech, application authors today are beginning to look at ways to incorporate other audio or video.  The intent of the sentences in these sections is to clarify that the specification itself imposes no restriction on the types of media that are allowed.



 

13.   In 9.4.35 and 9.4.36 what is the scale for the consistency here. How does one know what close means. What is the consistency between different recognizers.

 

The answer to question 11, above, applies here as well.



 

14.   In section 9.6.3.3 in the example (figure 2) confidence should be 0.75 and not 75

 

Fixed.



 

15.   In section 10.4.1 it is not clear how you measure the sensitivity in order to specify, is it based on some SNR translated to 0 to 1 scale?

 

The answer to question 11, above, applies here as well.



 

16.   In 11.4.6 the same issue with the scale, how does the client know how to set a value when working with different speaker verification servers.

 

Ditto.  I should point out that in all of these cases the parameters are typically passed directly to the engine, and their interpretations are defined (and described) in the vendors' documentation.  The most common MRCPv2 server implementations are by the technology vendors themselves (the providers of the synthesis, recognition, and verification engines).  This is commonly understood in this technology industry (meaning those who use this technology regularly).



 

17.   In 11.5.2.9 you state that the verification-score is not a probability, so what is it. How can the client decide if, for example, 0 is a good score for specifying the threshold.  I also noticed that the values in the example in section 11.5.2.10 are very precise like 0.98514 is this the expected precision. The examples here and in section 11.11 do not show the threshold, if the threshold is required for this flow why not show it in the example?

 

This parameter, as others mentioned above, has only a vendor-specific interpretation.  In practice authors interpret these values based both on guidance from the technology vendors and via experimentation on large sets of recorded data.

 

The Min-Verification-Score threshold is not required to be set.  In many cases the technology vendor has a fairly good understanding of what the default threshold should be.  The verification-score is returned, however, in case the application author determines (through experimentation, as described above) that the default threshold is not producing optimal results for the application.  In that case the author can set the threshold to a different value or can set it to -1 and make the determination within the application itself based on the verification-score values.

 

12.3. Media session protection 
Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support SRTP for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support SRTP. Alternative media channel protection MAY be used if desired (e.g. IPSEC).

 

to this:

 

12.3. Media session protection 
Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. If appropriate, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended.

 

19.   In section13.7.2 you specify the attribute resource as session level yet in the example in section 4.2 it is a media level attribute. The same goes for the channel attribute

 

I have corrected both in section 13.7.2 to be media-level.



 

Thanks

 

Roni Even

 

 

 

--Boundary_(ID_VAnI9RDuzfD30+DX7QbxZw)-- From Christian.Groves@nteczone.com Mon Aug 17 23:00:06 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452A33A68AA for ; Mon, 17 Aug 2009 23:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJMrAEipXv7f for ; Mon, 17 Aug 2009 23:00:05 -0700 (PDT) Received: from ipmail02.adl6.internode.on.net (ipmail02.adl6.internode.on.net [203.16.214.140]) by core3.amsl.com (Postfix) with ESMTP id 104DB3A6B60 for ; Mon, 17 Aug 2009 23:00:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYBAKrdiUp5LMMG/2dsb2JhbAAI1xCEGQU X-IronPort-AV: E=Sophos;i="4.43,401,1246804200"; d="scan'208";a="23188982" Received: from ppp121-44-195-6.lns10.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.195.6]) by ipmail02.adl6.internode.on.net with ESMTP; 18 Aug 2009 15:30:00 +0930 Message-ID: <4A8A434D.9020900@nteczone.com> Date: Tue, 18 Aug 2009 15:59:41 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dan Burnett References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" Subject: Re: [Speechsc] draft-20 changes (in addition to those in Roni's email) X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 06:00:06 -0000 G'Day Dan, Thanks for the updates. It clarifies my concerns. Regards, Christian Dan Burnett wrote: > Here are the other changes in draft-20 in addition to those in Roni's > email: > > > - Corrected the two typos that Arsen mentioned. > > - In 11.5.2.8, clarified that the adapted element is only found within > the first element (based on Christian Groves' question). > > - Corrected the remaining mistakes in the RNG schema pointed out > recently by Christian Groves. > > > > -- dan > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc> > From corbya@microsoft.com Fri Aug 21 18:13:26 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1293C3A69B5 for ; Fri, 21 Aug 2009 18:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGeRr-a27y11 for ; Fri, 21 Aug 2009 18:13:23 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 334F93A6838 for ; Fri, 21 Aug 2009 18:13:23 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Aug 2009 18:13:28 -0700 Received: from TK5EX14MBXC116.redmond.corp.microsoft.com ([169.254.7.27]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Fri, 21 Aug 2009 18:13:22 -0700 From: Corby Anderson To: "speechsc@ietf.org" Thread-Topic: Confusuion with INTERPRET Thread-Index: Acoixbz/oqwD7Tk/Sv6x0aOqfZ5kDw== Date: Sat, 22 Aug 2009 01:13:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EF149B22CD1213419BF4DFE038422CAC6D6C23TK5EX14MBXC116red_" MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 22 Aug 2009 08:38:25 -0700 Subject: [Speechsc] Confusuion with INTERPRET X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 01:15:30 -0000 --_000_EF149B22CD1213419BF4DFE038422CAC6D6C23TK5EX14MBXC116red_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does section 9.20 INTERPRET need some clarification? 9.20 states that INTER= PRETATION should return an INTERPRETATION-COMPLETE event (as described in 9= .21), but the example in section 9.20 shows the following response: S->C: MRCP/2.0 49 543267 200 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:... That S->C format is for responses (5.3), not events (5.5). Contrast this w= ith the RECOGNITION-RESPONSE event to RECOGNIZE: S->C:MRCP/2.0 486 RECOGNITION-COMPLETE 543260 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Waveform-URI:; size=3D124535;duration=3D2340 Content-Type:applicationt/x-nlsml Content-Length:... Shouldn't the first line of the INTERPRETATION-COMPLETE event be something = like the following? S->C: MRCP/2.0 49 INTERPRETATION-COMPLETE 543267 COMPLETE The only mention of INTERPRETATION-COMPLETE in the spec are * table of contents * 9.3 Recognizer events * 9.21 where it's described * 13.1.2 MRCPv2 methods and events * 15 Normative definition I found no usage examples for INTERPRETATION-COMPLETE; most notably not in = 9.20 Also, section 9.9 states For the recognizer resource, RECOGNIZE is the only request that returns a request-state of IN-PROGRESS, meaning that recognition is in progress. But the example in 9.20 for INTERPRET shows S->C: MRCP/2.0 49 543266 200 IN-PROGRESS Channel-Identifier:32AECB23433801@speechrecog Is the recognizer resource the resource that performs interpretation? If s= o, then the text in 9.9 should be changed to say the following: For the recognizer resource, RECOGNIZE and INTERPRET are the only requests that return a request-state of IN-PROGRESS, meaning that recognition or interpretation is in progress. Corby Anderson --_000_EF149B22CD1213419BF4DFE038422CAC6D6C23TK5EX14MBXC116red_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does section 9.20 INTERPRET need some clarification? 9= .20 states that INTERPRETATION should return an INTERPRETATION-COMPLETE event (= as described in 9.21), but the example in section 9.20 shows the following response:

 

   S->C:    MRCP/2.0 49 54= 3267 200 COMPLETE

         =   Channel-Identifier:32AECB23433801@speechrecog

         =   Completion-Cause:000 success

         =   Content-Type:application/nlsml+xml

         =   Content-Length:...

 

That S->C format is for responses (5.3), not events= (5.5).  Contrast this with the RECOGNITION-RESPONSE event to RECOGNIZE:<= /p>

 

   S->C:MRCP/2.0 486 RECOGNITION-COMPLETE 543260 COMPLETE

   Channel-Identifier:32AECB23433801@speechr= ecog

   Completion-Cause:000 success

   Waveform-URI:<http://web.media.com/session123/audio.wav>;<= /p>

         =        size=3D124535;duration=3D2340

   Content-Type:applicationt/x-nlsml

   Content-Length:...

 

Shouldn’t the first line of the INTERPRETATION-C= OMPLETE event be something like the following?

   S->C:    MRCP/2.0 49 IN= TERPRETATION-COMPLETE 543267 COMPLETE

 

The only mention of INTERPRETATION-COMPLETE in the spe= c are

* table of contents

* 9.3 Recognizer events

* 9.21 where it’s described

* 13.1.2 MRCPv2 methods and events

* 15 Normative definition

 

I found no usage examples for INTERPRETATION-COMPLETE;= most notably not in 9.20

 

 

 

Also, section 9.9 states

   For the recognizer resource, RECOGNIZE is= the only request that

   returns a request-state of IN-PROGRESS, m= eaning that recognition is

   in progress.

 

But the example in 9.20 for INTERPRET shows=

   S->C:    MRCP/2.0 49 54= 3266 200 IN-PROGRESS

         =   Channel-Identifier:32AECB23433801@speechrecog

 

Is the recognizer resource the resource that performs interpretation?  If so, then the text in 9.9 should be changed to say = the following:

   For the recognizer resource, RECOGNIZE an= d INTERPRET are the only

   requests that return a request-state of IN-PROGRESS, meaning that

   recognition or interpretation is in progr= ess.

 

 

Corby Anderson

 

--_000_EF149B22CD1213419BF4DFE038422CAC6D6C23TK5EX14MBXC116red_-- From arthur@istnetworks.com Mon Aug 24 03:17:56 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129203A6E19 for ; Mon, 24 Aug 2009 03:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_BACKHAIR_33=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0cTu9DsNOcb for ; Mon, 24 Aug 2009 03:17:55 -0700 (PDT) Received: from Out001.Mi8.com (out001.mi8.com [216.166.12.74]) by core3.amsl.com (Postfix) with ESMTP id 3F35C3A69FA for ; Mon, 24 Aug 2009 03:17:54 -0700 (PDT) Received: from AUSP02VMBX01.Mi8.com ([10.4.8.6]) by Out001.Mi8.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 06:17:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Aug 2009 06:18:09 -0400 Message-ID: <19EAD33AD254324284516DA3335C8FEA960203@AUSP02VMBX01.Mi8.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Semantic Scripts - Arrays Thread-Index: AcokpC3iUckZGeaIT2WOssle7gDrPA== From: "Arthur Vernon" To: X-OriginalArrivalTime: 24 Aug 2009 10:17:59.0703 (UTC) FILETIME=[27F42A70:01CA24A4] Subject: [Speechsc] Semantic Scripts - Arrays X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 10:17:56 -0000 In "Speech Processing for IP Networks" there is a reference to how arrays of values are to be handled. The gist of it is:=20 "It is possible for the rule variable of the root rule to be of type Array (e.g. x[0], x[1], etc) or indeed for one of its properties to be of type Array." I cannot see a concrete example in the specification of how this information is supposed to be communicated from the server to the client. The MRCP 2 server reports this... BHP RIO As you can see, there is notional identification of the two items I spoke by way of a CR/LF. The MRCP 2 client reports receiving this: BHP RIO On the document server, this is getting passed back to me as stock: "BRI" Further reading of the logs on the MRCP client (produced using) The type of stock is The value of stock is reveals: The type of stock is string The value of stock is BRI I would have expected that the type of stock to be array. (containing BHP and RIO) My problem is (from a user perspective) who do I complain to to seek a resolution to the problem? Can the specification clarify this matter please (or maybe I have just missed this bit). Here is the (edited and relevant bits of the) grammar used to generate this: Buy out._service =3D "StockBuy"; = out.stock=3Dnew Array(); var index=3D0; out.stock[index++] =3D ""+rules.company; =20 BHPout=3D"BHP"; Rio tinto out=3D"RIO"; It is a bit hacked because in the process I have tried numerious ways to realise a working array. Kind Regards, Arthur Vernon - Lead Software Architect, IST Networks AUSTRALIA (m) +61 411 336 176 (w) +61 (8) 6380 2058 Unit 5B, 1 Station St, Subiaco WA 6008=20