[asterisk-dev] CQDR

[John Todd]

At 1:44 PM -0500 2006/12/28, Jonathan k. Creasy wrote:
>
>In bug number 8188 and I also remember someone at Astricon talking 
>about this, someone mentioned logging call quality data to a mysql 
>table.
>
>I'd like to do this, it would play in very nicely with some other 
>projects I am working on.
>
>So, has anyone else already started? Does anyone have opinions on 
>how it should be done?
>
>-Jonathan
>
>Jonathan Creasy
>Network Engineer
>BluegrassNet Development
><http://www.bgnd.com>www.bgnd.com <http://www.bluegrass.net>www.bluegrass.net
>o. 502-589-4638
>c. 502-889-5567
>h. 812-206-1830


Jonathan -
   I think you are referring to Peter Macaulay's talk.  See included 
message below as to why it's useful for him, but possibly a bit on 
the "hackish" side.  I think that bug 8188 is a useful partial bit of 
code as a start, but I feel that a more generic call quality storage 
method should be devised so it can store CQDRs in a centralized and 
channel-agnostic way (at least, for those channels for which it is 
possible to easily obtain quantitative quality data, such as packet 
information on VoIP channels.)

   There exists in Asterisk a reasonably robust call history logging 
feature (CDRs, database CDRs, etc.) and I'd suggest that a CQDR 
method should look as much like the CDR method as possible, to use 
the code twice as well as to provide the flexibility of disk-based or 
database-based storage methods.  (Steve Davies mentions this a few 
days ago on the -dev list, as well.)  We already are collecting most 
of this data; just extracting it and logging it seems to be the 
remaining task.  I _know_ that several large Asterisk installations 
have already done this work for their specific requirements (usually 
SIP RTP or RTCP logging) but that code can't or won't be submitted 
back to TRUNK for various reasons.  It seems to be a fairly needy 
programming project; I'd put a few hundred bucks towards seeing it 
get done, so I don't have to keep explaining to every new 
[project,product] manager, CEO, investor, and person on the street 
why I can't tell why call X at time Y sounded bad because Asterisk 
doesn't log any call quality data without custom programming.

   In short: if we can have a discussion by those who are more 
informed about how CDRs work as to how  CQDRs can be implemented, I 
think it's worth the effort if we can get agreement and someone (you, 
Jonathan?) wants to put the effort in for the base code.  I'll put my 
money where my mouth is to aid in the effort.

JT



>Date: Fri, 3 Nov 2006 10:29:12 -0800
>To: asterisk-dev at lists.digium.com
>From: John Todd <jtodd at loligo.com>
>Subject: CQDRs - Call Quality records (was: Bug marshals - won't you 
>take a look...)
>
>At 2:36 PM -0500 2006/11/2, Jared Smith wrote:
>>On Thu, 2 Nov 2006, Stephen Davies wrote:
>>>  I posted up a change that gets chan_iax2 to log jitter buffer stats
>>>  into the logs regularly during active calls.
>>
>>I've also responded to the bug (#8188), but I'll repost my comments 
>>below as they're likely to get a greater audience of developers:
>>
>>Interesting... John Todd and I were discussing something similar at 
>>AstriCon, but in a more generic sense. What we'd like to see 
>>written is CQDR -- Call Quality Detail Records. Think of them as 
>>sitting side-by-side the CDR records, but showing information about 
>>the Call Quality.
>>
>>In the case of IAX, we get all kinds of useful information, which 
>>we don't currently capture (and your patch logs to the verbose 
>>log). In the case of SIP, we have RTCP reports (as well as call 
>>quality reports in the BYE messages of some endpoints).
>>
>>Wouldn't it be cool to see all this information logged to a CQDR table?
>>
>>-Jared
>
>
>There was even a talk (which I am ashamed to say I missed) at 
>Astricon by Peter Macaulay on call quality monitoring.  He's been 
>using wireshark/tethereal (agh!) to collect RTCP information and run 
>statistical analysis.  I talked with him briefly on the concept of 
>CQDRs, and everyone seems to be in violent agreement that this is 
>something that would greatly benefit service providers and large 
>enterprise instances of Asterisk.
>
>So, let me drag this monster out of the email archives again to see 
>if anyone has an interest in coding something like it:
>
>http://lists.digium.com/pipermail/asterisk-dev/2004-May/004180.html
>
>Wow, that was a long time ago!  Looks like everyone named "Jared" is 
>interested in this stuff.  Anyway, now that we have RTCP, much of 
>this data is immediately obvious and should be able to be inserted 
>into a CQDR-type record.  Even without RCTP, it is possible to put 
>much of this data into the record format - RTCP allows us to extend 
>the record and put in the perceptions from BOTH ends of the media 
>stream.
>
>Additional concepts that were discussed at Astricon:
>
>   - SNMP values for each RTP session that reflect jitter, RCTP, 
>non-RTCP statistics
>
>   - AMI commands to display jitter/RTCP/non-RTCP stats per media stream
>
>   - standard abstraction of CQDRs using the already-written CDR 
>abstraction layer (database, flatfile, etc)
>
>   - insertion of "Cisco-standard" statistics into the BYE messages 
>for SIP calls (RTP-RxStat/RTP-TxStat)
>
>   - collection of "Cisco-standard" statistics from BYE messages of 
>peers/clients and insertion into the CQDR
>
>JT