[Home]

Summary:ASTERISK-27679: res_pjsip: Endpoint destruction does not free DTLS configuration
Reporter:Mak Dee (makdorf@gmail.com)Labels:pjsip
Date Opened:2018-02-16 05:50:44.000-0600Date Closed:2018-02-19 06:12:44.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip
Versions:13.18.2 14.6.2 15.2.0 Frequency of
Occurrence
Related
Issues:
is duplicated byASTERISK-27281 Increased memory usage when using Sorcery Caching
Environment:CentOS Linux release 7.4.1708 (Core) Docker version 17.09.1-ce, build 19e2cf6 Asterisk and DB are working in different docker containers.Attachments:( 0) mem_alloc_-_sorcery_memory_cache_and_realtime_dis._0m._up.txt
( 1) mem_alloc_-_sorcery_memory_cache_and_realtime_dis._35m._up.txt
( 2) mem_alloc_-_sorcery_memory_cache_and_realtime_en._0m._up.txt
( 3) mem_alloc_-_sorcery_memory_cache_and_realtime_en._1h._up.txt
( 4) memory_show_allocations_rtp_engine.c.txt
Description:Problem described in parent task and I’ve faced the same issue.
I did some investigation and there is what I’ve found out.
When I remove lines which relate to the «realtime» and memory_cache from sorcery.conf then «rtp_engine.c» doesn’t allocate memory during the time. This is figured out in two pastes below:
[^mem_alloc_-_sorcery_memory_cache_and_realtime_dis._(0m._up).txt]
[^mem_alloc_-_sorcery_memory_cache_and_realtime_dis._(35m._up).txt]

When I add lines which relate to the «realtime» and memory_cache to the sorcery.conf then memory allocation by «rtp_engine.c» starts to increase during the time. This is also figured out in two pastes below:
[^mem_alloc_-_sorcery_memory_cache_and_realtime_en._(0m._up).txt]
[^mem_alloc_-_sorcery_memory_cache_and_realtime_en._(1h._up).txt]

Output for memory show allocations rtp_engine.c [^memory_show_allocations_rtp_engine.c.txt]

Sorcery cache:
{code:title=aor.cli|borderStyle=solid}
CLI> sorcery memory cache show res_pjsip/aor
Sorcery memory cache: res_pjsip/aor
Number of objects within cache: 15
Maximum allowed objects: 100
Number of seconds before object expires: 1800
Number of seconds before object becomes stale: 1500
Expire all objects on reload: On
{code}

{code:title=auth.cli|borderStyle=solid}
CLI> sorcery memory cache show res_pjsip/auth
Sorcery memory cache: res_pjsip/auth
Number of objects within cache: 15
There is no limit on the maximum number of objects in the cache
Number of seconds before object expires: 1800
Number of seconds before object becomes stale: 200
Expire all objects on reload: On
{code}

{code:title=endpoint.cli|borderStyle=solid}
CLI> sorcery memory cache show res_pjsip/endpoint
Sorcery memory cache: res_pjsip/endpoint
Number of objects within cache: 15
Maximum allowed objects: 100
Number of seconds before object expires: 600
Number of seconds before object becomes stale: 60
Expire all objects on reload: On
{code}

{code:title= registration.cli|borderStyle=solid}
CLI> sorcery memory cache show res_pjsip/registration
Sorcery memory cache: res_pjsip/registration
Number of objects within cache: 0
Maximum allowed objects: 100
Number of seconds before object expires: 600
Number of seconds before object becomes stale: 60
Expire all objects on reload: On
{code}

{code:title= transport.cli|borderStyle=solid}
CLI> sorcery memory cache show res_pjsip/transport
Sorcery memory cache: res_pjsip/transport
Number of objects within cache: 3
There is no limit on the maximum number of objects in the cache
Object expiration is not enabled - cached objects will not expire
Object staleness is not enabled - cached objects will not go stale
Expire all objects on reload: On
{code}

{code:title= identify.cli|borderStyle=solid}
CLI> sorcery memory cache show res_pjsip/identify
Sorcery memory cache: res_pjsip/identify
Number of objects within cache: 2
Maximum allowed objects: 100
Number of seconds before object expires: 3600
Number of seconds before object becomes stale: 60
Expire all objects on reload: On
{code}

During the test, the PBX didn’t receive or make a calls.
Comments:By: Asterisk Team (asteriskteam) 2018-02-16 05:50:45.200-0600

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: Joshua C. Colp (jcolp) 2018-02-16 06:05:27.735-0600

This appears to be the result of res_pjsip, not rtp_engine. The DTLS configuration is not getting freed when the endpoint goes away.

By: Friendly Automation (friendly-automation) 2018-02-19 06:12:45.828-0600

Change 8241 merged by Jenkins2:
res_pjsip: Endpoint destruction does not free DTLS configuration

[https://gerrit.asterisk.org/8241|https://gerrit.asterisk.org/8241]

By: Friendly Automation (friendly-automation) 2018-02-19 06:18:36.640-0600

Change 8242 merged by Jenkins2:
res_pjsip: Endpoint destruction does not free DTLS configuration

[https://gerrit.asterisk.org/8242|https://gerrit.asterisk.org/8242]

By: Friendly Automation (friendly-automation) 2018-02-19 06:25:01.197-0600

Change 8243 merged by Jenkins2:
res_pjsip: Endpoint destruction does not free DTLS configuration

[https://gerrit.asterisk.org/8243|https://gerrit.asterisk.org/8243]