Subject: [AVT] draft-clark-avt-rtcphr-02

From: Keith Lantz <[email-masked]>
Date: Tue, 11 Jul 2006 12:55:13 -0700

Alan, Amy, Rajesh, et al.:

This draft is much improved since I reviewed the 00 draft back in 
January. Good work! And thanks for accommodating many of my previous 
comments (appended below for reference). Please note, however, that 
several of those previous comments now apply to 
draft-clark-avt-rtcpxr-video-02, since some of the original prose 
from rtcphr-00 was copied to rtcpxr-video *before* addressing my 
earlier comments. :-( I will follow up with a separate message 
detailing my concerns with rtcpxr-video-02.

Following are some comments on rtcphr-02, in page order:

- p. 3, Section 2.1: Remove the hyphen from "A translator may:-".

         The phrase "with the translation which it performs RFC3550" is broken.

- p. 5, Section 2.3: The paragraph on concealed seconds suggests that 
*time* is "lost", which doesn't sound quite right to me. I suggest 
that paragraph be rewritten as follows: "The term Concealed Seconds 
defines a count of seconds during which packets were either lost or 
discarded. The term Severely Concealed Seconds defines a count of 
seconds in which the cumulative duration of all lost or discarded 
packets exceeds a specified threshold."

- p. 5, Section 2.4: I can't parse "in the range 0.0, 0.0039 to 
255.996". (More generally, I'm not convinced it's 
appropriate/necessary to show the decimal equivalent of n-bit binary 
fractions to three decimal places.)

- p. 6, diagram for Concealed Seconds metrics sub-block: "threshold" 
should be "SCS Threshold" (to match with subsequent prose).

- p. 13, Sections 3.6.1 & 3.6.2: The phrase "that have occurred on 
this call" suggests that the count in question is *cumulative*. 
Presuming this need not be the case -- i.e., that like all other 
metrics this could be an interval metric -- I suggest simply deleting 
the phrase (in both sections).

- p. 14, Section 3.7.2: For clarity, I think it would be helpful to 
insert "reporting" before "endpoint" -- yielding "The End System 
Delay is the internal round trip delay within the reporting endpoint..."

- p. 14, Section 3.7.3.: "If the external network is VoIP based then" 
--> "If the external network is IP-based, then".

- p. 16, Section 3.8.1 & 3.8.2: Per my original critique, these 
sections both refer to a "Voice/Data Quality Metric Algorithm block" 
that is not defined anywhere else in the document. I presume this 
should be the "RTCP HR Configuration Block" defined in Section 4 ... ???

- p. 17, Section 3.8.5: I still don't understand why "media type" is 
defined in the Call Quality Metrics sub-block.

- p. 20, Section 3.9: Per previous occurrences of like prose, rewrite 
"MAY be present. Their presence MUST be indicated" as "MAY be present 
and if present MUST be indicated",

- p. 22, Section 4.2.2: "An Map field" --> "A Map field".

- p. 22, Section 4.3: "for an endpoint may convey" --> "for an 
endpoint to convey"

- p. 23f, Section 4.4: I'm still pretty dissatisfied with this 
section. It simply doesn't do a good job, IMHO, of explaining the 
purpose/use of the block in question -- in large part, perhaps, 
because the example is so meaningless. Why not pick an actual metric? 
(One, perhaps, that isn't promoted by one of the authors ;-) -- 
Sage's SMOS metric, for example.)

- p. 26: Insert em-dashes in the first sentence of the paragraph 
following the bullet list, yielding "In the next section we 
illustrate how policies may be applied to control these behaviors and 
hence achieve three end-to-end reporting modes -- "end system 
peering," "local reporting" and "global reporting" -- for a 
hypothetical bidirectional unicast connection using translators."

         Also, the horizontal lines in the diagram in Section 5.1 are 
misaligned so as not to create the desired boxes ... at least in the 
hardcopy I reviewed.

- p. 28, end of Section 5.1.1: The phrase "may include modification 
of the RTCP" seems inappropriate -- as if you're actually modifying 
the protocol rather than the payload. Perhaps this usage is common, 
and I missed it previously, but here it finally caught my eye. 
Suggest simply inserting "payload" after "RTCP".

         Similarly, in subsequent prose the phrase "forwarded further 
in RTCP" is used several times. In this case I suggest simply 
deleting the "in RTCP".

- p. 31, Section 5.1.4: "forward end system reports (End System 
Peering)" --> "forward end system reports". The parenthetical remark 
is confusing.

- p. 32: Echoing the previous remark (and then some), rewrite the 
global mode paragraph as

         "Global mode - Translators forward both end system report and ..."

- p. 33, Section 10: Remove the two authors (Kevin and Geoff) from the list.

- Finally, a *complete* nit: There are many occurrences of "<text> 
however <more text>", where either (a) the "however" is not set off 
with commas and/or (b) where "but" would seem more appropriate. 
Similarly for "hence", "for example" and "finally". Edit as desired. ;-)

Regards, Keith

----- MY ORIGINAL COMMENTS ON draft-clark-avt-rtcphr-00

