[Asterisk-Dev] RTCP-'support'

[Filip Olsson]

The solution to put these thin CQDR's in the userfield isn't at all the
final solution, it was just a dirty hack to get them out.
Although the userfield isn't the solution to this, I don't now if a
separate record is the best one. Why not just put the stuff in the CDR
but in separate fields?

Concerning H.323/MGCP/SCCP it shouldn't be too much of a problem to get
them to use this, although I don't really know because I'm not that
familiar with them. But as long as they use the RTP from rtp.c the
modifications should be minor.

//filip

On Mon, 2004-11-15 at 23:14, John Todd wrote:
> Wow, this is really great!   I'm warming up the RRDTool engine 
> already to start plotting this data after I get the patch installed.
> 
> Sorry to follow up so quickly with the RTCP XR stuff - I hadn't even 
> read the list to see your message when I sent that.  :-)  The bad 
> news is that RTCP-XR isn't in most equipment... yet.  The data you're 
> collecting is excellent, though.
> 
> My preference would be to avoid populating this data into the CDR 
> field (even in the "user" field) since this repository is getting 
> pretty crowded.  In fact, this would be ultimately also perfect for 
> exportation into a database structure - the hooks for that exist 
> already, right?  You've done 90% of the work for getting a "CQDR" 
> data store running - any chance of getting out of the CDR log and 
> then weaving h.323 and IAX2 into the mix?  Also, I'm not sure how 
> you'd handle IAX2 - do the same RTP hooks apply?
> 
> Can the developers of H.323/MGCP/SCCP speak to how this might be 
> worked into those channels if/when this is more stable?
> 
> JT
> 
> 
> At 8:01 PM +0100 on 11/15/04, Filip Olsson wrote:
> >Hello boys and girls,
> >
> >I've posted a patch to
> >http://bugs.digium.com/bug_view_page.php?bug_id=0002863 that add's some
> >RTCP-support to rtp.c. It adds the ability to send/receive (and almost
> >understand) RTCP sender/receiver reports.
> >
> >It's kind of hard to test if the receiver actually understands what we
> >send them. The way I made sure it was correctly understood by the remote
> >end was to make sure that such things as LSR and DLSR in RTCP RRs was
> >filled in correctly to reflect our SR. The RTP-stack in 42Networks'
> >DRG-series understand them and responds correctly, according to
> >ethereal.
> >
> >The whole point of this patch was to dig out some statistics on the
> >quality(delay/jitter/loss) of the RTP-streams and then dump it to
> >somewhere useful. I've written a small patch to chan_sip so that some
> >averages/maxs/mins are saved in the userfield of the CDR. John Todd has
> >put forth a much better solution that is more generic(not just RTP)
> >http://lists.digium.com/pipermail/asterisk-dev/2004-May/004180.html.
> >But atleast it's a start to have the stuff in the CDR.
> >It would be even more useful to(on a per call basis) be able to log a
> >RTP-stream to a separate file that describes the whole stream/call in
> >more detail so one can monitor the stats as the call goes on(for people
> >that like fancy graphing).
> >
> >RTCP and RTP is described in RFC3550, it's the best documentation I've
> >found.
> >
> >Anyways, please test the patch and give me some feedback. I'm in
> >#asterisk/-dev/-bugs under my very secret nick folsson.
> >
> >Don't even think about patching your production systems with this one,
> >it'll most certainly blow up your machine and get you fired.
> >
> >//Filip Olsson
> >
> >_______________________________________________
> >Asterisk-Dev mailing list
> >Asterisk-Dev at lists.digium.com
> >http://lists.digium.com/mailman/listinfo/asterisk-dev
> >To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
__________________________________________
Filip Olsson        Phone:  +46 40 6220000
Telavox AB          Direct: +46 40 6220012
www.telavox.se      Mobile: +46 73 5000018