Re: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19

[Arsen Chaloyan <[e-mail]>]

Hi,
Two small issues left you may want to fix.

- Section 9.4.30
Media type should be "text/plain" instead of "plain/text"
http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/

- Find BARGE-IN-OCCURED replace with BARGE-IN-OCCURRED
There are 3 such occurrences in the text.

Thanks,
Arsen.




________________________________
From: Roni Even <[e-mail]>
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Sent: Wednesday, July 8, 2009 12:40:17 AM
Subject: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19

 
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:[e-mail]” 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