[Opalvoip-user] Issues with RTCP XR (RFC 3611 Extended Report)?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I've been experimenting with the RFC 3611 RTCP XR (Extended Report)
    in the opal library, module metrics.h/cxx<br>
    <br>
    It doesn't seem to produce correct results for me, so just checking
    if anyone else has had any experiences positive or negative with
    this bit of code.&nbsp; I'm concerned about a couple of things:<br>
    <br>
    1)&nbsp; The equipment/codec degradation method does not appear to
    actually do a proper calculation on sumIe.&nbsp; The calculation below
    does not aggregate across all the periods -- it only uses the last
    period in the iePeriods list, while sumDuration does aggregate all
    the durations of the periods.&nbsp; Thus, the Ie degradation factor will
    tend to 0, which is what I see in the RTCP reports, despite the fact
    I'm applying a constant 10% packet loss -- the rFactor starts off
    low, as it should, then it climbs up to 94, which means perfect
    audio, which it is NOT with 10% packet loss.<br>
    <br>
    <font face="Courier New, Courier, monospace">float
      RTCP_XR_Metrics::GetPonderateIe()<br>
      {<br>
      &nbsp; float&nbsp;&nbsp; ponderateIe = 0;<br>
      &nbsp; float&nbsp;&nbsp; sumIe = 0;<br>
      &nbsp; PUInt64 sumDuration = 0;<br>
      &nbsp; DWORD&nbsp;&nbsp; count = 0;<br>
      <br>
      &nbsp; /* Account for the current time and Ie value */<br>
      &nbsp; PTime now;<br>
      &nbsp; ponderateIe = Ieff(m_currentPeriodType) * (now -
      m_periodBeginTimestamp).GetMilliSeconds();<br>
      &nbsp; sumDuration = sumDuration + (now -
      m_periodBeginTimestamp).GetMilliSeconds();<br>
      &nbsp; count++;<br>
      <br>
      &nbsp; /* Iterate over the list of periods to calculate an average Ie
      */<br>
      &nbsp; for (list&lt;IePeriod&gt;::iterator period =
      m_iePeriods.begin(); period != m_iePeriods.end(); period++) {<br>
      &nbsp;&nbsp;&nbsp; sumIe = (*period).Ieff * (*period).duration.GetMilliSeconds();<br>
      &nbsp;&nbsp;&nbsp; sumDuration = sumDuration +
      (*period).duration.GetMilliSeconds();<br>
      &nbsp;&nbsp;&nbsp; count++;<br>
      &nbsp; }<br>
      <br>
      &nbsp; if (count != 0 &amp;&amp; sumDuration != 0) {<br>
      &nbsp;&nbsp;&nbsp; ponderateIe = sumIe/sumDuration;<br>
      &nbsp; }<br>
      &nbsp; return ponderateIe;<br>
      }</font><br>
    <br>
    2)&nbsp; Unbounded collection of periods over time.&nbsp; Method
    RTCP_XR_Metrics::createIePeriod() always performs an
    m_iePeriods.push_back() operation on each new Ie period.&nbsp; Thus, the
    std::list of Ie periods grows without bound, resulting in an ever
    increasing amount of CPU spent on each RTCP message processing these
    growing lists of periods...memory also grows.&nbsp; Seems like this
    should be doing pop_front() operations after reaching a certain
    number of intervals, so that the rFactor calculation stays relevant
    to recent history of the session, not trying to calculate an rFactor
    over the&nbsp; entire life of the session, which would not be useful.<br>
    <br>
    Am I just missing something?&nbsp; I know that Ekiga uses the Opal
    libraries, but I've observed that Ekiga does not do XR blocks in its
    RTCP packets.<br>
    <br>
    Thanks!<br>
  </body>
</html>