draft-ietf-avt-rtcp-report-extns-05.txt   draft-ietf-avt-rtcp-report-extns-06.txt 
Internet Engineering Task Force Expires: 30 October 2003 Internet Engineering Task Force Expires: 19 November 2003
Audio/Video Transport Working Group Audio/Video Transport Working Group
Timur Friedman, Paris 6 Timur Friedman, Paris 6
Ramon Caceres, ShieldIP Ramon Caceres, ShieldIP
Alan Clark, Telchemy Alan Clark, Telchemy
Editors Editors
RTP Control Protocol Extended Reports (RTCP XR) RTP Control Protocol Extended Reports (RTCP XR)
draft-ietf-avt-rtcp-report-extns-05.txt draft-ietf-avt-rtcp-report-extns-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.1.2 Bit Vector Chunk .......................................... 15 4.1.2 Bit Vector Chunk .......................................... 15
4.1.3 Terminating Null Chunk .................................... 15 4.1.3 Terminating Null Chunk .................................... 15
4.2 Duplicate RLE Report Block ................................ 16 4.2 Duplicate RLE Report Block ................................ 16
4.3 Packet Receipt Times Report Block ......................... 17 4.3 Packet Receipt Times Report Block ......................... 17
4.4 Receiver Reference Time Report Block ...................... 20 4.4 Receiver Reference Time Report Block ...................... 20
4.5 DLRR Report Block ......................................... 21 4.5 DLRR Report Block ......................................... 21
4.6 Statistics Summary Report Block ........................... 22 4.6 Statistics Summary Report Block ........................... 22
4.7 VoIP Metrics Report Block ................................. 25 4.7 VoIP Metrics Report Block ................................. 25
4.7.1 Packet Loss and Discard Metrics ........................... 26 4.7.1 Packet Loss and Discard Metrics ........................... 26
4.7.2 Burst Metrics ............................................. 27 4.7.2 Burst Metrics ............................................. 27
4.7.3 Delay Metrics ............................................. 29 4.7.3 Delay Metrics ............................................. 30
4.7.4 Signal Related Metrics .................................... 30 4.7.4 Signal Related Metrics .................................... 30
4.7.5 Call Quality or Transmission Quality Metrics .............. 33 4.7.5 Call Quality or Transmission Quality Metrics .............. 33
4.7.6 Configuration Parameters .................................. 34 4.7.6 Configuration Parameters .................................. 34
4.7.7 Jitter Buffer Parameters .................................. 35 4.7.7 Jitter Buffer Parameters .................................. 35
5. SDP Signaling ............................................. 36 5. SDP Signaling ............................................. 36
5.1 The SDP Attribute ......................................... 37 5.1 The SDP Attribute ......................................... 37
5.2 Usage in Offer/Answer ..................................... 39 5.2 Usage in Offer/Answer ..................................... 40
5.3 Usage Outside of Offer/Answer ............................. 41 5.3 Usage Outside of Offer/Answer ............................. 41
6. IANA Considerations ....................................... 41 6. IANA Considerations ....................................... 42
6.1 XR Packet Type ............................................ 41 6.1 XR Packet Type ............................................ 42
6.2 RTCP XR Block Type Registry ............................... 42 6.2 RTCP XR Block Type Registry ............................... 42
6.3 The "rtcp-xr" SDP Attribute ............................... 42 6.3 The "rtcp-xr" SDP Attribute ............................... 43
7. Security Considerations ................................... 43 7. Security Considerations ................................... 44
A. Algorithms ................................................ 44 A. Algorithms ................................................ 45
A.1 Sequence Number Interpretation ............................ 44 A.1 Sequence Number Interpretation ............................ 45
A.2 Example Burst Packet Loss Calculation ..................... 46 A.2 Example Burst Packet Loss Calculation ..................... 46
Intellectual Property ..................................... 48 Intellectual Property ..................................... 48
Full Copyright Statement .................................. 48 Full Copyright Statement .................................. 49
Acknowledgments ........................................... 49 Acknowledgments ........................................... 49
Contributors .............................................. 49 Contributors .............................................. 50
Authors' Addresses ........................................ 50 Authors' Addresses ........................................ 50
References ................................................ 51 References ................................................ 52
Normative References ...................................... 51 Normative References ...................................... 52
Non-Normative References .................................. 52 Non-Normative References .................................. 53
1. Introduction 1. Introduction
This document defines the Extended Report (XR) packet type for the This document defines the Extended Report (XR) packet type for the
RTP Control Protocol (RTCP) [9], and defines how the use of XR RTP Control Protocol (RTCP) [9], and defines how the use of XR
packets can be signaled by an application if it employs the Session packets can be signaled by an application if it employs the Session
Description Protocol (SDP) [4]. XR packets convey information beyond Description Protocol (SDP) [4]. XR packets convey information beyond
that already contained in the reception report blocks of RTCP's that already contained in the reception report blocks of RTCP's
sender report (SR) or Receiver Report (RR) packets. The information sender report (SR) or Receiver Report (RR) packets. The information
is of use across RTP profiles, and so is not appropriately carried in is of use across RTP profiles, and so is not appropriately carried in
skipping to change at page 27, line 5 skipping to change at page 27, line 5
Packet Loss and Discard Metrics, Delay Metrics, Signal Related Packet Loss and Discard Metrics, Delay Metrics, Signal Related
Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, Call Quality or Transmission Quality Metrics, Configuration
Metrics, and Jitter Buffer Parameters. Metrics, and Jitter Buffer Parameters.
4.7.1 Packet Loss and Discard Metrics 4.7.1 Packet Loss and Discard Metrics
It is very useful to distinguish between packets lost by the network It is very useful to distinguish between packets lost by the network
and those discarded due to jitter. Both have equal effect on the and those discarded due to jitter. Both have equal effect on the
quality of the voice stream however having separate counts helps quality of the voice stream however having separate counts helps
identify the source of quality degradation. These fields MUST be identify the source of quality degradation. These fields MUST be
populated. populated, and MUST be set to zero if no packets have been received.
loss rate: 8 bits loss rate: 8 bits
The fraction of RTP data packets from the source lost since the The fraction of RTP data packets from the source lost since the
beginning of reception, expressed as a fixed point number with beginning of reception, expressed as a fixed point number with
the binary point at the left edge of the field. This value is the binary point at the left edge of the field. This value is
calculated by dividing the total number of packets lost (after calculated by dividing the total number of packets lost (after
the effects of applying any error protection such as FEC) by the the effects of applying any error protection such as FEC) by the
total number of packets expected, multiplying the result of the total number of packets expected, multiplying the result of the
division by 256, limiting the maximum value to 255 (to avoid division by 256, limiting the maximum value to 255 (to avoid
overflow), and taking the integer part. The numbers of overflow), and taking the integer part. The numbers of
skipping to change at page 29, line 9 skipping to change at page 29, line 9
burst density: 8 bits burst density: 8 bits
The fraction of RTP data packets within burst periods since the The fraction of RTP data packets within burst periods since the
beginning of reception that were either lost or discarded. This beginning of reception that were either lost or discarded. This
value is expressed as a fixed point number with the binary point value is expressed as a fixed point number with the binary point
at the left edge of the field. It is calculated by dividing the at the left edge of the field. It is calculated by dividing the
total number of packets lost or discarded (excluding duplicate total number of packets lost or discarded (excluding duplicate
packet discards) within burst periods by the total number of packet discards) within burst periods by the total number of
packets expected within the burst periods, multiplying the packets expected within the burst periods, multiplying the
result of the division by 256, limiting the maximum value to 255 result of the division by 256, limiting the maximum value to 255
(to avoid overflow), and taking the integer part. (to avoid overflow), and taking the integer part. This field
MUST be populated and MUST be set to zero if no packets have
been received.
gap density: 8 bits gap density: 8 bits
The fraction of RTP data packets within inter-burst gaps since The fraction of RTP data packets within inter-burst gaps since
the beginning of reception that were either lost or discarded. the beginning of reception that were either lost or discarded.
The value is expressed as a fixed point number with the binary The value is expressed as a fixed point number with the binary
point at the left edge of the field. It is calculated by point at the left edge of the field. It is calculated by
dividing the total number of packets lost or discarded dividing the total number of packets lost or discarded
(excluding duplicate packet discards) within gap periods by the (excluding duplicate packet discards) within gap periods by the
total number of packets expected within the gap periods, total number of packets expected within the gap periods,
multiplying the result of the division by 256, limiting the multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the integer maximum value to 255 (to avoid overflow), and taking the integer
part. part. This field MUST be populated and MUST be set to zero if
no packets have been received.
burst duration: 16 bits burst duration: 16 bits
The mean duration, expressed in milliseconds, of the burst The mean duration, expressed in milliseconds, of the burst
periods that have occurred since the beginning of reception. periods that have occurred since the beginning of reception.
The duration of each period is calculated based upon the packets The duration of each period is calculated based upon the packets
that mark the beginning and end of that period. It is equal to that mark the beginning and end of that period. It is equal to
the timestamp of the end packet, plus the duration of the end the timestamp of the end packet, plus the duration of the end
packet, minus the timestamp of the beginning packet. If the packet, minus the timestamp of the beginning packet. If the
actual values are not available, estimated values MUST be used. actual values are not available, estimated values MUST be used.
If there have been no burst periods, the burst duration value If there have been no burst periods, the burst duration value
skipping to change at page 30, line 34 skipping to change at page 30, line 38
calculate round trip delay. A value of 0 is permissible, however calculate round trip delay. A value of 0 is permissible, however
this field MUST be populated as soon as a delay estimate is this field MUST be populated as soon as a delay estimate is
available. available.
end system delay: 16 bits end system delay: 16 bits
The most recently estimated end system delay, expressed in The most recently estimated end system delay, expressed in
milliseconds. End system delay is defined as the sum of the milliseconds. End system delay is defined as the sum of the
total sample accumulation and encoding delay associated with the total sample accumulation and encoding delay associated with the
sending direction and the jitter buffer, decoding, and playout sending direction and the jitter buffer, decoding, and playout
buffer delay associated with the receiving direction. This buffer delay associated with the receiving direction. This
delay MAY be estimated or measured. This value MUST be provided delay MAY be estimated or measured. This value SHOULD be
in all VoIP metrics reports. provided in all VoIP metrics reports. If an implementation is
unable to provide the data, the value 0 MUST be used.
Note that the one way symmetric VoIP segment delay may be calculated Note that the one way symmetric VoIP segment delay may be calculated
from the round trip and end system delays as follows. If the round from the round trip and end system delays as follows. If the round
trip delay is denoted RTD and the end system delays associated with trip delay is denoted RTD and the end system delays associated with
the two endpoints are ESD(A) and ESD(B) then: the two endpoints are ESD(A) and ESD(B) then:
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
4.7.4 Signal Related Metrics 4.7.4 Signal Related Metrics
The following metrics are intended to provide real time information The following metrics are intended to provide real time information
related to the non-packet elements of the voice over IP system to related to the non-packet elements of the voice over IP system to
assist with the identification of problems affecting call quality. assist with the identification of problems affecting call quality.
The values identified below must be determined for the received audio The values identified below must be determined for the received audio
signal. The information required to populate these fields may not be signal. The information required to populate these fields may not be
available in all systems, although it is strongly recommended that available in all systems, although it is strongly recommended that
this data SHOULD be provided to support problem diagnosis. this data SHOULD be provided to support problem diagnosis.
signal level: 8 bits signal level: 8 bits
The voice signal relative level is defined as the ratio of the The voice signal relative level is defined as the ratio of the
skipping to change at page 31, line 10 skipping to change at page 31, line 14
The following metrics are intended to provide real time information The following metrics are intended to provide real time information
related to the non-packet elements of the voice over IP system to related to the non-packet elements of the voice over IP system to
assist with the identification of problems affecting call quality. assist with the identification of problems affecting call quality.
The values identified below must be determined for the received audio The values identified below must be determined for the received audio
signal. The information required to populate these fields may not be signal. The information required to populate these fields may not be
available in all systems, although it is strongly recommended that available in all systems, although it is strongly recommended that
this data SHOULD be provided to support problem diagnosis. this data SHOULD be provided to support problem diagnosis.
signal level: 8 bits signal level: 8 bits
The voice signal relative level is defined as the ratio of the The voice signal relative level is defined as the ratio of the
signal level to a 0dBm0 reference [10], expressed in decibels as signal level to a 0 dBm0 reference [10], expressed in decibels
a signed integer in two's complement form. This is measured as a signed integer in two's complement form. This is measured
only for packets containing speech energy. The intent of this only for packets containing speech energy. The intent of this
metric is not to provide a precise measurement of the signal metric is not to provide a precise measurement of the signal
level but to provide a real time indication that the signal level but to provide a real time indication that the signal
level may be excessively high or low. level may be excessively high or low.
signal level = 10 Log10 ( rms talkspurt power (mW) ) signal level = 10 Log10 ( rms talkspurt power (mW) )
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
Typical values should be generally in the -15 to -20 dBm range. Typical values should be generally in the -15 to -20 dBm range.
noise level: 8 bits noise level: 8 bits
The noise level is defined as the ratio of the silent period The noise level is defined as the ratio of the silent period
background noise level to a 0 dBm0 reference, expressed in background noise level to a 0 dBm0 reference, expressed in
decibels as a signed integer in two's complement form. decibels as a signed integer in two's complement form.
noise level = 10 Log10 ( rms silence power (mW) ) noise level = 10 Log10 ( rms silence power (mW) )
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
residual echo return loss (RERL): 8 bits residual echo return loss (RERL): 8 bits
The residual echo return loss is defined as the sum of the The residual echo return loss value may be measured directly by
measured echo return loss (ERL) and the echo return loss the VoIP end system's echo canceller or may be estimated by
enhancement (ERLE) of the echo canceller (if present), expressed adding the echo return loss (ERL) and echo return loss
in dB as a signed integer in two's complement form. enhancement (ERLE) values reported by the echo canceller.
The residual echo return loss relates to the effective echo
level that a user would hear. The amount of echo that can occur
in analog loops can be significant, and therefore echo
cancellers are typically used to try and eliminate or reduce the
audible echo. The amount of echo is typically described as an
"echo return loss" (i.e. ratio between the transmitted signal
level and the received echo level) expressed in dB. The
effectiveness of an echo canceller is normally described in
terms of "echo return loss enhancement", i.e. an echo canceller
increases the effective echo return loss and makes the audible
echo smaller. Hence the residual echo return loss (RERL) is the
sum of the echo return loss (ERL) and the echo return loss
enhancement (ERLE) expressed in dB.
A low level of echo return loss (say less than 20 dB) in
conjunction with some delay can lead to hollowness or audible
echo. A high level of echo return loss (say over 40 dB) is
preferable.
The ERL and ERLE parameters are often available directly from the RERL(dB) = ERL (dB) + ERLE (dB)
echo canceler contained within the VoIP end system. They relate to
the echo on the external network attached to the end point.
In the case of a VoIP gateway this would be line echo that typically In the case of a VoIP gateway the source of echo is typically
occurs at 2-4 wire conversion points in the network. Echo return line echo that occurs at 2-4 wire conversion points in the
loss from typical 2-4 wire conversions can be in the 8-12 dB range. network. This can be in the 8-12 dB range. A line echo
A line echo canceler can provide an ERLE of 30 dB or more and hence canceler can provide an ERLE of 30 dB or more and hence reduce
reduce this to 40-50 dB. In the case of an IP phone this could be this to 40-50 dB. In the case of an IP phone this could be
acoustic coupling between handset speaker and microphone or
residual acoustic echo from speakerphone operation, and may more residual acoustic echo from speakerphone operation, and may more
correctly be termed terminal coupling loss (TCL). A typical handset correctly be termed terminal coupling loss (TCL). A typical
would result in 40-50 dB of echo due to acoustic feedback. handset would result in 40-50 dB of echo loss due to acoustic
feedback.
Typical values for RERL are as follows: Examples:
(i) IP gateway connected to circuit switched network with 2 wire loop - IP gateway connected to circuit switched network with 2 wire
Without echo cancellation, typical 2-4 wire converter ERL of 12 dB loop. Without echo cancellation, typical 2-4 wire converter ERL
RERL = ERL + ERLE = 12 + 0 = 12 dB of 12 dB. RERL = ERL + ERLE = 12 + 0 = 12 dB.
(ii) IP gateway connected to circuit switched network with 2 wire loop - IP gateway connected to circuit switched network with 2 wire
With echo canceler that improves echo by 30 dB loop. With echo canceler that improves echo by 30 dB. RERL =
RERL = ERL + ERLE = 12 + 30 = 42 dB ERL + ERLE = 12 + 30 = 42 dB.
(iii) IP phone with conventional handset - IP phone with conventional handset. Acoustic coupling from
Acoustic coupling from handset speaker to microphone 40 dB handset speaker to microphone (terminal coupling loss) is
Residual echo return loss = TCL = 40 dB typically 40 dB. RERL = TCL = 40 dB.
If we denote the "local" end of the VoIP path as A and the remote end If we denote the local end of the VoIP path as A and the remote
as B and if the sender loudness rating (SLR) and receiver loudness end as B and if the sender loudness rating (SLR) and receiver
rating (RLR) are known for A (default values 8 dB and 2 dB loudness rating (RLR) are known for A (default values 8 dB and 2
respectively), then the echo loudness level at end A (talker echo dB respectively), then the echo loudness level at end A (talker
loudness rating or TELR) is given by: echo loudness rating or TELR) is given by:
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B) TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
Hence in order to incorporate echo into a voice quality estimate at Hence in order to incorporate echo into a voice quality estimate
the A end of a VoIP connection it is desirable to send the ERL + ERLE at the A end of a VoIP connection it is desirable to send the
value from B to A. ERL + ERLE value from B to A using a format such as RTCP XR.
For an IP phone with handset this metric MUST be set to the designed Echo related information may not be available in all VoIP end
or measured terminal coupling loss, which would typically be 40-50 systems. As echo does have a significant effect on
dB. conversational quality it is recommended that estimated values
for echo return loss and terminal coupling loss be provided (if
sensible estimates can be reasonably determined).
For a PC softphone or speakerphone this metric MUST be set to either Typical values for end systems are given below to provide
the value reported by the acoustic echo canceler or to 127 to guidance:
indicate an undefined value.
For an IP gateway with ERL and ERLE measurements this metric MUST be - IP Phone with handset: typically 45 dB.
reported as ERL + ERLE.
For an IP gateway without ERL and ERLE measurement capability then - PC softphone or speakerphone: extremely variable, consider
this metric MUST be reported as 12 dB if line echo cancellation is reporting "undefined" (127).
disabled and 40 dB if line echo cancellation is enabled.
- IP gateway with line echo canceller: typically has ERL and
ERLE available.
- IP gateway without line echo canceller: frequently a source of
echo related problems, consider reporting either a low value (12
dB) or "undefined" (127).
Gmin Gmin
See Configuration Parameters (Section 4.7.6, below). See Configuration Parameters (Section 4.7.6, below).
4.7.5 Call Quality or Transmission Quality Metrics 4.7.5 Call Quality or Transmission Quality Metrics
The following metrics are direct measures of the call quality or The following metrics are direct measures of the call quality or
transmission quality, and incorporate the effects of codec type, transmission quality, and incorporate the effects of codec type,
packet loss, discard, burstiness, delay etc. These metrics may not packet loss, discard, burstiness, delay etc. These metrics may not
be available in all systems however SHOULD be provided in order to be available in all systems however SHOULD be provided in order to
skipping to change at page 35, line 6 skipping to change at page 34, line 47
noticeable degradation in call quality; during gap periods, if noticeable degradation in call quality; during gap periods, if
packet loss or discard occurs, each lost or discarded packet packet loss or discard occurs, each lost or discarded packet
would be preceded by and followed by a sequence of at least 16 would be preceded by and followed by a sequence of at least 16
received non-discarded packets. Note that lost or discarded received non-discarded packets. Note that lost or discarded
packets that occur within Gmin packets of a report being packets that occur within Gmin packets of a report being
generated may be reclassified as being part of a burst or gap in generated may be reclassified as being part of a burst or gap in
later reports. ETSI TS 101 329-5 [3] defines a computationally later reports. ETSI TS 101 329-5 [3] defines a computationally
efficient algorithm for measuring burst and gap density using a efficient algorithm for measuring burst and gap density using a
packet loss/discard event driven approach. This algorithm is packet loss/discard event driven approach. This algorithm is
reproduced in Appendix A.2 of the present document. Gmin MUST reproduced in Appendix A.2 of the present document. Gmin MUST
not be zero and MUST be provided. not be zero and MUST be provided and MUST remain constant across
VoIP Metrics report blocks for the duration of the RTP session.
receiver configuration byte (RX config): 8 bits receiver configuration byte (RX config): 8 bits
This byte consists of the following fields: This byte consists of the following fields:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate| |PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
packet loss concealment (PLC): 2 bits packet loss concealment (PLC): 2 bits
Standard (11) / enhanced (10) / disabled (01) / unspecified Standard (11) / enhanced (10) / disabled (01) / unspecified
(00). When PLC = 11 then a simple replay or interpolation (00). When PLC = 11 then a simple replay or interpolation
algorithm is being used to fill-in the missing packet. algorithm is being used to fill-in the missing packet; this
This is typically able to conceal isolated lost packets approach is typically able to conceal isolated lost packets
with loss rates under 3%. When PLC = 10 then an enhanced at low packet loss rates. When PLC = 10 then an enhanced
interpolation algorithm is being used. This would interpolation algorithm is being used; algorithms of this
typically be able to conceal lost packets for loss rates of type are able to conceal high packet loss rates
10% or more. When PLC = 01 then silence is inserted in effectively. When PLC = 01 then silence is being inserted
place of lost packets. When PLC = 00 then no information in place of lost packets. When PLC = 00 then no
is available concerning the use of PLC however for some information is available concerning the use of PLC, however
codecs this may be inferred. for some codecs this may be inferred.
jitter buffer adaptive (JBA): 2 bits jitter buffer adaptive (JBA): 2 bits
Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
(00). When the jitter buffer is adaptive then its size is (00). When the jitter buffer is adaptive then its size is
being dynamically adjusted to deal with varying levels of being dynamically adjusted to deal with varying levels of
jitter. When non-adaptive, the jitter buffer size is jitter. When non-adaptive, the jitter buffer size is
maintained at a fixed level. When either adaptive or non- maintained at a fixed level. When either adaptive or non-
adaptive modes are specified then the jitter buffer size adaptive modes are specified then the jitter buffer size
parameters below MUST be specified. parameters below MUST be specified.
skipping to change at page 36, line 12 skipping to change at page 36, line 4
degree of "aggressiveness" of a an adaptive jitter buffer degree of "aggressiveness" of a an adaptive jitter buffer
and may be estimated. A value of 0 indicates that the and may be estimated. A value of 0 indicates that the
adjustment time is unknown for this implementation. adjustment time is unknown for this implementation.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
4.7.7 Jitter Buffer Parameters 4.7.7 Jitter Buffer Parameters
The values reported in these fields SHOULD be the most recently
obtained values at the time of reporting.
jitter buffer nominal delay (JB nominal): 16 bits jitter buffer nominal delay (JB nominal): 16 bits
This is the current nominal jitter buffer delay in milliseconds, This is the current nominal jitter buffer delay in milliseconds,
which corresponds to the nominal jitter buffer delay for packets which corresponds to the nominal jitter buffer delay for packets
that arrive exactly on time. This parameter MUST be provided that arrive exactly on time. This parameter MUST be provided
for both fixed and adaptive jitter buffer implementations. for both fixed and adaptive jitter buffer implementations.
jitter buffer maximum delay (JB maximum): 16 bits jitter buffer maximum delay (JB maximum): 16 bits
This is the current maximum jitter buffer delay in milliseconds This is the current maximum jitter buffer delay in milliseconds
which corresponds to the earliest arriving packet that would not which corresponds to the earliest arriving packet that would not
skipping to change at page 37, line 40 skipping to change at page 37, line 34
/ pkt-rcpt-times / pkt-rcpt-times
/ rcvr-rtt / rcvr-rtt
/ stat-summary / stat-summary
/ voip-metrics / voip-metrics
/ format-ext / format-ext
pkt-loss-rle = "pkt-loss-rle" ["=" max-size] pkt-loss-rle = "pkt-loss-rle" ["=" max-size]
pkt-dup-rle = "pkt-dup-rle" ["=" max-size] pkt-dup-rle = "pkt-dup-rle" ["=" max-size]
pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size] pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size] rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
stat-summary = "stat-summary" rcvr-rtt-mode = "all"
/ "sender"
stat-summary = "stat-summary" ["=" stat-flag *("," stat-flag)]
stat-flag = "loss"
/ "dup"
/ "jitt"
/ "TTL"
/ "HL"
voip-metrics = "voip-metrics" voip-metrics = "voip-metrics"
max-size = 1*DIGIT ; maximum block size in octets max-size = 1*DIGIT ; maximum block size in octets
DIGIT = %x30-39 DIGIT = %x30-39
rcvr-rtt-mode = "all"
/ "sender"
format-ext = non-ws-string format-ext = non-ws-string
non-ws-string = 1*(%x21-FF) non-ws-string = 1*(%x21-FF)
CRLF = %d13.10 CRLF = %d13.10
The "rtcp-xr" attribute contains zero, one, or more XR block related The "rtcp-xr" attribute contains zero, one, or more XR block related
parameters. Each parameter signals functionality for an XR block, or parameters. Each parameter signals functionality for an XR block, or
a group of XR blocks. The attribute is extensible so that parameters a group of XR blocks. The attribute is extensible so that parameters
can be defined for any future XR block (and a parameter should be can be defined for any future XR block (and a parameter should be
defined for every future block). defined for every future block).
skipping to change at page 38, line 44 skipping to change at page 38, line 44
pkt-rcpt-times 3 Packet Receipt Times Report Block pkt-rcpt-times 3 Packet Receipt Times Report Block
stat-summary 6 Statistics Summary Report Block stat-summary 6 Statistics Summary Report Block
voip-metrics 7 VoIP Metrics Report Block voip-metrics 7 VoIP Metrics Report Block
The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters
MAY specify an integer value. This value indicates the largest size MAY specify an integer value. This value indicates the largest size
the whole report block SHOULD have in octets. This shall be seen as the whole report block SHOULD have in octets. This shall be seen as
an indication that thinning shall be applied if necessary to meet the an indication that thinning shall be applied if necessary to meet the
target size. target size.
The "stat-summary" parameter contains a list indicating which fields
SHOULD be included in the Statistics Summary report blocks that are
sent. The list is a comma separated list, containing one or more
field indicators. The space character (0x20) SHALL NOT be present
within the list. Field indicators represent the flags defined in
section 4.6. The field indicators and their respective flags are as
follows:
Indicator Flag
--------- ---------------------------
loss loss report flag (L)
dup duplicate report flag (D)
jitt jitter flag (J)
TTL TTL or Hop Limit flag (ToH)
HL TTL or Hop Limit flag (ToH)
For "loss", "dup", and "jitt", the presence of the indicator
indicates that the corresponding flag should be set to 1 in the
Statistics Summary report blocks that are sent. The presence of
"TTL" indicates that the corresponding flag should be set to 1. The
presence of "HL" indicates that the corresponding flag should be set
to 2. The indicators "TTL" and "HL" MUST NOT be signaled together.
Blocks in the collaborative category are classified as initiator Blocks in the collaborative category are classified as initiator
blocks or response blocks. Signaling SHOULD indicate which blocks or response blocks. Signaling SHOULD indicate which
participants are required to respond to the initiator block. A party participants are required to respond to the initiator block. A party
that wishes to receive response blocks from those participants can that wishes to receive response blocks from those participants can
trigger this by sending an initiator block. trigger this by sending an initiator block.
The collaborative category currently consists only of one The collaborative category currently consists only of one
functionality, namely the RTT measurement mechanism for RTP data functionality, namely the RTT measurement mechanism for RTP data
receivers. The collective functionality of the Receiver Reference receivers. The collective functionality of the Receiver Reference
Time Report Block and DLRR Report Block is represented by the "rcvr- Time Report Block and DLRR Report Block is represented by the "rcvr-
skipping to change at page 42, line 41 skipping to change at page 43, line 18
might commonly be found in an ill-formed packet. might commonly be found in an ill-formed packet.
Any registration MUST contain the following information: Any registration MUST contain the following information:
- Contact information of the one doing the registration, including at - Contact information of the one doing the registration, including at
least name, address, and email. least name, address, and email.
- The format of the block type being registered, consistent with the - The format of the block type being registered, consistent with the
extended report block format described in Section 3. extended report block format described in Section 3.
- A description of what the block type represents and how it shall be
interpreted, detailing this information for each of its fields.
6.3 The "rtcp-xr" SDP Attribute 6.3 The "rtcp-xr" SDP Attribute
This SDP attribute "rtcp-xr" defined by this document is registered This SDP attribute "rtcp-xr" defined by this document is registered
with the IANA registry of SDP Parameters as follows: with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rtcp-xr Attribute name: rtcp-xr
Long form: RTP Control Protocol Extended Report Parameters Long form: RTP Control Protocol Extended Report Parameters
Type of name: att-field Type of name: att-field
skipping to change at page 46, line 25 skipping to change at page 46, line 51
} }
// Return our best guess for a 32-bit sequence number that // Return our best guess for a 32-bit sequence number that
// corresponds to the 16-bit number we were given. // corresponds to the 16-bit number we were given.
return extended_seq; return extended_seq;
} }
A.2 Example Burst Packet Loss Calculation. A.2 Example Burst Packet Loss Calculation.
This is an algorithm for measuring the burst characteristics for the This is an algorithm for measuring the burst characteristics for the
VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI VoIP Metrics Report Block (Section 4.7). The algorithm, which has
TS 101 329-5 [3]. The algorithm is event driven and hence extremely been verified against a working implementation for correctness, is
computationally efficient. reproduced from ETSI TS 101 329-5 [3]. The algorithm as described
here takes precedence over any change that might eventually be made
to the algorithm in future ETSI documents.
This algorithm is event driven and hence extremely computationally
efficient.
Given the following definition of states: Given the following definition of states:
state 1 = received a packet during a gap state 1 = received a packet during a gap
state 2 = received a packet during a burst state 2 = received a packet during a burst
state 3 = lost a packet during a burst state 3 = lost a packet during a burst
state 4 = lost an isolated packet during a gap state 4 = lost an isolated packet during a gap
The "c" variables below correspond to state transition counts, i.e. The "c" variables below correspond to state transition counts, i.e.
c14 is the transition from state 1 to state 4. It is possible to c14 is the transition from state 1 to state 4. It is possible to
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/