Hi,<div><br></div><div>i would be happy to test it - and maybe to integrate the new manager events with asterisk-java - to be able to create some fancy live quality monitor...</div><div><br></div><div>Testing does only make sense on system with some load - so the question is - how stable is it already ? Is it ready for testing on a production system ?</div>
<div><br></div><div>And - how long would it take for you to port it to 1.6.x ?</div><div><br></div><div>best regards,</div><div>Wolfgang<br><br><div class="gmail_quote">2010/1/21 Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net">oej@edvina.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Friends,<br>
I've just created a combined test branch for work on RTCP that I would appreciate<br>
your feedback on.<br>
<br>
Thanks!<br>
<br>
/Olle<br>
<br>
<a href="http://svn.asterisk.org/svn/asterisk/team/oej/pinefrog-deluxe-rtcp-test/" target="_blank">http://svn.asterisk.org/svn/asterisk/team/oej/pinefrog-deluxe-rtcp-test/</a><br>
<br>
Test branch for patches hidden in several branches - all based on Asterisk 1.4<br>
----------------------------------------------------------------------------------------------------------<br>
<br>
- RTCP improvements from pinefrog-1.4<br>
- "Sip show chanstats" cli command<br>
- pinequality-* giving you the manager "sipchannel" event to check QoS<br>
<br>
This branch is now open for testing and I need feedback. Among the improvements<br>
<br>
- Manager QoS events during a call and after a call<br>
- Improved RTCP - rtcp now works for p2p bridge in RTP, which means that we will get<br>
RTCP for many, many more sip calls<br>
- RTCP over NAT improvements - if Asterisk is behind NAT, we will now kick-start RTCP from the remote<br>
end by sending a first "emtpy" RTCP packet to open a NAT port.<br>
- QoS reports to realtime storage after each call - one report per call leg<br>
(The amount of data and the names will change)<br>
<br>
The reason that I store QoS data in realtime, is that the CDR is usually gone or frozen at the time<br>
that we freeze the RTP channels and get the last QoS data. The QoS reports can't thus<br>
be included in CDR, you have to merge it in automatically later in your database.<br>
<br>
There's still a lot to do, but please test it so I get some sort of feedback.<br>
<br>
For testing, don't forget to run the "rtcp debug" cli command so you can see what's<br>
going on in the RTCP channel.<br>
<br>
FAQ<br>
---<br>
Yes, this work will be ported to trunk and hopefully merged soon.<br>
No, I have no reason or funding to adapt it to 1.6.x at this point.<br>
No, the RTPAUDIOQOS is not changed at all. YOu might get more data now though.<br>
<br>
-------<br>
This work is funded to 20% by companies in the community. If you want to cover the<br>
80% that's still not funded, please contact me off-list (<a href="mailto:oej@edvina.net">oej@edvina.net</a>).<br>
<font color="#888888"><br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</font></blockquote></div><br></div>