RTCP XR (Extended Reports) or at least timing info included?

Peter Paluch · ‎11-19-2005

Hello everyone,

I planned to use the information conveyed by RTCP Sender Reports (SR) between two Cisco 2801 routers/voice gateways (IOS 12.3(11)YK1) for QoS evaluation purposes. Among other data, the RTCP SR messages contain two fields called LSR and DLSR which can be used to estimate the round-trip time between the two communicating parties.

To my surprise after analyzing the RTCP SRs I have found out that neither of the two communicating voice gateways was actually using the LSR and DLSR fields. Both fields carried the value of 0 in all RTCP SR messages which is clearly incorrect. I am not sure if this behavior is correct according to the RFC 3550 where the RTCP SRs are defined.

Moreover, the RFC 3611 specifies the so-called Extended Reports (XR) that include more specific data used for QoS evaluation. It seems that the Cisco boxes do not implement these XRs at all.

I could not find anything usable about the RTCP XRs or at least about "turning on" the RTCP SR LSR and DLSR fields. Did someone have a similar problem? Are the XRs and/or LSR and DLSR really unsupported? Why are the LSR and DLSR values not used by default?

Thank you for any hint or suggestion!

With best regards,

Peter

pradeepde · ‎11-28-2005

last SR timestamp (LSR): 32 bits

The middle 32 bits out of 64 in the NTP timestamp (as explained

in Section 4) received as part of the most recent RTCP sender

report (SR) packet from source SSRC_n. If no SR has been

received yet, the field is set to zero.

delay since last SR (DLSR): 32 bits

The delay, expressed in units of 1/65536 seconds, between

receiving the last SR packet from source SSRC_n and sending this

reception report block. If no SR packet has been received yet

from SSRC_n, the DLSR field is set to zero.

Let SSRC_r denote the receiver issuing this receiver report. Source

SSRC_n can compute the round propagation delay to SSRC_r by recording

the time A when this reception report block is received. It

calculates the total round-trip time A-LSR using the last SR

timestamp (LSR) field, and then subtracting this field to leave the

round-trip propagation delay as (A- LSR - DLSR).

Peter Paluch · ‎11-29-2005

Hello,

thanks for your reply. I see you have posted an excerpt from RFC 3550 where the LSR, DLSR and their semantics are defined. That's ok, but I know the definitions of the LSR and DLSR fields - I am familiar with the RTCP protocol.

My problem is that the Cisco boxes do not put valid values into these fields. In all RTCP packets from both parties the LSR and the DLSR fields are set to 0, and this is not a correct behavior. Not only the first SR packets carry a value of 0 in LSR and DLSR, but rather all SR packets do. This violates exactly the part of RFC 3550 you have posted a part of.

Moreover, the LSR and DLSR are used by traffic analyzers to estimate a round trip time (e.g., Agilent) and further the MOS score and/or the R factor. As the SR sent by Cisco voice gateways do not contain valid values in LSR and DLSR fields the traffic analyzers may become confused or produce invalid results.

My question therefore is if it is possible to force the Cisco voice gateways to correctly fill the LSR and DLSR fields and so to be RFC 3550 compliant.

Regards,

Peter