Recently, I was running the loading test on Asterisk 1.4.x. I used SIPP to run a simple loading test. In my scenario, SIPP made calls to Asterisk , and Asterisk started to play musiconhold function like this:
In the beginning, I did not discover that there was a bug in SIPP v3.1 that SIPP would get wrong remote RTP ports (only 4 digits) and run the script of SIPP like this:
./sipp 192.168.1.1 -sn uac_pcap -l 20 -i 192.168.1.100
The CPU loading under this scenario is pretty fine.
However, I discovered that those RTP packets from SIPP did not send to the correct port of Asterisk actually. So, I restricted the RTP port range and force SIPP could send RTP packets into Asterisk. Then I run the same scenario again and the CPU loading was pretty high.
I think the high CPU loading of Asterisk is due to handling the RTP packets from SIPP. However, Asterisk should not need to do that. To deal with those RTP packets from a held UA is wasting the CPU power. Maybe it is a good way that Asterisk ignores those RTP packets from a held UA or just send a re-INVITE request with “sendonly” attribute to tell the held UA not sending any further RTP packets to server and just listening musiconhold voices instead.