Summary:	ASTERISK-15171: RTPAUDIOQOS and RTPAUDIOQOSBRIDGED false statistics
Reporter:	Maciej Krajewski (jamicque)	Labels:
Date Opened:	2009-11-18 18:36:18.000-0600	Date Closed:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-16404 [branch] Pinefrog - RTCP improvements
Environment:		Attachments:	( 0) full
Description:	Ticket is concerning variables RTPAUDIOQOS and RTPAUDIOQOSBRIDGED which are based on information in RTCP reports. Every time in variable the number of lost packets is >> than number of received or transmitted packets. My conclusion is that the reported number of lost packets in variable is false and also the number or transmitted and received packets is also false (always < 1000 no matter how long was the call the value should be much higher...). It's not a network related problem. I've tested it on different machines and different networks (also local calls - the result is always the same). The problem concerns asterisk 1.4 and 1.6
Comments:	By: Leif Madsen (lmadsen) 2009-11-19 09:41:45.000-0600 Additional information is required here in order to move this issue forward: 1) console output with debugging while this is happening 2) ability to reproduce the issue 3) I guess some information on how you came to this conclusion so that it can be repeated in the lab By: Maciej Krajewski (jamicque) 2009-11-19 10:21:41.000-0600 ad.1) I'll attach the logs later today ad.2) the results are the same on every asterisk (I mean the info about lost, send and received packets) - tested on numerous asterisks in different versions (about 12 different machines). ad.3) You can even make a call between 2 phones connected to asterisk and look at the logs. Send and received packet should be in hundreds of thousands during the longer call (if there is no VAD enabled) and they are always <1000 By: Maciej Krajewski (jamicque) 2009-11-19 13:57:10.000-0600 I've uploaded the attachment. Which shows log of a connection between ZOIPER softphone and VoIP operator. In this log you can see that the variable RTPAUDIOQOSBRIDGED has the rlp (remote lost packets) a very high value. And the number of send and received packets is <1000 By: Maciej Krajewski (jamicque) 2009-11-19 14:12:37.000-0600 Sorry it's my mistake after deeper analysing. The problem occurs only when i'm terminating my call's thru one of the operators. During the local call's it's ok. It's probably the fault of implementing RTCP in remote side. By: Maciej Krajewski (jamicque) 2009-11-19 14:13:47.000-0600 However the number of recieved and sent packets seems false anyway By: Olle Johansson (oej) 2010-01-13 05:42:46.000-0600 Turn on RTCP debug and read the output. There you will see incoming and outgoing packets, as well as a summary that is easier to parse when looking for issues. By: Leif Madsen (lmadsen) 2010-04-14 09:49:07 Not sure if this will help or not, but try testing the RTCP improvements in the PineFrog branch by oej. http://svn.asterisk.org/svn/asterisk/team/oej/pinefrog-deluxe-rtcp-test/ http://www.voip-forum.com/opensource/2010-01/test-rtcp-test-branch-based-asterisk-14/ By: philipp2 (philipp2) 2010-06-25 18:50:28 In Asterisk 1.4 RTPAUDIOQOS is wrong for sure, see ASTERISK-10189 (look at patch "rtpqos-14-r119891.diff" to improve 1.4; and there are also ASTERISK-14801 as well as ASTERISK-14530). If I remember correctly then RTPAUDIOQOS only reports information from the last RTCP info it received and does therefore not cover the entire call - its output should be identical to CHANNEL(rtpqos,audio,all), by the way. I could be wrong, but I think RTPAUDIOQOSBRIDGED does not exist in pure Asterisk 1.4 (but is added by patch ASTERISK-10189 and is included in Asterisk 1.6.x). See also: http://www.voip-info.org/wiki/view/Asterisk+RTCP So yes, I would say RTPAUDIOQOS needs to be fixed in Asterisk 1.4. By: Olle Johansson (oej) 2011-02-14 07:12:26.000-0600 In my work with Pinefrog I have realized that settings these variables will NEVER work. That's why I moved to storing CQRs - Call Quality Records - in realtime storage after the call. And I've fixed a lot of stuff in the RTCP stats as well, especially if the call has NAT involved.