Bug Report: pjsip/outsess Taskprocessors Persist After Call Completion

Asterisk Asterisk Support
1

Summary

On Asterisk 22.10.1, pjsip/outsess taskprocessors continue to accumulate after outbound PJSIP calls have completed. The taskprocessors remain registered even when there are no active outbound calls.

While investigating a memory issue, we initially suspected these taskprocessors were responsible. However, further testing showed they are not the cause of the high RSS memory usage. After forcing malloc_trim(0), the process RSS dropped from approximately 30 GB to 5.3 GB, while the number of pjsip/outsess taskprocessors remained unchanged.

This suggests the taskprocessors are persistent idle objects rather than the source of memory consumption.

Environment

  • Asterisk Version: 22.10.1
  • Channel Driver: PJSIP
  • Operating System: Linux
  • Call Type: High-volume outbound dialing using Dialplan + AGI
  • Call Flow:
Inbound Trigger
    ↓
Dialplan
    ↓
AGI(tff/broadcast.agi)
    ↓
Dial(PJSIP/...)
    ↓
Outbound Call

No AMI or ARI is used for originating calls.

Problem Description

After processing approximately 186,000 outbound calls, the system reports:

1 active channel
1 active call
186797 calls processed

However:

asterisk -rx "core show taskprocessors" | grep '^pjsip/outsess' | wc -l

63467

The number of taskprocessors remains around 63,000 even when only a single active call exists.

Sample Output

pjsip/outsess/0091160030808d-0004ea64
pjsip/outsess/009116003080866d-000536ea
pjsip/outsess/009116003080866d-00055866

Representative entries:

pjsip/outsess/009116003080514cc
4 0 1 450 500 0 388960

pjsip/outsess/0091796979704d5d6
7 0 1 450 500 0 42543

Observations:

  • Queue Depth = 0
  • Max Depth = 1
  • Taskprocessors appear completely idle.
  • They do not disappear after calls terminate.

Memory Investigation

Before calling malloc_trim(0):

VmRSS: ~30 GB

After executing:

call (int) malloc_trim(0)

RSS immediately reduced to:

VmRSS: ~5.3 GB

The pjsip/outsess count remained unchanged:

63467

Therefore:

  • High RSS was due to allocator retention and not these taskprocessors.
  • However, the taskprocessors themselves remain registered indefinitely.

Expected Behavior

When an outbound PJSIP session is destroyed, its associated pjsip/outsess taskprocessor should also be released unless intentionally cached by design.

After completed calls, the number of idle pjsip/outsess taskprocessors should not continue to grow indefinitely.

Actual Behavior

Completed outbound sessions leave behind idle pjsip/outsess taskprocessors.

The total number increases over time with call volume and does not decrease, even when there are virtually no active calls.

Questions

  1. Is this expected behavior for pjsip/outsess taskprocessors?
  2. Are these taskprocessors intentionally retained for reuse?
  3. If not, could there be a missing cleanup path for outbound session serializers in Asterisk 22.10.1?
  4. Has this behavior already been fixed in a later 22.x release?

Any guidance on whether this is expected or a regression would be appreciated.

2

A few comments, starting with bug reports don’t go on the forum. They go on Github[1].

  1. No they should not exist
  2. They are not
  3. The most likely case is that the taskprocessor is not leaked, but the overall session itself - on [bug]: chan_pjsip_hangup crash (taskprocessor teardown race) · Issue #1985 · asterisk/asterisk · GitHub there was mention of specific case where this can occur but no issue has been filed yet, and there haven’t been any other filed
  4. There is no later 22.x release so this question doesn’t make sense, did you use AI to come up with this report and it imagined there was a later release or did you not look?

Additionally the outsess taskprocessors won’t exist as of the next release.

If you do file a Github issue you will need to provide logs and further information. If you use AI and it invents things that waste time that will be bad, so verify what it provides.

[1] Issues · asterisk/asterisk · GitHub

3

interesting

this is my output looks like 62 orphaned outsess
[root@db02 ~]# asterisk -rx "core show taskprocessors" | grep '^pjsip/outsess' | wc -l
62
[root@db02 ~]# asterisk -rx " core show calls"
0 active calls
7472607 calls processed
[root@db02 ~]# asterisk -rx "core show taskprocessors" | grep '^pjsip/outsess' | wc -l
62
[root@db02 ~]#

4

I am not using any AI,

The behaviour i shared is observed on the production.

Where calls disconnect channel closed cdr creats but outsess still present under load

5

if i read up correct

Additionally the outsess taskprocessors won’t exist as of the next release.

this issue could be fixed by pr #2030 can you test

if not file a issue

6

Hi ,

whenw e can expect to have this merged in asterisk 22.10

7

It won’t be. It will be in the next set of releases, 22.11.0.

8

There is also no guarantee that this actually fixes the underlying issue. The taskprocessor still existing is almost certainly a symptom, not the actual issue itself.

9

i can open a issue but i do not have what to backtrace to figure out why it is open
what would be the way to trace it

10

A backtrace wouldn’t do anything really. Specific details about the calls themselves - the scenario details. [bug]: chan_pjsip_hangup crash (taskprocessor teardown race) · Issue #1985 · asterisk/asterisk · GitHub mentioned if a BYE is sent and doesn’t get a response, for example so confirming that is the case.