Load test with direct media and PJSIP

Hi everyone

we are trying to loadtest an Asterisk certified/16.8-cert2.
We have the port range configured to 5000-6000 (this range is a fixed requirement) in rtp.conf.
We want to test a large number (600 calls) of simultaneous calls setup within 1 second with direct media rtp connections (so that the limited port range shouldn’t limit the number of calls).
We had a similar setup with an older version using sip, which worked. In the new version we are using pjsip.
However, Asterisk can only create 249 calls. The 250th call (and all after that) always fails.
If we increase the portrange up to 7000 the 499th call fails.
So it appears that Asterisk does not release the rtp ports for the calls after the direct media connection was established.
The test PC and Asterisk are on the same network. UAC and UAS are executed by the same PC.
It is most likely a configuration error on our side, but we can’t find a solution for it.
Does anyone have an idea how to fix this?

PJSIP.conf is configured in the following way

type = endpoint
context = sipp
disallow = all
allow = alaw
allow = ulaw
allow = g722
direct_media = yes

type = aor
contact = sip:

type = endpoint
context = sipp
disallow = all
allow = alaw
allow = ulaw
allow = g722
direct_media = yes
aors = sippuas_TWa_direct*

Both the sipp and sippuas_TWa_direct show up with “pjsip show endpoint” and both list direct_media : true.

The 249 calls produce these messages in asterisk, so it appears as if the direct media connection is successfully established. Packet captures also shows no RTP packets going through the asterisk server:

== Setting global variable ‘SIPDOMAIN’ to ‘’
– Executing [21001@sipp:1] Dial(“PJSIP/sipp-00000000”, “PJSIP/sippuas_TWa_direct”) in new stack
– Called PJSIP/sippuas_TWa_direct
– PJSIP/sippuas_TWa_direct-00000001 is ringing
– PJSIP/sippuas_TWa_direct-00000001 is ringing
– PJSIP/sippuas_TWa_direct-00000001 answered PJSIP/sipp-00000000
– Channel PJSIP/sippuas_TWa_direct-00000001 joined ‘simple_bridge’ basic-bridge <2fc96e1c-23a6-4aa0-862d-282e90c965a6>
– Channel PJSIP/sipp-00000000 joined ‘simple_bridge’ basic-bridge <2fc96e1c-23a6-4aa0-862d-282e90c965a6>

Bridge 2fc96e1c-23a6-4aa0-862d-282e90c965a6: switching from simple_bridge technology to native_rtp
Remotely bridged ‘PJSIP/sipp-00000000’ and ‘PJSIP/sippuas_TWa_direct-00000001’ - media will flow directly between them

However, the 250th call (and all beyond that) yields these kinds of errors:

[Apr 5 14:51:31] ERROR[31901]: res_rtp_asterisk.c:3703 rtp_allocate_transport: Oh dear… we couldn’t allocate a port for RTP instance ‘0x7f3394891960’
== Everyone is busy/congested at this time (1:0/0/1)
– Auto fallthrough, channel ‘PJSIP/sipp-000008b4’ status is ‘CHANUNAVAIL’
[Apr 5 14:51:31] WARNING[31901]: res_rtp_asterisk.c:2781 dtls_srtp_stop_timeout_timer: Unable to cancel schedule ID 0.
This is probably a bug (res_rtp_asterisk.c: dtls_srtp_stop_timeout_timer, line 2781).
[Apr 5 14:51:31] ERROR[31901]: res_pjsip_sdp_rtp.c:249 create_rtp: Unable to create RTP instance using RTP engine ‘asterisk’

On the sipp side, the 250th call gets a 503 Service Unavailable message.

Thanks in advance!
Best regards,

EDIT: Sorry, messed up the formatting. Hopefully fixed now

PJSIP does not release RTP resources when direct media is active. Any “fixing” of it would require changing the code and modifying stuff to work that way. I don’t believe chan_sip worked this way either, but I don’t remember specifics of it.

So there is no solution other than to increase the port range?

If what you’re asking is if there is any other configuration which would influence this and not require code changes, then I believe the answer is no.

Yes, that was what I was asking/hoping for. Still, thanks for the quick replies!

I don’t think it would be a good idea to release the port, as that could result in the call failing if something happened (e.g. one side hanging up, with the other continuing, or adding recording) that required the all to be re-INVITEd back.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.