change play_pcap_audio raw socket to udp socket

[stars-in-darkness]

At first I must say is forgive my pool english, thanks for read this pull-request text.

There ia a bug with sipp when use play_pcap_audio to play pcap audio files in sipp stressing test, first give some report on the internet,here is the hyperlink weburl:
https://sourceforge.net/p/sipp/mailman/message/27432688/

https://sourceforge.net/p/sipp/mailman/message/35015333/

Unfortunately, we trip in the bug one night when we begin stressing test on our voip system, as a result we changed to use rtp_stream to avoid the problem with had tried almost any ways the whole night on work. And now I wannt to fix the bug.
the syndrome is below:

./sipp 192.168.2.112:10000 -i 192.168.9.138 -sf call_ivr_send.xml -inf call_ivr_send.csv -m 400 -l 400

<nop> <action> <exec play_pcap_audio="pcap/cityinsky_u.pcap"/> </action> </nop>

Our network card has RSS(Receive Side Scaling) queue, but for the reason RSS do not hash the port or the other reason, it all foward to cpu12 and then 100% si to lost packages. Cause this one-half is network card RSS not ideal and the other half is the use of RAW sockets.

when the sipp run, we monitor the system performance use

perf top -C 12 --call-graph=dwarf

lookup the document of linux kernel network stack, the function raw_local_deliver is deliver the packets to raw sockets. what's more, a raw sockets will receive the whole prototype's packets, what means if sipp calls 400, each of 400 raw sockets will receive the whole 400 calls' packets. In this situation, although sipp do not received the packets, but the kernel network stack still do the copy opearation, queue operation and intent to deliver to the applicational layer and release the skb later. Cause the softirq high especially when all packets to one cpu irq. Except for the fault of uncompleted network card RSS, use raw socket for sipp performance test is not a ideal way.

At last ,what I do is change the raw socket use to udp socket when use play_pcap_audio, and then the top si is very low, the bug is been fixd.

[wdoekes]

Thanks for your PR. At first glance, the PR looks okay, but there is one problem: the pcap support allows for multiple source/destination ports to be used (commonly for RTCP on port+1 or a simultaneous video stream on port+2).

When simply switching to UDP sockets, without catering for multiple source/destination ports, you will remove that functionality.

From the quick look, I don't know what the real problem you're facing is.

Maybe you're better of using the RTPSTREAM functionality instead?

[stars-in-darkness]

Thanks for your reply. The reason why I change it is if you use play_pcap_audio with raw sokcets , some machine sipp runs at can't over concurrent 400(e.g on my machine)，when sipp runs you can open another terminal use the top to see the core network card assigned soft interrupt to be 100% si ,and the media packages and sip signal packages began to loss. The concurrent 400-500 is too low  for stressing our voip systems. When I change it , I don't see so far as I'm a not a sipp expert. If for the reason you mentioned can not change , we should change to use RTPSTREAM .But  we  must know the problem and write a tips in the user manual document ,thanks. By the way,if you use play_pcap_audio  up the concurrent to over 500 or 1000,maybe you will see the problem with top (the si  of  one cpu  core), thanks for you reply.

…

------------------ 原始邮件 ------------------ 发件人: "SIPp/sipp" ***@***.***>; 发送时间: 2022年3月4日(星期五) 晚上8:13 ***@***.***>; ***@***.******@***.***>; 主题: Re: [SIPp/sipp] change play_pcap_audio raw socket to udp socket (PR #571) Thanks for your PR. At first glance, the PR looks okay, but there is one problem: the pcap support allows for multiple source/destination ports to be used (commonly for RTCP on port+1 or a simultaneous video stream on port+2). When simply switching to UDP sockets, without catering for multiple source/destination ports, you will remove that functionality. From the quick look, I don't know what the real problem you're facing is. Maybe you're better of using the RTPSTREAM functionality instead? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: ***@***.***>