At 08:12 AM 1/4/2006, Alan Clark wrote:
>The attached draft was submitted last week however does not seem to 
>have emerged from the IETF as yet.  This comprises the "high 
>resolution metrics" block from the earlier RTCP XRbis draft - which 
>the AVT chairs requested be split into several drafts.
>
>Comments would be welcomed!!
>
>Regards
>
>Alan
>
><snip>
>
>Clark               Expires June 2006                        [Page 2]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>
>        ----------->    --------RTP---------->   ------------->
>    <A>             <B>                       <C>              <D>
>        <-----------    <-------RTP----------- | <-------------
>                                               |
>                        <------RTCP HR---------|
>
>    With respect to RTCP HR report blocks generated by "C" in relation to
>    the RTP stream from "B" to "C".

Replace the period with a colon.

>    (i) The term "External" is used to relate to the network connected to
>    the other side of "this" endpoint (i.e. to the connection from "C" to
>    "D").
>
>    (ii) The Local IP Endpoint is "this" endpoint (i.e. "C")

Insert a period at the end of the sentence.

>    (iii) The Remote IP Endpoint is the source for the RTP stream
>    terminated at this endpoint, and for which packet/frame related
>    metrics apply. (i.e. "B")

Move period to after the ")" -- i.e. 'metrics apply. (i.e. "B")'
  --> 'metrics apply (i.e. "B").'

>    (iv) The Remote External Endpoint is the remote endpoint on the
>    "external" side of this endpoint (i.e. "D").
>
>    (v) The endpoint on the external side of the Remote IP Endpoint (i.e.
>    "A") does not have a specific term applied to it, however note that
>    some metrics may apply to the "A" to "B" connection.
>
>    If this model is applied to a trunking gateway, then the "B" to "C"
>    connection would be the IP network or Voice over IP connection
>    whereas the "C" to "D" connection would typically be the PCM trunk.
>
>    If this model is applied to a conference bridge or session/border
>    controller then the "B" to "C" connection would be a Voice over IP
>    connection and the "C" to "D" connection may also be Voice over IP.
>    In this scenario, "C" could be generating RTCP HR or XR reports in
>    both directions, i.e. sent to "D" for the "D" to "C" RTP stream and
>    sent to "B" for the "B" to "C" RTP stream.
>
>    2.2 Cumulative and Interval Metrics
>
>    Cumulative metrics relate to the entire duration of the call to the
>    point at which metrics are determined and reported, and are typically
>    used to report call quality.  Cumulative metrics generally result in
>    a lower volume of data that may need to be stored, as each report
>    supersedes earlier reports.
>
>    Interval metrics relate to the period since the last Interval report.
>    Interval data may be easier to correlate with specific network events
>    for which timing is known, and may also be used as a basis for
>    threshold crossing alerts.
>    Note that interval metrics for the start and end of calls may be
>    unreliable due to factors such as irregular interval length and the
>    difficulty in knowing when packet transmission started and ended.
>
>
>
>Clark               Expires June 2006                        [Page 3]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    2.3 Bursts, Gaps, and Concealed Seconds
>
>    The terms Burst and Gap are used in a manner consistent with that of
>    RTCP XR (RFC3611).  A Gap is a period of time between Bursts such
>    that any lost or discarded packets or frames are separated by some
>    number of "good" packets or frames.  A Burst is a period of time that
>    fails the test for a Gap, and hence corresponds to a degraded quality
>    period.  The recommended value for Gmin in RFC3611 resulted in a
>    Burst being a period of time during which the packet loss/discard
>    rate exceeded 5%.

The definitions of burst and gap are quite confusing. I've seen two 
much better explanations. The first, in one of your old ITU 
submissions, says "a gap is a period of time during which the packet 
loss rate is low and only isolated packets may be lost, and a burst 
is a period of time during which the packet loss rate is high enough 
to be problematic." The second, in the emerging PacketCable 2.0 
specification, says "RTCP XR views a call as being divided into 
bursts, which are periods during which the combined packet loss and 
discard rate is high enough to cause noticeable call quality 
degradation (generally over 5 percent loss/discard rate), and gaps, 
which are periods during which lost or discarded packets are 
infrequent and hence call quality is generally acceptable." Either 
provides much needed clarity in comparison to the above prose.

