[Asterisk-Dev] Call Quality Measurement idea (was: cisco 7940/7960 call_stats
logging)
John Todd
jtodd at loligo.com
Tue May 11 22:27:45 MST 2004
I like that format, but I'd also like to see a little more data in the output if it's possible, since we have the data... Jitter is the biggest problem I have with my calls right now, and I'd like to get a better idea of what's going on with that statistic.
AvgJtr = Average Jitter
MaxJtr = Maximum Jitter
JtrSDV = Jitter Standard Deviation
These are the minimal data required to provide meaningful alarm outputs. One particular call might have one second of really nasty jitter in a 20 minute conversation, which is probably "acceptable", but we'd want to see that maximum jitter number to notify us that something went wrong there... somewhere. The average (and even the standard deviation) numbers wouldn't tell us that.
Also, the term "RTP" shouldn't be used in the stats routines, since if we include IAX channels then we're not going to be using RTP. Might as well be pedantic about it. :-)
Let me put on my "wishing hat" for a while. I wish we had...
Perhaps something like this in /var/log/asterisk/cqdr :
Callstart,Callend,OriginIP,DestinationIP,PerspectiveIP,UniqueID,RxPackets,RxOctets,RxLatePackets,RxLost,RxAverageJitter,RxMaximumJitter,RxStandardDeviationJitter,TxPackets,TxOctets
Where:
Callstart = Timestamp of call audio setup (starting from RTP startup, not call startup) Timestamps are generated by local clock, not by remote devices/endpoints.
Callend = Timestamp of call audio termination (ending at RTP end, not call end) Timestamps are generated by local clock, and not by remote devices/endpoints.
OriginIP = The IP of the origin for this leg (who initiated the call.) In the instance this is the local Asterisk server, it should use the address of the interface (or whatever was the originating packets) used to communicate audio data for the session.
DestinationIP = The destination IP address of the call. Again, if it's the local Asterisk server, the locally defined IP address (interface, virtual interface, whatever) should be used.
PerspectiveIP = Who is reporting this event? PerspectiveIP should match _either_ the OriginIP or the DestinationIP. Since we can take reports in from remote devices, this needs to be included so that we can have multiple reports of the same call to compare who sees what from various perspectives. In the event of NAT on the device (SIP or IAX2) then use the IP address which is seen by the Asterisk server as the "outside" address.
UniqueID = The unique call ID given to this call. If this is reported by Asterisk, then it is set to uniqueid (channel unique identifier.) Messages transmitted back to Asterisk in SIP BYE or other hangup methods should be tagged with the unique Asterisk identifier to facilitate matching of CDRs to CQDRs. Zap channels should use the group/channel number.
Protocol = the protocol of this leg (IAX2, IAX, SIP, H323, MGCP, SCCP, ZAP, etc.)
Codec = the codec being used on this leg (Recall that Zap is either ULAW or ALAW, so we could put Zap channels into this mix even though they would always be 100% "good" in their statistics)
RxPackets = The number of packets received during the session (or UNKNOWN)
RxOctets = The number of bytes received during the session (or UNKNOWN)
RxLatePackets = The number of late (mis-ordered) packets received during the session (or UNKNOWN)
RxLost = The number of packets lost during the session (or UNKNOWN)
RxAverageJitter = The average jitter (difference between sequential Rx packets) during the session (or UNKNOWN)
RxMaximumJitter = The maximum delay between sequential Rx packets during the session (or UNKNOWN)
RxStandardDeviationJitter = The standard deviation of jitter values during the session (or UNKNOWN)
TxPackets = The number of packets transmitted during the session (or UNKNOWN)
TxOctets = The number of bytes transmitted during the session (or UNKNOWN)
Here's an example of three lines that would appear in the CQDR file if my mythical call quality system was put in place. While this example uses RFC1918 addresses, assume that there are no NAT translations occurring here (not that it makes that much of a difference...):
Asterisk = 10.10.22.9
IAX2 client = 172.16.33.1
Cisco 7960 SIP client = 192.168.34.9
The Asterisk-to-Firefly (IAX2) call, as reported by Asterisk:
"2004-05-12 03:07:39","2004-05-12 03:08:33","10.10.22.9","172.16.33.1","10.10.22.9","12345678901234567890123456789012","IAX2","ILBC",2922,994322,3,4,12,55,14,3002,942117
The Asterisk-to-7960 leg, as reported by Asterisk:
"2004-05-12 03:07:39","2004-05-12 03:08:33","10.10.22.9","192.168.34.9","10.10.22.9","12345678901234567890123456789012","SIP","ALAW",9833,1400233,0,3,5,15,6,9660,13894412
The 7960-to-Asterisk leg, as reported by the 7960:
"2004-05-12 03:07:40","2004-05-12 03:08:33","192.168.34.9","10.10.22.9","192.168.34.9","12345678901234567890123456789012","SIP","ALAW",9654,13893011,1,6,6,"UNKNOWN","UNKNOWN",9830,1399933
There is no Firefly-to-Asterisk leg, since Firefly doesn't have the ability to report back that data. Perhaps for that leg we would put in a "dummy" record that had all "UNKNOWN" values stuff into it for that perspective's quality reporting? I haven't really thought about that one much...
Looking at these made-up numbers, we can see that there is pretty good packet throughput and jitter across these two legs. The numbers are close enough that we probably wouldn't worry about quality here. Some quick perl would be able to link CDR's with CQDR's based on uniqueID, or even (possibly) on the call time, though time is an inadequate method for matching call legs together. I haven't really figured out how re-invites would show up in this system; I suppose if they generate a new uniqueID, they'd create a new set of records. Similiarly, IAX2 calls that native bridge after initial negotiation would just show a very short CQDR record, but hey, something is better than nothing. Perhaps eventually we'll see IAX2 report back things like this to the origin server(s) after hangup, but I don't think that the architecture needs to change just for this reason...
In any case, someone out there should put this on the "John's Very Large Pile of Asterisk Ideas Which Will Never Be Implemented". I'm sure Google will have a good time showing it to people for years and years when they search on "asterisk call quality" or "IAX2 quality measurement" or other trivial things like that. :-)
JT
At 10:23 PM -0400 on 5/11/04, Jared Mauch wrote:
>On Tue, May 11, 2004 at 11:44:25AM -0700, John Todd wrote:
>> This is (from my non-C-experienced viewpoint) a fairly major
>> development task. However, it does seem obvious that Asterisk needs
>> to have some call quality measurement in order to be compared against
>> the "big boys" of the VoIP world, if only so that an Asterisk admin
>> can point to a graph and say "See? Call quality is great with my
>> free software, and I can identify problem customers almost
>> immediately - how is your million-dollar system doing?" And it's
>> something that would be useful and universally applicable across all
>> channel types that involved VoIP of some type. Any takers? :-)
>
> Perhaps we can get the data in asterisk
>stored up and output int the same format
>as the cisco w/ RTP-RxStat/RTP-TxStat
>
> - Jared
>
>> At 11:46 AM -0400 5/11/04, Jared Mauch wrote:
>> >
>> > Ideally one would log it as well as the endpoint IPs in order
>> >to determine if there is a network problem with one of the peoples links.
>> >
>> > I have a lot of users behind various NAT devices on
>> >dsl/cable and want to use this to pinpoint the source of their
>> >problems.
>> >
>> > - Jared
>> >
>> >On Tue, May 11, 2004 at 09:35:23AM -0600, brian k. west wrote:
>> >> Now if you can make this a config option per peer and copy it into the
>> >> cdr->userfield.
>> >>
>> >> bkw
>> >>
>> >> ----- Original Message -----
>> >> From: "Jared Mauch" <jared at puck.nether.net>
>> >> To: <asterisk-dev at lists.digium.com>
>> >> Cc: "Jared Mauch" <jared at puck.nether.net>
>> >> Sent: Tuesday, May 11, 2004 8:02 AM
>> >> Subject: Re: [Asterisk-Dev] cisco 7940/7960 call_stats logging
>> >>
>> >>
>> >> > I've hacked together this which does
>> >> > the job..
>> >> >
>> > > >
>> >[patch snipped[
>> > > >
>> >> >
>> >> > - Jared
> > >> >
>> >> > On Fri, Apr 30, 2004 at 12:23:38AM -0400, Jared Mauch wrote:
>> >> > >
>> >> > > so, in the recent SIP firmware on the Cisco phones,
>> >> > > it sends some data in the BYE message that can be used to collect
>> >> > > information about the connection.
>> >> > >
>> >> > > I want to collect and parse this data to help show my users
>> >> > > that have bad connections exactly what we see as compared to
>> >> > > a non-problematic connection/ISP.
>> >> > >
>> >> > > Has anyone been looking at this yet?
>> >> > >
>> >> > >
>> >>
> > >>http://www.cisco.com/en/US/products/sw/voicesw/ps2156/prod_release_note09186a00801d1d80.html#80912
>> >> > >
>> >> > > I'm also really interested in the jitter and late/lost pkts
>> >> > > too..
>> >> > >
> > > > > > - jared
More information about the asterisk-dev
mailing list