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 ED81E28C2FF; Tue, 7 Jul 2009 12:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 Vlm+lyPnAvA1; Tue, 7 Jul 2009 12:41:49 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5737E28C540; Tue, 7 Jul 2009 12:41:49 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF009XMG07HT@szxga03-in.huawei.com>; Wed, 08 Jul 2009 03:40:55 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF004LPG07XI@szxga03-in.huawei.com>; Wed, 08 Jul 2009 03:40:55 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-156-32.red.bezeqint.net [82.81.156.32]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMF001JOFZNP9@szxml01-in.huawei.com>; Wed, 08 Jul 2009 03:40:55 +0800 (CST) Date: Tue, 07 Jul 2009 22:40:17 +0300 From: Roni Even To: sarvi@cisco.com, dburnett@voxeo.com Message-id: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tDM6/tBc+CJPdmIwZyVDuw)" Content-language: en-us Thread-index: Acn/OlCXdRdlr834SLWofXw8dvS9rQ== X-Mailman-Approved-At: Wed, 08 Jul 2009 09:26:14 -0700 Cc: speechsc@ietf.org, oran@cisco.com, rai@ietf.org Subject: [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, 07 Jul 2009 19:41:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_tDM6/tBc+CJPdmIwZyVDuw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 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 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. 3. In section 3.2 you have "For example: sip:mrcpv2@example.net" twice one after the other. 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 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. 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. 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. 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. 9. In section 6.3.1, typo you have "Verfication " instead of verification. It appears twice in the section. 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. 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. 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. 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. 14. In section 9.6.3.3 in the example (figure 2) confidence should be 0.75 and not 75 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? 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. 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? 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. 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 Thanks Roni Even --Boundary_(ID_tDM6/tBc+CJPdmIwZyVDuw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

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

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.

3.       In section 3.2 you have = “For example: sip:mrcpv2@example.net” twice one = after the other.

 =

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

 =

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

 =

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.

 =

 =

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.

 =

 =

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.

 =

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

 =

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

 =

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.

 =

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.

 =

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.

 =

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

 =

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?

 =

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.

 =

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?

 =

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.

 =

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

 

Thanks=

 =

Roni Even

 =

 

--Boundary_(ID_tDM6/tBc+CJPdmIwZyVDuw)--