[Home]

Summary:ASTERISK-18455: RTCP stats works only when transcoding
Reporter:Fabian Borot (fborot)Labels:
Date Opened:2011-09-07 13:50:31Date Closed:2017-12-19 06:33:46.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_rtp_asterisk
Versions:1.8.5.0 Frequency of
Occurrence
Constant
Related
Issues:
is related toASTERISK-16404 [branch] Pinefrog - RTCP improvements
Environment:Asterisk 1.8.5.0 built by root @ asterisk1-8.lab.com on a x86_64 running Linux on 2011-09-02 18:56:22 UTC Linux asterisk1-8.lab.com 2.6.18-238.el5 #1 SMP Thu Jan 13 15:51:15 EST 2011 x86_64 x86_64 x86_64 GNU/Linux Attachments:( 0) rtcp-1-60_seconds_call.pcap
( 1) rtcp-1-60_seconds_call.txt
( 2) rtcp-4-2_calls_in_g729.pcap
( 3) rtcp-4-2_calls_in_g729.txt
( 4) rtcp-6-ulaw-stats.pcap
( 5) rtcp-6-ulaw-stats.txt
( 6) rtcp-7-xcoding-stats.pcap
( 7) rtcp-7-xcoding-stats.txt
( 8) rtcp-8-2_calls_without_xcoding-stats.txt
Description:We are trying to use the values returned by "RTPAUDIOQOS" and "RTPAUDIOQOSBRIDGED" to have an idea about the quality of the calls. We have noticed that when transcoding is involved the stats provided at the end of the call are very similar to what wireshark shows for the same call. However, when both legs use the same codec the variable either returns all zeroes or incorrect values [i.e: wireshark says packets sent 500 and the txcount shows 1 or 2).
I am attaching several files with console logs and tcpdump captures on the same machine to compare.
Comments:By: Fabian Borot (fborot) 2011-09-07 13:53:42.118-0500

console logs and tcpdump captures

By: Leif Madsen (lmadsen) 2011-09-13 14:11:09.654-0500

I don't think this is going to do anything, but you might try:

transcode_via_sln=yes

in the asterisk.conf file. It probably won't force transcoding via signed linear, but if it did, it might cause the stats to work?

By: Fabian Borot (fborot) 2011-09-13 14:14:01.651-0500

Txs Leif, I will try it

By: Fabian Borot (fborot) 2011-09-13 14:23:16.115-0500

same thing, I tried ulaw<->ulaw and g729<->g729 and the stats are 0 or very close to it. See console log named "rtcp-8-2 calls without xcoding-stats.txt", it has the 2 calls

By: Fabian Borot (fborot) 2011-09-13 14:24:06.869-0500

2 calls without transcoding: first call using ulaw and 2nd call using g729

By: Leif Madsen (lmadsen) 2011-09-13 15:52:58.780-0500

OK then I consider this another issue associated with RTCP in Asterisk. I'd suggest looking into ASTERISK-16404 and see if that helps, however I'm pretty sure that is going to be created against Asterisk 1.4, and very old now :(

By: Fabian Borot (fborot) 2011-09-20 12:09:31.903-0500

Dear Leif, we are willing to pay to fix this issue. Is this covered by any of the Digium's Subscription Support options? What other options are there?
Thank you in advance
FBorot

By: Matt Jordan (mjordan) 2012-08-27 10:54:50.856-0500

Digium's subscription support options do not cover fixing specific bugs.  It simply results in different internal prioritization.  If you'd like this specific bug fixed, you may want to consider contacting the owner of the pinefrog branch (Olle) to see if he'd be willing to port the fix to your particular branch, or you may want to contact the asterisk-biz list.

By: Joshua C. Colp (jcolp) 2017-12-19 06:33:46.752-0600

I believe the underlying problem here has been resolved in Asterisk as of a few years ago. If this is still occurring in a current supported version feel free to comment and the issue will automatically reopen.