Reloading rtp causes asterisk to stall

is this the way it is supposed to work when changing rtp.conf file

i wanted to change to more higher port from 20000 to 60000
but it stalled all asterisk is this normal ?

[general]
;
; RTP start and RTP end configure start and end addresses
;
; Defaults are rtpstart=5000 and rtpend=31000
;
rtpstart=10000
rtpend=60000

module reload res_rtp_asterisk.so

Anything that causes Asterisk to appear to stop handling calls is not normal

do you think i should file a issue ?

Do you think you should file an issue?

On Monday 16 February 2026 at 13:34:04, benphone wrote:

do you think i should file a issue ?

I think you should first of all try to get more detail about what is happening
when “it stalled all asterisk”.

For example, what shows up in verbose logging output?

Does Asterisk create a core dump?

Does Asterisk actually stop, or is the process still running and using CPU
resources?

What happens if you narrow the range of ports you are asking Asterisk to use?

  • if “10000 - 60000” causes a problem, what happens with “10000 - 40000”?
  • if that’s still a problem, try “10000 - 25000”; if it isn’t, try “10000 -
    50000” etc.

The more detail you can provide on what is actually happening, the more likely
it is that someone can help you fix things.

Also, please let us know:

  • which version of
  • which Linux distribution this is running on
  • which version of Asterisk you are running
  • whether this is a native (bare-metal) installation or virtualised
  • if virtualised, which virtualisation environment is it
  • anything else which might help someone reproduce the problem.

Finally, and maye just for my personal curiosity, why do you want to extend
the RTP port range this much?

Antony.


“Remember: the S in IoT stands for Security.”

  • Jan-Piet Mens

in the logs i see

[2026-02-16 12:25:01] VERBOSE[22164] loader.c: The previous reload command didn’t finish yet
[2026-02-16 12:26:09] VERBOSE[16429] loader.c: The previous reload command didn’t finish yet
[2026-02-16 12:30:01] VERBOSE[42627] loader.c: The previous reload command didn’t finish yet
[2026-02-16 12:35:01] VERBOSE[57605] loader.c: The previous reload command didn’t finish yet

then now i tried on a different node

this is interesting a 15 second stall for res_pjsip_mwi.so
while doing a reload via the cli

Line 204273: [2026-02-16 19:52:44] VERBOSE[3624648] loader.c: Reloading module ‘res_pjsip_mwi.so’ (PJSIP MWI resource)
Line 438801: [2026-02-16 19:52:59] VERBOSE[3624648] loader.c: Reloading module ‘res_pjsip_publish_asterisk.so’ (PJSIP Asterisk Event PUBLISH Support)

the reason i did it was to try figure out why a incoming call with a high port from a other provider was giving me dead air the invite stated a port 56000 but asterisk was sending to a lower port looks like i did not like the high port rtp

with rtp changing it was almost minute

Line 266787: [2026-02-16 19:34:34] VERBOSE[3578696] loader.c: Reloading module ‘res_pjsip_mwi.so’ (PJSIP MWI resource)
Line 495235: [2026-02-16 19:35:01] VERBOSE[3581645] loader.c: The previous reload command didn’t finish yet
Line 593653: [2026-02-16 19:35:20] VERBOSE[3578696] loader.c: Reloading module ‘res_pjsip_publish_asterisk.so’ (PJSIP Asterisk Event PUBLISH Support)

and the original it got stuck at

[2026-02-16 12:23:13] VERBOSE[2803] loader.c: Reloading module ‘res_pjsip_config_wizard.so’ (PJSIP Config Wizard)
[2026-02-16 12:25:01] VERBOSE[22164] loader.c: The previous reload command didn’t finish yet

How is this related to res_rtp_asterisk.so? Put together something reproducible and open an issue.

i am not sure what the core issue is .

is it just high load 1.5 k registered 500 channels on a busy system that caused it

now thinking i should have done a coredump o well …

i do not want to try it again on a system in production

There are no configuration options that control the allowable port ranges that Asterisk will send to. It will send to the port in the SDP, unless symmetric RTP is set and it receives from a different port, in which case it will start sending to that port.

feels to me a general reload is the issue need to figure out which is the module causing it

using asterisk 20.18.2

what would be the steps to see what is causing the issue !?

A backtrace would show what is blocked.