Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2009-11-18 18:36:18.000-0600Date Closed:
Versions:Frequency of
is related toASTERISK-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.



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.