[Home]

Summary:ASTERISK-30112: ari: Call recording stops prematurely
Reporter:e-telequote.com (ETQ)Labels:webrtc
Date Opened:2022-06-16 13:14:09Date Closed:2022-07-08 12:00:01
Priority:MinorRegression?
Status:Closed/CompleteComponents:Applications/app_record
Versions:18.10.0 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Ubuntu 20.04.03 LTS Kernel: Linux 5.4.0-100-generic Asterisk 18.10.0 installed from source using tar.gz file. Memory : 8 GB swap 2GB Cpu Count: 2 Cpu Model : Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHzAttachments:( 0) messages-9_2.log
Description:We are facing this issue where calls recording suddenly truncated without disconnecting the calls. CPU usage at that point in time sometimes well under 80%.
     We are using ARI application to generate outbound calls. Two legs were bridged together and then Recorder/ARI channel used to record the audio in the bridge. Also recording happens directly in file in /var/spool/asterisk/recording/filename. Means not in temp file in temo directory. After looking into log files finds this.
VERBOSE[354962] bridge.c: Bridge d8f9e148-122c-4a70-a26a-5c03385bf581: switching from simple_bridge technology to softmix
WARNING[354964][C-00000d91] app.c: No audio available on Recorder/ARI-000006ee;1??
WARNING[354962] channel.c: Exceptionally long voice queue length queuing to Recorder/ARI-000006ee;1
WARNING[354962] channel.c: Exceptionally long voice queue length queuing to Recorder/ARI-000006ee;1
WARNING[354962] channel.c: Exceptionally long voice queue length queuing to Recorder/ARI-000006ee;1
WARNING[354962] channel.c: Exceptionally long voice queue length queuing to Recorder/ARI-000006ee;1
VERBOSE[354962] bridge_channel.c: Channel Recorder/ARI-000006ee;2 left 'softmix' stasis-bridge <d8f9e148-122c-4a70-a26a-5c03385bf581>
VERBOSE[354962] bridge_channel.c: Channel Recorder/ARI-000006ee;2 left 'softmix' stasis-bridge <d8f9e148-122c-4a70-a26a-5c03385bf581>
VERBOSE[354962] bridge.c: Bridge d8f9e148-122c-4a70-a26a-5c03385bf581: switching from softmix technology to native_rtp
VERBOSE[354952] bridge_channel.c: Channel SIP/172.24.98.14-00001c2b left 'native_rtp' stasis-bridge <d8f9e148-122c-4a70-a26a-5c03385bf581>
VERBOSE[354952] bridge.c: Bridge d8f9e148-122c-4a70-a26a-5c03385bf581: switching from native_rtp technology to simple_bridge
VERBOSE[354951][C-00000d91] bridge_channel.c: Channel SIP/outbound-00001c21 left 'simple_bridge' stasis-bridge <d8f9e148-122c-4a70-a26a-5c03385bf581>

Sophos anti-virs and TM Deep security agent are running on the server. So trying to figure out what cause this issue. Also need guidelines and help to further advance our investigation in right direction to locate/resolve the issue.
Comments:By: Asterisk Team (asteriskteam) 2022-06-16 13:14:10.664-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Joshua C. Colp (jcolp) 2022-06-16 13:17:00.705-0500

We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: e-telequote.com (ETQ) 2022-06-16 17:04:58.138-0500

Thanks a lot Joshua C. Colp for responding with guidelines. Fortunately, We are able to capture the event. So attaching log file with debug messages and one of the instances happened at around 16:53:22.
Furthermore, IPs 172.24.98.* are of other PBX servers running asterisk in cluster. Agents using webrtc to logged in.
Also just replaced public IPs with "itsp-rtp-engine-ip" and "outbound-trunk-ip".
By: Joshua C. Colp (jcolp) 2022-06-20 04:20:09.776-0500

What is the full content of your ARI originate? Are you specifying codecs? If not, do so.

Is this a virtualized environment? Even before your issue, I'm seeing evidence of the system not being able to keep up or being able to provide accurate timing.
By: e-telequote.com (ETQ) 2022-06-21 10:56:07.511-0500

Can you please elaborate more on your comment about timing, are you suggesting that we are running out of CPU?
Yes, this is a virtual machine running on a hypervisor.
Let us provide ARI originate content shortly.
By: Joshua C. Colp (jcolp) 2022-06-21 11:06:18.770-0500

Even before your issue occurs, the timing is already delayed (a timer is asked to wake up every 20 milliseconds, it wakes up after 40, or 60, or 80, or more) which generally indicates the environment is not receiving adequate CPU time to keep up. There is a tolerance, to a degree, but it's better to ensure that the VM receives guaranteed CPU time and resources.
By: Asterisk Team (asteriskteam) 2022-07-08 12:00:01.187-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines