Summary:	ASTERISK-27835: Asterisk Memory consumption after load
Reporter:	Biz Biz (biz8031)	Labels:
Date Opened:	2018-05-03 04:02:43	Date Closed:	2018-10-02 09:59:18
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Core/General
Versions:	13.17.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Virtual Machine 8 CPU, 16 Gb RAM on VM Ware ESXi6 OS: RedHat 7.1 Asterisk : 13.17.0	Attachments:	( 0) AsteriskMemoryConsumption.png ( 1) asteriskmemorysummary.zip
Description:	70 SIP user registered 120 Active SIP calls (only SIP), the calls remain active all the time 300 Active internal calls between conferences 110 Active Conferences (meetme) Sending message on AMI Interface (hundreds/minute) (mainly mute/unmute of channels between conferences, Originate to make calls) Asking channel status by command : asterisk -rx 'sip show channels' and 'meetme list <conference>' (several times minute) Asterisk modules: {noformat} [modules] autoload=yes noload => chan_alsa.so noload => chan_oss.so noload => chan_console.so noload => res_stun_monitor.so noload => res_ari_applications.so noload => res_ari_bridges.so noload => res_ari_device_states.so noload => res_ari_events.so noload => res_ari_playbacks.so noload => res_ari.so noload => res_ari_asterisk.so noload => res_ari_channels.so noload => res_ari_endpoints.so noload => res_ari_model.so noload => res_ari_recordings.so noload => res_ari_sounds.so noload => app_stasis.so noload => res_stasis_answer.so noload => res_stasis_device_state.so noload => res_stasis_playback.so noload => res_stasis_recording.so noload => res_stasis_snoop.so noload => res_stasis.so noload => func_sorcery.so noload => res_sorcery_astdb.so noload => res_sorcery_config.so noload => res_sorcery_memory_cache.so noload => res_sorcery_memory.so noload => res_sorcery_realtime.so noload => res_hep_rtcp.so noload => res_hep.so noload => app_mysql.so noload => cdr_mysql.so noload => cdr_csv.so noload => cdr_custom.so noload => cdr_mysql.so noload => cdr_odbc.so noload => cdr_sqlite3_custom.so noload => cdr_syslog.so noload => app_test.so noload => res_config_mysql.so noload => chan_iax2.so noload => app_voicemail.so noload => chan_dahdi.so noload => res_config_ldap.so noload => res_http_websocket.so {noformat} After 6/7 days of work the memory used  start growing till to saturate  all memory system (RAM and swap) in half hour/one hour ;the growth it isn't linear in the time (i've monitored the process with pmap),it start increasing very fast after few days. asterisk pmap out extract: {noformat} gio 26 apr 2018, 16.50.47, CEST total kB 5007200 106968 94372 gio 26 apr 2018, 17.00.47, CEST total kB 5007200 107072 94476 gio 26 apr 2018, 17.10.48, CEST total kB 5007200 107148 94552 gio 26 apr 2018, 17.20.48, CEST total kB 5007200 107112 94516 gio 26 apr 2018, 17.30.48, CEST total kB 5011664 107812 95116 gio 26 apr 2018, 17.40.48, CEST total kB 5011664 107928 95232 gio 26 apr 2018, 17.50.49, CEST total kB 5011664 108272 95576 gio 26 apr 2018, 18.00.49, CEST total kB 5011664 108556 95860 gio 26 apr 2018, 18.10.50, CEST total kB 5011664 108956 96260 dom 29 apr 2018, 07.52.54, CEST total kB 5011664 111332 98612 dom 29 apr 2018, 08.02.55, CEST total kB 5011664 111320 98600 dom 29 apr 2018, 08.12.55, CEST total kB 5011664 111320 98600 dom 29 apr 2018, 08.22.55, CEST total kB 5011664 111320 98600 dom 29 apr 2018, 08.32.56, CEST total kB 5011664 111320 98600 mer 2 mag 2018, 20.15.35, CEST total kB 5171376 141488 128768 mer 2 mag 2018, 20.25.35, CEST total kB 5171376 141488 128768 mer 2 mag 2018, 20.35.36, CEST total kB 5171376 141484 128764 mer 2 mag 2018, 20.45.36, CEST total kB 5171376 141592 128872 mer 2 mag 2018, 20.55.37, CEST total kB 5171376 141484 128764 mer 2 mag 2018, 21.05.37, CEST total kB 5171376 141484 128764 mer 2 mag 2018, 21.15.38, CEST total kB 5171376 144160 131440 mer 2 mag 2018, 21.25.38, CEST total kB 7595844 3186200 3173180 mer 2 mag 2018, 21.35.46, CEST total kB 9825056 5620656 5607628 mer 2 mag 2018, 21.45.59, CEST total kB 11109020 7040680 7027652 mer 2 mag 2018, 21.56.17, CEST total kB 11649240 7890956 7877928 mer 2 mag 2018, 22.06.36, CEST total kB 12237640 8642528 8629500 mer 2 mag 2018, 22.16.56, CEST total kB 13152596 9343332 9330304 mer 2 mag 2018, 22.27.17, CEST total kB 13677312 10007388 9994360 mer 2 mag 2018, 22.37.39, CEST total kB 14136988 10616112 10603084 mer 2 mag 2018, 22.48.03, CEST total kB 14924344 11220692 11207664 {noformat} From here asterisk is unresponsive. I did a lot of tests (using asterisk 13.20 too) but the behaviour is always the same. The epilogue  differs: Some times the operating system kills Asterisk  for the excessive memory consumption: {noformat} apr 11 22:18:36 hermes kernel: Out of memory: Kill process 3586 (asterisk) score 885 or sacrifice child apr 11 22:18:36 hermes kernel: Killed process 3586 (asterisk) total-vm:24097556kB, anon-rss:15277360kB, file-rss:0kB, shmem-rss:0kB {noformat} after receiving some errors on log (messages) {noformat} [Apr 11 22:18:04] NOTICE[10758] chan_sip.c:    -- Registration for 'hsgw-trunk0@svr-trunk0' timed out, trying again (Attempt #3) [Apr 11 22:18:11] ERROR[11426][C-00000021] astobj2.c: Excessive refcount 100000 reached on ao2 object 0x7f7b94001cb8 [Apr 11 22:18:11] ERROR[11426][C-00000021] astobj2.c: FRACK!, Failed assertion Excessive refcount 100000 reached on ao2 object 0x7f7b94001cb8 (0) [Apr 11 22:18:12] ERROR[11426][C-00000021] astobj2.c: Excessive refcount 100000 reached on ao2 object 0x7f7b94001cb8 [Apr 11 22:18:12] ERROR[11426][C-00000021] astobj2.c: FRACK!, Failed assertion Excessive refcount 100000 reached on ao2 object 0x7f7b94001cb8 (0) [Apr 11 22:18:14] ERROR[11497][C-0000003b] astobj2.c: Excessive refcount 100000 reached on ao2 object 0x7f7c24004848 [Apr 11 22:18:14] ERROR[11497][C-0000003b] astobj2.c: FRACK!, Failed assertion Excessive refcount 100000 reached on ao2 object 0x7f7c24004848 (0) {noformat} Recompiling asterisk with debug flags to trace memory (as requested in guide to asterisk issue): {noformat} [*] DONT_OPTIMIZE [*] COMPILE_DOUBLE [ ] DEBUG_THREADS [ ] DEBUG_FD_LEAKSthe final [*] BETTER_BACKTRACES [ ] LOTS_OF_SPANS [*] MALLOC_DEBUG ( ) DEBUG_CHAOS [*] BUILD_NATIVE     --- Extended --- [ ] REF_DEBUG [ ] AO2_DEBUG [ ] STATIC_BUILD [ ] REBUILD_PARSERS [ ] LOW_MEMORY [ ] DISABLE_INLINE [*] OPTIONAL_API XXX USE_HOARD_ALLOCATOR [ ] RADIO_RELAX [ ] G711_NEW_ALGORITHM < > G711_REDUCED_BRANCHING < > TEST_CODING_TABLES < > TEST_TANDEM_TRANSCODING ( ) ADDRESS_SANITIZER [ ] THREAD_SANITIZER XXX LEAK_SANITIZER XXX UNDEFINED_SANITIZER [ ] BUSYDETECT_TONEONLY [ ] BUSYDETECT_COMPARE_TONE_AND_SILENC [ ] BUSYDETECT_DEBUG [ ] INTEGER_CALLERID {noformat} and repeating the test after 6 days asterisk has the same behaviour (in few time (1 hour) memory starts to grow to the limit), but this time asterisk remain freezed and with 14 Gb of memory allocated and totally unresponsive: {noformat} [root@hermes asterisk-13.17.0]# ps aux | grep asterisk root      4925  0.0  0.0 115252   276 ?        S    apr26   0:00 /bin/sh /usr/sbin/safe_asterisk root      4927  142 80.2 17531648 13095380 ?   Sl   apr26 13878:51 /usr/sbin/asterisk -f -vvvg -c {noformat} the mmlog trace nothing: {noformat} [root@hermes asterisk]# cat mmlog 1523538186 - New session 1523601658 - New session 1523627081 - New session 1523814040 - New session 1524740535 - New session 1524740807 - New session 1524740809 - New session 1524741524 - New session 1524745950 - New session 1524746405 - New session 1524746417 - New session 1524746418 - New session 1524746493 - New session 1524746516 - New session 1524747598 - New session 1524751289 - New session 1524751337 - New session {noformat} On message there are a lot of warning of type : {noformat} [May  3 07:42:46] WARNING[6032] asterisk.c: No more connections allowed [May  3 07:42:46] WARNING[24523][C-00000401] channel.c: Exceptionally long voice queue length queuing to Local/9283@cnf_patch_not_radioonly-00000168;2 [May  3 07:42:46] WARNING[29799][C-00000043] channel.c: Exceptionally long voice queue length queuing to Local/9280@cnf_patch_not_radioonly-0000001d;2 [May  3 07:42:46] WARNING[19315][C-0000034f] channel.c: Exceptionally long voice queue length queuing to Local/9280@cnf_patch_not_radioonly-0000011c;2 [May  3 07:42:46] WARNING[1481][C-00000065] channel.c: Exceptionally long voice queue length queuing to Local/9280@cnf_patch_not_radioonly-0000002c;2 [May  3 07:42:46] WARNING[3161][C-0000006c] channel.c: Exceptionally long voice queue length queuing to Local/9281@cnf_patch_not_radioonly-0000002f;1 [May  3 07:42:46] WARNING[1372][C-00000062] channel.c: Exceptionally long voice queue length queuing to Local/9282@cnf_patch_not_radioonly-0000002b;1 [May  3 07:42:46] WARNING[21649][C-0000042a] channel.c: Exceptionally long voice queue length queuing to Local/9282@cnf_patch_not_radioonly-0000017a;1 [May  3 07:42:46] WARNING[9594][C-00000393] channel.c: Exceptionally long voice queue length queuing to Local/9280@cnf_patch_not_radioonly-00000139;2 [May  3 07:42:46] WARNING[6032] asterisk.c: No more connections allowed [May  3 07:42:46] VERBOSE[24547] manager.c: Manager 'astlog' logged on from 192.168.3.230 [May  3 07:42:46] WARNING[6032] asterisk.c: No more connections allowed [May  3 07:42:46] WARNING[7810][C-000003db] channel.c: Exceptionally long voice queue length queuing to Local/9281@cnf_patch_not_radioonly-00000158;2 [May  3 07:42:46] WARNING[6032] asterisk.c: No more connections allowed [May  3 07:43:36] WARNING[6032] asterisk.c: No more connections allowed [May  3 07:43:36] WARNING[6032] asterisk.c: No more connections allowed [May  3 07:43:36] WARNING[12603][C-00000465] channel.c: Exceptionally long voice queue length queuing to Local/9283@cnf_patch_not_radioonly-00000193;2 [May  3 07:43:36] WARNING[23367][C-0000035c] channel.c: Exceptionally long voice queue length queuing to Local/9281@cnf_patch_not_radioonly-00000122;1 [May  3 07:43:36] WARNING[2601][C-00000335] channel.c: Exceptionally long voice queue length queuing to Local/9283@cnf_patch_not_radioonly-00000111;2 {noformat} The problem is the start of memory growing after few days. I saw that other people had the same problem, but i've found no definitive solution.
Comments:	By: Asterisk Team (asteriskteam) 2018-05-03 04:02:44.487-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. 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]. By: Biz Biz (biz8031) 2018-05-03 04:09:23.600-0500 htop output of memory consumption By: Joshua C. Colp (jcolp) 2018-05-03 04:32:28.734-0500 It appears the bug you have submitted is against a rather old version of a supported branch of Asterisk. There have been many issues fixed between the version you are using and the current version of your branch. Please test with the latest version in your Asterisk branch and report whether the issue persists. Please see the Asterisk Versions [1] wiki page for info on which versions of Asterisk are supported. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions By: Biz Biz (biz8031) 2018-05-03 04:52:19.365-0500 Hi Joshua, i did the test on 13.17.0 actually in use (finished today) and on 13.20 (finished yesterday with the same results but after 10 days) to check the last version. I dont know if 13.21 fix the problem, maybe i can try the 15.4 ? (if compatible with application connected to AMI interface) Is this a known bug ? The test is long and require time (days) and VM (client) to reproduce; so i can give you a feedback in some days ( week :-) ) By: Joshua C. Colp (jcolp) 2018-05-03 04:55:52.150-0500 13.20 should be fine. We just don't like to go after bugs longer than a version or two behind, because in a lot of cases the bug is already fixed and it ends up wasting a lot of time. I'll let the person currently doing triage look at this further. By: George Joseph (gjoseph) 2018-05-07 08:41:20.216-0500 Hmmm.  The question is... "is this a chan_sip issue or a core issue?" Can you... * Install the libasan package from yum. * Rebuild asterisk just as you normally would for production except in menuselect "Compiler Flags" turn on ONLY the following options: BETTER_BACKTRACES, OPTIONAL_API, ADDRESS_SANITIZER.  If you normally use BUILD_NATIVE you can select that as well. * Run asterisk from the command line with as close to your production configuration as possible * Make a few calls. * Do a "core stop gracefully" from the asterisk command line. * Report the results. You should at least get something like... {noformat} ================================================================= ==16398==ERROR: LeakSanitizer: detected memory leaks Direct leak of 120 byte(s) in 2 object(s) allocated from:    #0 0x7fdd9e122850 in malloc (/lib64/libasan.so.4+0xde850)    #1 0x7fdd9abbfcfe in wcsdup (/lib64/libedit.so.0+0x18cfe) {noformat} By: Biz Biz (biz8031) 2018-05-07 11:28:15.682-0500 I did the test 3 times on a smaller test bed  but in the same environment (with a load of few minutes). the first time asterisk doesn't shoutdown gracefully, and i've killed. the second and the third had the same result : no output related to sanitaizer I've run asterisk from command line : asterisk -cvvvvvvvvvvvvvvvvv I've run my application (connected to asterisk via AMI) and started the calls (10 calls) and messaging via AMI. I've set asterisk to require a refresh o SIP user agent registration every 30 sec, (so in real scenario asterisk receives 50 registration message every 30 sec) follow the last rows of output after the stop of asterisk: {noformat} *CLI> *CLI> *CLI> core show channels Channel              Location             State   Application(Data) 0 active channels 0 active calls 86 calls processed *CLI> core stop gracefully Waiting for inactivity to perform halt... Unloading res_manager_devicestate.so  == Manager unregistered action DeviceStateList Unloading res_manager_presencestate.so  == Manager unregistered action PresenceStateList Unloading app_queue.so  == Manager unregistered action QueueStatus  == Manager unregistered action Queues  == Manager unregistered action QueueRule  == Manager unregistered action QueueSummary  == Manager unregistered action QueueAdd  == Manager unregistered action QueueRemove  == Manager unregistered action QueuePause  == Manager unregistered action QueueLog  == Manager unregistered action QueuePenalty  == Manager unregistered action QueueReload  == Manager unregistered action QueueReset  == Manager unregistered action QueueMemberRingInUse  == Unregistered application 'AddQueueMember'  == Unregistered application 'RemoveQueueMember'  == Unregistered application 'PauseQueueMember'  == Unregistered application 'UnpauseQueueMember'  == Unregistered application 'QueueLog'  == Unregistered application 'Queue'  == Unregistered custom function QUEUE_EXISTS  == Unregistered custom function QUEUE_VARIABLES  == Unregistered custom function QUEUE_MEMBER  == Unregistered custom function QUEUE_MEMBER_COUNT  == Unregistered custom function QUEUE_MEMBER_LIST  == Unregistered custom function QUEUE_WAITING_COUNT  == Unregistered custom function QUEUE_MEMBER_PENALTY Unloading func_callerid.so  == Unregistered custom function CALLERPRES  == Unregistered custom function CALLERID  == Unregistered custom function CONNECTEDLINE  == Unregistered custom function REDIRECTING Unloading func_lock.so  == Unregistered custom function LOCK  == Unregistered custom function TRYLOCK  == Unregistered custom function UNLOCK Unloading func_db.so  == Unregistered custom function DB  == Unregistered custom function DB_EXISTS  == Unregistered custom function DB_DELETE  == Unregistered custom function DB_KEYS Unloading func_sha1.so  == Unregistered custom function SHA1 Unloading func_version.so  == Unregistered custom function VERSION Unloading res_chan_stats.so Unloading res_limit.so Unloading res_clioriginate.so Unloading res_endpoint_stats.so Unloading res_realtime.so Unloading res_mutestream.so  == Unregistered custom function MUTEAUDIO  == Manager unregistered action MuteAudio Unloading res_clialiases.so Unloading res_convert.so Unloading res_security_log.so    -- Security Logging Disabled Unloading func_global.so  == Unregistered custom function GLOBAL  == Unregistered custom function SHARED Unloading func_aes.so . . . . .. == Unregistered application 'Goto'  == Unregistered application 'GotoIf'  == Unregistered application 'GotoIfTime'  == Unregistered application 'ImportVar'  == Unregistered application 'Hangup'  == Unregistered application 'Incomplete'  == Unregistered application 'NoOp'  == Unregistered application 'Proceeding'  == Unregistered application 'Progress'  == Unregistered application 'RaiseException'  == Unregistered application 'Ringing'  == Unregistered application 'SayAlpha'  == Unregistered application 'SayAlphaCase'  == Unregistered application 'SayDigits'  == Unregistered application 'SayNumber'  == Unregistered application 'SayPhonetic'  == Unregistered application 'SetAMAFlags'  == Unregistered application 'Wait'  == Unregistered application 'WaitExten'  == Manager unregistered action ShowDialPlan  == Manager unregistered action ExtensionStateList  == Unregistered custom function EXCEPTION  == Unregistered custom function TESTTIME  == Unregistered custom function FEATUREMAP  == Unregistered custom function FEATURE  == Manager unregistered action Bridge  == Unregistered application 'Bridge'  == Manager unregistered action BridgeTechnologyList  == Manager unregistered action BridgeTechnologySuspend  == Manager unregistered action BridgeTechnologyUnsuspend  == Unregistered channel type 'Surrogate'  == Manager unregistered action DataGet    -- Message handler 'dialplan' unregistered.  == Unregistered custom function MESSAGE  == Unregistered custom function MESSAGE_DATA  == Unregistered application 'MessageSend'  == Manager unregistered action MessageSend  == Sorcery unregistered wizard 'bucket'  == Sorcery unregistered wizard 'bucket_file'  == Manager unregistered action DBGet  == Manager unregistered action DBPut  == Manager unregistered action DBDel  == Manager unregistered action DBDelTree [root@hermes ~]# rpm -qa | grep asan libasan-4.8.5-28.el7.x86_64 [root@hermes ~]# {noformat} By: Richard Mudgett (rmudgett) 2018-06-01 12:22:12.028-0500 We need information about where the memory is going.  MALLOC_DEBUG can provide information about where Asterisk used malloc to allocate memory.  You can periodically look at the CLI "memory show summary" output to see where memory is increasing.  You can then drill down into specific files using the CLI "memory show summary <filename>" command. {noformat} [May  3 07:42:46] WARNING[6032] asterisk.c: No more connections allowed [May  3 07:42:46] WARNING[24523][C-00000401] channel.c: Exceptionally long voice queue length queuing to Local/9283@cnf_patch_not_radioonly-00000168;2 {noformat} However, the above log messages give some indication that this may not be a memory leak but threads getting blocked and media frames getting queued up.  The memory is then held in frame queues waiting to be processed.  The "No more connections allowed" message is indicating that you are trying to open more AMI connections than allowed.  The maximum allowed connections is currently 128. * Why do you have so many AMI connections opened? * We'll need a backtrace of all threads when the system is in the high memory state.  gdb command "thread apply all bt" and "thread apply all bt full" output.  You might want to look into using the ./contrib/scripts/ast_coredumper script.  https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace * You need to look at the MALLOC_DEBUG CLI "memory show summary" output to see which module is growing its memory usage.  Please provide the final output of "memory show summary" and indicate which module was growing.  A "memory show summary <filename>" output of the identified module would also be helpful. Please *attach* the captured files (More->Attach-Files) to the issue with a {{.txt}} extension.  Please *do not* paste the requested output into a comment like you have been doing. By: Biz Biz (biz8031) 2018-06-08 02:02:10.884-0500 output of memory show summary samolet every 10 minutes. By: Biz Biz (biz8031) 2018-06-08 02:02:29.933-0500 Hi, in the last weeks i've tried to upgrade to asterisk 15.4, but the results was the same. Now i've only a smallest test bed, on which test. I've compiled asterisk enabling malloc debug and sampling the memory summary on the small test bed (10% of original test bed), but i dont seee memory gowth (i attach the report). As i told after some days of load (sending alot of messages on AMI interface, mainly mute/unmute on some hundresd of channels) asterisk start becoming unresponsive giving different messages (too many reference...., task processor queue...., exceptionally log call ,ecc.... ), the memory start to grow untill OS kill the process (this behaviour confirm hypothesis of lock); the AMI connection is only one, maybe during the test the application has been disconnected and it try to reconnect. I'm doing a test on another system stressing AMI interface with mute/unmute every 500 ms on 120 channels, but there is no problem. By: Joshua C. Colp (jcolp) 2018-06-19 04:22:42.287-0500 Per the comment from Richard we really do need to see MALLOC_DEBUG information of a failing instance to see what is using all of the memory so we can narrow it down. Failing that we would need further information about precise usage of the system to see if we could narrow it down that way. By: Asterisk Team (asteriskteam) 2018-07-03 12:00:01.383-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 By: Biz Biz (biz8031) 2018-10-01 04:18:44.990-0500 Hi everyone, after a lot of time and a lot of test i've found a work around, not a solution because it was clear that in asterisk version from 13 to 15 (i've tried  with 13.7,13.17,13.19,13.20 ,15.4) there was a problem with my scenario , probably a lock using meetme and chan sip. Using an old version of asterisk (1.8.7) and loading havily the system i had no problem in seventeen day of load. By: Asterisk Team (asteriskteam) 2018-10-01 04:18:46.472-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Joshua C. Colp (jcolp) 2018-10-01 04:25:56.369-0500 Do you plan on providing the information previously mentioned for a current supported version? By: Biz Biz (biz8031) 2018-10-02 05:17:07.499-0500 Hi Joshua, In the past i've tried to debug asterisk 13 enabling debug  on thread,memory, and sampling memory status; but in that conditions asterisk cant handle the load of test and produces Gb of data from which i cant take useful informations. As i told you a haven't the esclusive access to test bed so now i stay with asterisk 1.8 avoiding the passage to 15 (maybe in the future if i need of ARI interface and out of call messages). Maybe as you told using meetme happen a lock and the rtp flows remain in memory (the growth of memory from 2 Gb to 16 Gb in 25 minutes is compatible with 500 alaw calls )   By: Joshua C. Colp (jcolp) 2018-10-02 09:59:18.726-0500 I'm suspending this as we'd need data on a current supported version.