>    The term Concealed Seconds defines a count of seconds during which
>    the proportion of time lost through packet loss and discard exceeds
>    some threshold.
>
>    2.4 Numeric formats
>
>    This report block makes use of binary fractions.  The terminology
>    used is
>
>    S X:Y, where S indicates a signed representation,
>                 X the number of bits prior to the decimal place and
>                 Y the number of bits after the decimal place.
>
>    Hence 8:8 represents an unsigned number in the range 0.0039 to
>    255.996.
>
>3   High Resolution VoIP Metrics Report Block
>
>3.1 Block Description
>
>    This block comprises a header and a series of sub-blocks.  The
>    Map field in the header defines which sub-blocks are present.
>
>    Header sub-block
>     0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     BT=N      |           Map                  | block length |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        SSRC of source                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Correlation tag                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          Duration                             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Basic Loss/Discard Metrics sub-block
>     0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       Loss percentage         |      Discard percentage       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Number of frames expected                 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Clark               Expires June 2006                        [Page 4]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    Burst/Gap metrics sub-block
>     0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Threshold     |             Burst Duration (ms)               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                  Gap Duration (ms)                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Burst Loss/Disc Percentage    |  Gap Loss/Disc Percentage     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>    Playout metrics sub-block
>     0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                 On-time Playout Duration                    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |              On-time Active Speech Playout Duration         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                  Loss Concealment Duration                  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |              Buffer Adjustment Concealment Duration         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Concealed Seconds metrics sub-block
>    0               1               2               3
>    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Unimpaired Seconds                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Concealed Seconds                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Severely Concealed Seconds    | RESERVED      |  threshold  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Delay and PDV metrics sub-block
>     0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Network Round Trip Delay      |       End System Delay        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       External Delay          |           Mean PDV            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Max PDV              |       PDV Percentile          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   JB config   |  JB Metric    |          JB nominal           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          JB maximum           |          JB abs max           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>
>Clark               Expires June 2006                        [Page 5]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    Call Quality metrics sub-block
>     0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               R-LQ            |             R-CQ              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              MOS-LQ           |            MOS-CQ             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | R-LQ Ext In   | R-LQ Ext Out  |RFC3550 Payload| Media Type    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | RxSigLev (IP) |RxNoiseLev (IP)|  Local RERL   |  Remote RERL  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | RxSigLev (Ext)|RxNoiseLev(Ext)|       Metric Status           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Vendor specific extension sub-block
>   0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          Vendor ID                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Vendor ID Src |Manuf Code Src |     Extension Block Length    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Vendor-specific extension data             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>3.2 Header
>
>    Implementations MUST send the Header block within each High
>    Resolution Metrics report.
>
>    3.2.1 Block type
>    Nine High Resolution VoIP Metrics blocks are defined
>
>    mmm   = HR VoIP Metrics- Cumulative, Locally Generated
>    mmm+1 = HR VoIP Metrics- Cumulative, Relayed from Remote IP Endpoint
>    mmm+2 = HR VoIP Metrics- Cumulative. Relayed from Remote External
>            Endpoint
>    mmm+3 = HR VoIP Metrics- Interval - Locally Generated
>    mmm+4 = HR VoIP Metrics- Interval - Relayed from Remote IP Endpoint
>    mmm+5 = HR VoIP Metrics- Interval - Relayed from Remote External
>            Endpoint
>    mmm+6 = HR VoIP Metrics- Alert - Locally Generated
>    mmm+7 = HR VoIP Metrics- Alert - Relayed from Remote IP Endpoint
>    mmm+8 = HR VoIP Metrics- Alert - Relayed from Remote External
>            Endpoint
>
>
>    The time interval associated with these report blocks is left to the
>    implementation.  Spacing of RTCP reports should be in accordance
>    with RFC3550 however the specific timing of RTCP HR reports may
>    be determined in response to an internally derived alert such as a
>    threshold crossing.
>
>
>
>Clark               Expires June 2006                        [Page 6]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    3.2.2 Map field
>    An Map field indicates the optional sub-blocks present in this
>    report. A 1 indicates that the sub-block is present, and a 0 that
>    the block is absent.  If present, the sub-blocks must be in the
>    sequence defined in this document.
>    The bits have the following definitions:
>
>    0 Burst/Gap Metrics block
>    1 Concealed Seconds Metrics block
>    2 Playout Metrics block
>    3 Call Quality Metrics
>    4 Vendor specific extension block
>    5-15 Reserved, set to 0
>
>    3.2.3 Block Length
>    The block length indicates the length of this report in 32 bit
>    words and includes the header and any extension octets.
>
>    3.2.4 SSRC
>    The SSRC of the stream to which this report relates.
>
>    3.2.5 Correlation tag
>    The correlation tag facilitates the correlation of this report
>    block with other call or session related data or endpoint data.
>
>    3.2.6 Duration
>    The duration of time for which this report applies expressed in
>    milliseconds.  For cumulative reports this would be the call
>    duration. For interval reports this would be the duration of the
>    interval.
>
>3.3 Basic Loss/ Discard Metrics
>
>    The Basic Loss/Discard Metrics sub-block MUST be present. This
>    reports the proportion of frames lost by the network and the
>    proportion of frames discarded due to jitter.  For sample based

Hyphenate: "sample-based"

>    codecs such as G.711, a frame shall be defined as an RTP frame.
>    For endpoints that incorporate jitter buffers capable of fractional
>    frame discard the proportion of frames discarded MAY be determined on
>    the basis of the proportion of samples discarded.
>    If Voice Activity Detection is used then the proportion of frames
>    lost and discarded shall be determined based on transmitted packets,
>    i.e. frames that contained silence and were not transmitted shall
>    not be considered.
>    A frame shall be regarded as lost if it fails to arrive within an
>    implementation specific time window.

Hyphenate: "implementation-specific"

>A frame that arrives within
>    this time window but is too early or late to be played out shall
>    be regarded as discarded.  A frame shall be classified as one of
>    received (or OK), discarded or lost.
>    The Loss and Discard metrics are determined after the effects of
>    FEC, redundancy (RFC2198) or other similar process.
>
>    3.3.1 Proportion of frames lost
>    Proportion of frames lost within the network expressed as a binary
>    fraction.  Duplicate frames shall be disregarded.
>
>Clark               Expires June 2006                        [Page 7]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    3.3.2 Proportion of frames discarded
>    Proportion of voice frames received but discarded due to late or
>    early arrival.
>
>    3.3.3 Dead connection detection
>    If no RTP, SID or RTP no-op packets have been received for a pre-
>    specified time interval(for example ten seconds) then an RTCP HR
>    dead connection indication MUST be sent.  This time interval may
>    be changed during the connection, for example being longer at the
>    start of a call.  A dead connection is indicated by
>    setting both the fields above to 0xFFFF (equivalent to indicating
>    that 99.99% of packets have been both lost and discarded).
>    Receipt of an RTCP HR block with either field set to a value other
>    than 0xFFFF shall indicate that the remote endpoint HAS received
>    some valid RTP packets.
>
>    3.3.4 Number of frames expected
>    An count

"A count"

>of the number of frames expected, estimated if necessary.
>    If no frames have been received then this count shall be set to
>    zero, however if a dead connection is indicated then this count
>    shall be regarded as undefined.
>
>
>3.4 Burst/Gap metrics sub-block
>
>    The Burst/Gap metrics sub-block MAY be present and if present MUST
>    be indicated in the Map field.  The definition of Burst and Gap is
>    consistent with that defined in the RFC3611 VoIP Metrics block, with
>    the clarification that Loss and Discard are defined in terms of
>    frames (as described in 3.3 above). To accomodate the range of
>    jitter buffer algorithms and packet discard logic that may be used
>    by implementors, the method used to distinguish between bursts and
>    gaps may be an equivalent method to that defined in RFC3611.  The
>    method used SHOULD produce the same result as that defined in RFC3611
>    for conditions of burst packet loss however MAY produce different
>    results for conditions of time varying jitter.

Rewrite as "burst packet loss, but MAY".

>    If Voice Activity Detection is used the Burst and Gap Duration
>    shall be determined as if silence frames had been sent, i.e. a
>    period of silence in excess of Gmin frames MUST terminate a burst
>    condition.
>
>    The Burst/Gap Metrics sub-block contains the following elements.
>
>    3.4.1 Threshold
>    The Threshold is equivalent to Gmin in RFC3611, i.e. the number of
>    successive frames that must be received and not discarded prior to
>    and following a lost or discarded frame in order for this lost or
>    discarded frame to be regarded as part of a gap.
>
>    3.4.2 Burst Duration (ms)
>    The average duration of a burst of lost and discarded frames.
>
>    3.4.3 Gap Duration (ms)
>    The average duration of periods between bursts.
>
>Clark               Expires June 2006                        [Page 8]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    3.4.4 Burst Loss/Discard Rate
>    The proportion of Lost and Discarded frames during Bursts expressed
>    as a binary fraction.
>
>    3.4.5 Gap Loss/Discard Rate
>    The proportion of Lost and Discarded frames during Gaps expressed
>    as a binary fraction.
>
>3.5 Playout Metrics sub-block
>
>     The Playout Duration metrics sub-block MAY be present and
>     if present MUST be indicated in the Map field.
>
>     At any instant, the audio output at a receiver may be classified
>     as either 'normal' or 'concealed'.  'Normal' refers to playout of
>     audio payload received from the remote end.  Concealment refers
>     to playout of locally-generated signals used to mask the impact
>     of network impairments or to reduce the audibilty of jitter buffer
>     adaptations.
>
>     This sub-block accounts for the source of the output audio, in
>     millisecond units.  The on-time and active speech playout durations
>     allow calculation of the voice activity fraction.  The on-time, and
>     concealment durations allow calculation of concealment ratios.
>     A distinction between reactive (due to effective packet loss)
>     and proactive (due to buffer adaptation) concealment types MAY
>     be made.
>
>     3.5.1 On-time Playout Duration
>
>     'On-time' playout is the uninterrupted, in-sequence playout of valid
>     decoded audio information originating from the remote endpoint.
>     This includes comfort noise during periods of remote talker
>     silence, if VAD is used, and regenerated tones.  Equivalently,
>     on-time playout is that which is not concealed.
>
>     On-time playout duration MUST include both speech and silence
>     intervals, whether VAD is used or not.  This duration is reported
>     in millisecond units.
>
>     3.5.2 On-time Active Speech Playout Duration (optional)
>
>     The duration, in milliseconds, of the on-time playout duration
>     corresponding to playout of active speech signals, if known. If
>     not known, then this field is set to all ones (0x FFFF FFFF).
>
>     3.5.3 Loss Concealment Duration
>
>     The duration, in milliseconds, of audio playout corresponding to
>     Loss-type concealment.
>
>     Loss-type concealment is reactive insertion or deletion of samples
>     in the audio playout stream due to effective frame loss at the audio
>     decoder. "Effective frame loss" is the event in which a frame of
>     coded audio is simply not present at the audio decoder when
>
>Clark               Expires June 2006                        [Page 9]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>     required.  In this case, substitute audio samples are generally
>     formed, at the decoder or elsewhere, to reduce audible impairment.
>
>     Only loss-type concealment is used to form Concealed and Severely
>     Concealed Seconds counts, in Section 3.6.
>
>     3.5.4 Buffer Adjustment Concealment Duration (optional)
>
>     The duration, in milliseconds, of audio playout corresponding to
>     Buffer Adjustment-type concealment, if known. If not known, then
>     this field is set to all ones (0x FFFF FFFF).
>
>     Buffer Adjustment-type concealment is proactive or controlled
>     insertion or deletion of samples in the audio playout stream due to
>     jitter buffer adaptation, re-sizing or re-centering decisions within
>     the endpoint.
>
>     Concealment events which cannot be classified as Buffer Adjustment
>     -type MUST be classified as Loss-type.
>
>     Buffer adjustment-type concealment has lower audible impact, in
>     general, than loss-type concealment, and is hence exempted from
>     calculations of Concealed Second and Severely Concealed Seconds
>     counts (Section 3.6).
>
>
>3.6 Concealed Seconds metrics sub-block
>
>     The Concealed Seconds metrics sub-block MAY be present and if
>     present MUST be indicated in the Map field.
>
>     This block provides a description of potentially audible impairments
>     due to lost and discarded packets at the endpoint, expressed on a
>     time basis analogous to a traditional PSTN T1/E1 errored seconds
>     metric.
>
>     Periods of time of less than 1000ms shall be incorporated into these
>     counts if they exceed 500mS and shall be disregarded if they are
>     less than 500mS.
>
>
>     3.6.1 Unimpaired Seconds
>     A count of the number of unimpaired Seconds that have occurred on
>     this call.
>
>     An unimpaired Second is defined as a non-overlapping period of
>     1000ms during which no frame loss or discard due to late arrival has
>     occurred.  Every second in a call must be classified as either
>     OK or Concealed.
>
>     Normal playout of comfort noise or other silence concealment
>     signal during periods of talker silence, if VAD is used, shall be
>     counted as unimpaired seconds.
>
>
>
>Clark               Expires June 2006                        [Page 10]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>     3.6.2 Concealed Seconds
>
>     A count of the number of Concealed Seconds that have occurred on
>     this call.
>
>     A Concealed Second is defined as a non-overlapping period of 1000ms
>     during which any frame loss or discard due to late arrival has
>     occurred.
>
>     Equivalently, a concealed second is one in which
>     some Loss-type concealment (defined in S. 3.6) has occurred.
>     Buffer adjustment-type concealment shall not cause Concealed
>     Seconds to be incremented.
>
>     For clarification, the count of Concealed Seconds MUST
>     include the count of Severely Concealed Seconds.
>
>     3.6.3 Severely Concealed Seconds
>     A count of the number of Severely Concealed Seconds that have
>     occurred on this call.
>     A Severely Concealed Second is defined as a non-overlapping period
>     of 1000 ms during which the cumulative amount of time that has been
>     subject to frame loss or discard due to late arrival, exceeds the
>     SCS Threshold.
>
>     3.6.4 SCS Threshold
>     The SCS Threshold defines the amount of time corresponding to lost
>     or discarded frames that must occur within a one second period in
>     order for the second to be classified as a Severely Concealed
>     Second.  This is expressed in milliseconds and hence can represent
>     a range of 0.1 to 25.5 percent loss/ discard.
>
>     A default threshold of 50ms (5% effective frame loss per second)
>     is suggested.
>
>
>3.7 Delay and PDV metrics sub-block
>
>    The Delay and PDV metrics sub-block MUST be present.  This sub-block
>    contains a number of parameters related to overall delay (latency),
>    delay variation and the current jitter buffer configuration.
>
>    [Editor's note - need to add high and low water marks]
>
>    3.7.1 Network Round Trip Delay (ms)
>    The Network Round Trip Delay is the most recently measured value
>    of the RTP-to-RTP interface round trip delay, typically determined
>    using RTCP SR/RR. If no measured delay is available then this
>    field shall be set to 0xFFFF
>
>    3.7.2 End System Delay (ms)
>    The End System Delay is the internal round trip delay within the
>    endpoint, calculated using the nominal value of the jitter buffer
>    delay plus the accumulation/ encoding and decoding / playout delay
>    associated with the codec being used.
>
>Clark               Expires June 2006                        [Page 11]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    3.7.3 External Network Delay (ms)
>    The External Network Delay parameter indicates external network
>    round trip delay through cellular, satellite or other types of
>    network with significant delay impact, if known.  A value of
>    oxFFFF shall indicate that the delay is unknown.
>    If the external network is VoIP based then this parameter is
>    typically determined using RTCP SR/RR.  If the external network delay
>    is known and does not vary materially then this value may be
>    provisioned.
>
>    3.7.4 PDV/ Jitter Metrics

Should probably define/expand "PDV" here or earlier in the document.

>    Jitter metrics defined are:
>
>     (i)  Mean PDV - for cumulative reports this is a running average of
>          PDV and for interval reports this is an interval average
>          (16 bit, 12:4 format) expressed in milliseconds
>
>     (ii) Max PDV - the maximum PDV associated with the PDV percentile
>          (16 bit, 12:4 format) expressed in milliseconds
>
>     (iii)PDV Percentile - the percentage of time on the call during
>          which individual packet delays were below Max PDV, expressed
>          in 8:8 format.
>
>
>    3.7.5 PDV Type
>    Indicates the type of algorithm used to calculate PDV:
>
>       PPDV (0),
>       MAPDV (1),
>       Y.1540 (2)
>       Other values reserved
>
>    For example:-
>
>      (a) To report PPDV (RFC3550):
>          Mean PDV = PPDV
>          Max PDV = Undefined (FF FF)
>          PDV Percentile = Undefined (FFF)
>          PDV type = 0 PPDV
>
>      (b) To report 95th percentile MAPDV (G.1020):
>          Mean PDV = average MAPDV
>          Max PDV = Max MAPDV
>          PDV Percentile = 95.3
>          PDV type = 1 MAPDV
>
>     Note that implementations may either fix the reported percentile
>     and calculate the associated PDV level OR may fix a threshold PDV
>     level and calculate the associated percentile.
>
>    3.7.6 Jitter Buffer and PLC Configuration
>    Indicates the configuration of the jitter buffer and the type of PLC
>    algorithm in use.
>
>
>Clark               Expires June 2006                        [Page 12]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>         bits 0-3
>               0 = silence insertion
>               1 = simple replay, no attenuation
>               2 = simple replay, with attenuation
>               3 = enhanced
>               ? = ?
>               Other values reserved
>
>         bits 4-7
>               0 = Fixed jitter buffer
>               1 = Adaptive jitter buffer
>               Other values reserved
>
>    3.7.7 Jitter Buffer Size parameters
>    Current nominal, maximum and absolute maximum jitter buffer size
>    expressed in milliseconds.
>
>3.8 Call Quality Metrics sub-block
>    The Call Quality Metrics sub-block MAY be present however if present
>    it MUST be indicated in the Header Map field.

Consistent with sections 3.4, 3.5 and 3.6, rewrite as "MAY be present 
and if present ..."

>This sub-block reports
>    call quality metrics and estimates of signal, noise and echo levels.
>
>    Signal, noise and echo metrics should be long term averages and
>    should not be instantaneous values.
>
>    3.8.1 Listening and Conversation Quality R Factors
>    Expresses listening and conversational quality in terms of R factor,
>    a 0-120 scaled parameter in 8:8 format.  The algorithm used to
>    calculate R factor MAY be defined in the Voice/Data Quality Metric
>    Algorithm block.
>
>    3.8.2 Listening and Conversation Quality MOS Scores
>    Expresses listening and conversational quality in terms of MOS,
>    a 1-5 scaled parameter in 8:8 format.  The algorithm used to
>    calculate MOS MAY be defined in the Voice/Data Quality Metric
>    Algorithm block.

What block is that? DO you mean the "Configuration Block" (defined in 
Section 4)?

>    Note that R factors and MOS scores may be defined for both narrow
>    and wide-band VoIP calls.  R Factors are continuous for narrow and
>    wideband, hence the R factor for a wideband call may be higher than
>    that for a narrowband call.  MOS scores are scaled relative to
>    reference conditions and hence both narrow and wideband MOS occupy
>    the same 1-5 scale; this can lead to a wideband MOS being lower than
>    a narrowband MOS even though the listening quality may be higher.
>
>    3.8.3 R-LQ External In and Out.
>      R-LQ External In - measured by this endpoint for incoming
>                         connection on "other" side of this endpoint
>
>      R-LQ External Out - copied from RTCP XR message received from
>                       remote endpoint on "other" side of this endpoint
>
>    e.g. PhoneA <---> Bridge <----> Phone B
>
>    In XR message from Bridge to Phone A:-
>
>Clark               Expires June 2006                        [Page 13]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>         - R-LQ = quality for PhoneA ----> Bridge path
>
>         - R-LQ-ExtIn = quality for Bridge <---- Phone B path
>
>         - R-LQ-ExtOut = quality for Bridge -----> Phone B path
>
>    This allows PhoneA to assess
>
>      (i) received quality from the combination of
>
>          R-LQ measured at A
>                and
>          R-LQ-ExtIn reported by the Bridge to A
>
>      (ii) remote endpoint quality from the combination of
>
>          R-LQ reported by the Bridge
>                and
>          R-LQ-ExtOut reported by the Bridge
>
>    3.8.4 RFC3550 RTP Payload Type
>
>    The RTP Payload type field - as per RFC3551 and
>    http://www.iana.org/assignments/rtp-parameters
>
>    If the RFC3550 Payload type indicates a dynamic payload then
>    it is strongly recommended that the Extended Payload Descriptor
>    sub-block be sent in order that mid-stream management systems
>    can identify the codec type used.
>
>    3.8.5 Media Type
>       Media type -
>                   0 = No media present
>                   1 = Narrowband audio
>                   2 = Wideband audio
>                   3 = Fax Relay (T.38)
>                   4 = Voiceband data (V.152)
>                   5 = Modem Relay (V.150.1)
>                   6 = Text Relay (V.151)
>                   7 = Video

Why is "Media Type" in the Call Quality sub-block?

>    3.8.6 Received Signal and Noise Levels - IP side
>    The received signal level during talkspurts and the noise level
>    expressed in dBm0, for the decoded packet stream.
>
>    3.8.7 Received Signal and Noise Levels - External
>    The received signal level during talkspurts and the noise level
>    expressed in dBm0, for the PCM side of a gateway, audio input
>    from a handset or decoded packet stream for an IP-IP gateway.
>
>    3.8.8 Local and Remote Echo Return Loss
>    The Local and Remote Residual Echo Return Loss expressed in dB.
>    The Local RERL is the echo level that would be reflected into the
>    IP path due to line echo on the trunk side of this IP endpoint if
>    a gateway or acoustic echo if a handset.
>
>Clark               Expires June 2006                        [Page 14]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    The Remote RERL is the echo level that would be reflected into
>    the remote IP endpoint from the network "behind" it, and would
>    typically be measured at and reported from the remote endpoint.
>    This value is included as it may be used in calculating the R-CQ and
>    MOS-CQ values expressed in this report block.
>
>    3.8.9 Metric Status
>    Indicates the source of parameter values used in call quality
>    calculation:
>
>    Bit      Description                 Source
>
>    0-1    Local IP side Signal/Noise Levels measured on the incoming
>           decoded VoIP stream to this endpoint
>
>               00 = assumed
>               01 = measured for this call
>               10 = measured across multiple calls on this port
>               11 = measured across multiple ports
>
>    2-3    Remote IP side Signal/Noise Levels reported by the remote
>           IP endpoint through RTCP XR or equivalent
>
>               00 = assumed
>               01 = measured for this call
>               10 = measured across multiple calls on this port
>               11 = measured across multiple ports
>
>    4-5    Local Trunk side Signal/Noise Levels measured on the incoming
>           PCM, Audio or non-IP side of this endpoint
>
>               00 = assumed
>               01 = measured for this call
>               10 = measured across multiple calls on this port
>               11 = measured across multiple ports
>
>    6-7    Local Echo level measured in the incoming line/ trunk/
>           handset direction at this endpoint after the effects of echo
>           cancellation
>
>               00 = assumed
>               01 = measured for this call
>               10 = measured across multiple calls on this port
>               11 = measured across multiple ports
>
>    8      Remote Echo level measured in the incoming line/ trunk/
>           handset direction at the remote endpoint after the effects of
>           echo cancellation and reported to this endpoint via RTCP XR
>           or equivalent.
>
>               0 = assumed
>               1 = reported from remote endpoint
>
>    9-15  Reserved
>
>
>Clark               Expires June 2006                        [Page 15]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    For example, if this endpoint is "C" in the diagram below then the
>    following definitions would apply.
>
>    Endpoint B -----RTP-------> Gateway C <-----PCM-------> D
>    "Remote"                    "Local"        "Trunk/PCM/External"
>        Reporting endpoint is "B"
>
>        Local IP side signal/noise metrics relate to signal/noise levels
>        from decoded RTP packets received by C from B
>
>        Remote IP side signal/noise metrics relate to signal/noise levels
>        from decoded RTP packets received by B from C, and reported by B
>        to C through RTCP XR or RTCP HR VoIP Metrics blocks
>
>        Local Trunk side signal/noise metrics relate to signal/noise
>        levels from the PCM signal received by C from D
>
>        Local Echo level relates to the proportion of the signal passing
>        from B to C to D that is reflected back to C at some point
>        between C and D or on the far side of D.  This would typically be
>        line echo or acoustic echo.
>
>        Remote Echo level relates to the proportion of the signal passing
>        from D to C to B that is reflected back to B at some point
>        between B and the user.  This echo level is typically measured at
>        B and reported to C via RTCP XR or RTCP HR VoIP Metrics blocks.
>
>
>3.9 Vendor Extension sub-block
>
>    The Vendor Extension sub-block MAY be present however if present
>    it MUST be indicated in the Header Map field.

Consistent with previous sections, rewrite as "MAY be present and if 
present MUST ..."

>    One or more vendor extension sub-blocks may be added.  Each
>    extension block consists of an extension header and vendor-specific
>    extension data. The extension header has the form Vendor ID, Vendor
>    ID Source and Extension Block Length. The Extension Block Length is
>    defined as including these extension header and extension data
>    octets but does not include any subsequent vendor extension
>    sub-blocks.  An implementation can skip over a
>    vendor extension sub-block that it does not understand.
>
>    The Vendor ID Source field indicates whether the four-octet Vendor ID
>    is based on ITU T.35 or is an IANA private enterprise number. The
>    designated values for these options are 1 and 2 respectively. If the
>    Vendor ID Source field is assigned a value of 0, then all of the
>    fields in the vendor extension sub-block with the exception of the
>    Vendor ID Source field and the Extension Block Length field have
>    proprietary definitions.
>
>    If the Vendor ID is based on ITU T.35, its first two octets either
>    contain a country code from Annex A of ITU Recommendation T.35
>    followed by 0x00 or an escape code of 0xFF followed by a country code
>    from Annex B of T.35. The next two octets comprise a terminal
>    provider code allocated by a national assignment authority
>
>Clark               Expires June 2006                        [Page 16]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    (http://people.itu.int/~campos/t35/t35db.htm). This field is padded
>    with leading zeros if necessary. If a vendor has multiple
>    terminal provider codes in different registries (e.g. the H-series,
>    T-series and V-series registries for the USA), then this provenance
>    shall be indicated in the Manufacturer Code Source field. Possible
>    values of the Manufacturer Code Source field are:
>          0 Unspecified/don't care (may be used if there is no conflict)
>          1 G-series registry
>          2 H-series registry
>          3 T-series registry
>          4 V-series registry
>          5-255 Reserved.
>
>    If the four-octet Vendor ID is an IANA private enterprise number,
>    then it is padded with leading zeros as necessary. Current private
>    enterprise numbers (www.iana.org/assignments/enterprise-numbers)
>    can be accommodated within two octets. The additional two octets
>    provide for future growth.
>
>4. RTCP HR Configuration Block
>
>    This block type provides a flexible means to describe the algorithms
>    used for call quality calculation and other data.  This block need
>    only be exchanged occasionally, for example sent once at the start
>    of a call.
>
>    Header sub-block
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     BT=N      |           Map                  | block length |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        SSRC of source                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Correlation tag                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Algorithm sub-block
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Alg type      | Descriptor len|       Algorithm descriptor... |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   ... Algorithm descriptor                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Extended Payload Descriptor sub-block
>     0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Sample Rate                             | Frames per Pkt |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Frame Size (octets)        |        Frame size (mS)        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                 Payload descriptor (optional)                 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>Clark               Expires June 2006                        [Page 17]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    Vendor Specific Extensions sub-block
>     0               1               2               3
>     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          Vendor ID                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Vendor ID Src |Manuf Code Src |     Extension Block Length    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                    Vendor-specific extension data             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>4.1 Header
>
>    Implementations MUST send the Header block within each RTCP HR
>    Configuration report.
>
>    4.2.1 Block type
>    One RTCP HR Configuration blocks is defined
>
>    mmm+9   = RTCP HR Configuration Block
>
>
>    The time interval associated with these report blocks is left to the
>    implementation.  Spacing of RTCP reports should be in accordance
>    with RFC3550 however the specific timing of RTCP HR reports may
>    be determined in response to an internally derived alert such as a
>    threshold crossing.
>
>    4.2.2 Map field
>    An Map field indicates the optional sub-blocks present in this
>    report. A 1 indicates that the sub-block is present, and a 0 that
>    the block is absent.  If present, the sub-blocks must be in the
>    sequence defined in this document.
>    The bits have the following definitions:
>
>    0 Algorithm Descriptor 1
>    1 Algorithm Descriptor 2
>    2 Algorithm Descriptor 3
>    3 Algorithm Descriptor 4
>    4 Algorithm Descriptor 5
>    5 Algorithm Descriptor 6
>    6 Algorithm Descriptor 7
>    7 Algorithm Descriptor 8
>    8 Payload Descriptor
>    9 Vendor Specific Extension
>    10-15 Reserved, set to 0
>
>    4.2.3 Block Length
>    The block length indicates the length of this report in 32 bit
>    words and includes the header and any extension octets.
>
>    4.2.4 SSRC
>    The SSRC of the stream to which this report relates.
>
>
>Clark               Expires June 2006                        [Page 18]
>
>draft-clark-avt-rtcphr-00.txt                          December 2005
>
>    4.2.5 Correlation tag
>    The correlation tag facilitates the correlation of this report
>    block with other call or session related data or endpoint data.
>
>4.3 Algorithm description

I think this section should do more to explain how the sub-block can 
be used to clearly describe the algorithm being used. It might be 
useful, for example, to describe how Sage's SMOS score would be described.

>    The Algorithm Description sub-block MAY be present however if present
>    MUST be indicated in the MAP field
>    The Algorithm descriptor is a bit field which indicates which
>    algorithm is being described.  The bits are defined as:-
>
>       Bit 0:      MOS-LQ Algorithm
>       Bit 1:      MOS-CQ Algorithm
>       Bit 2:      R-LQ Algorithm
>       Bit 3:      R-CQ Algorithm
>       Bit 4-7:    Reserved and set to 0
>
>   The descriptor length gives the overall length of the descriptor in
>   32 bit words and includes the algorithm descriptor and length fields.
>
>   The algorithm descriptor is a text field that contains the
>   description or name of the algorithm.  If the algorithm name is
>   shorter than the length of the field then the trailing octets
>   must be set to 0x00.
>
>   For example, an implementation may report:
>
>       Algorithm descriptor = 0x0F   - R and MOS algorithms
>       Descriptor length = 3         - 3 words
>       Descriptor = "Alg X" 0x00     - description
>
>   Call quality estimation algorithms may be defined for listening or
>   conversational quality MOS or R factor.
>
>4.4 Extended payload description field
>
>    The Extended Payload Description sub-block MAY be present however
>    if present it MUST be indicated in the Header Map field.

Again, to be consistent with prior sections, rewrite as "MAY be 
present and if present MUST ..."

That's it.

Regards, Keith

----------------
Keith Lantz, Ph.D.                        Voice: +1 (408) 902-3302
Cisco Distinguished Engineer              FAX:   +1 (408) 525-4971
Voice & Video Systems Architecture        Email: klantz (at) cisco.com
Cisco Systems, Inc.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt