I already know that if not SRTP then FS has no problem with the load. I have no experience with rtpengine, so this brinngs in a new piece that I would also need to load test before sliding into production. I may just have to bring up some FS servers in the cloud and use them to generate load SRTP traffic unless someone has a better idea… From: FreeSWITCH-users [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Richard Chan Sent: Tuesday, October 31, 2017 11:20 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] SRTP scaling issues Just an idea: to isolate you use something else just to offload SRTP: e.g use rtpengine for SRTP/RTP bridging. This could show whether FreeSWITCH+SRTP is really to blame. You could even run rtpengine on the same box as FreeSWITCH since the CPU load looks manageable. Media path would look like: webrtc --[SRTP] -- (rtpengine+kamailio-to-rewrite-SDP) --[ RTP] -- FreeSWITCH On Tue, Oct 31, 2017 at 4:37 AM, Matthew Meek <mmeek@livexchange.com<mailto:mmeek@livexchange.com>> wrote: We have been using Freeswitch as our SBC and core switch for many years without issues. Recently we added public facing softphones using an additional server running Kamailio as TLS and webrtc bridge with FS handling media back to our core FS farm. We run a mix of webrtc and Zoiper softphones. All running SIPS (tls) but webrtc is SRTP (PCMU) and Zoiper is RTP (PCMU). We have been ramping up the webrtc traffic and at some magic point at busy times (~150 concurrent calls) the RTT and Packet loss for the webrtc calls goes crazy (as measured in the browser via RTCP and captured back on our logging servers). RTT jumps from 100ms to 2-3 seconds for most or all webrtc users and packet loss jumps from nothing to troubling on the Sending side back to FS only. Packets received are not an issue on webrtc side… webrtc can hear end caller, but end caller cannot hear webrtc well. Non webrtc traffic (Zoiper) have no reported impact. Server CPU (dual socket 6 core) looks great (no core over 20%) according to nmon… packets per second within reason (10Gb NICs). I am assuming the SRTP has some hidden scaling issue since this is the only difference between the two types of softphones. Has anyone seen this or have a workaround? I am at a loss. I assume if it is encryption overhead the CPU would be saturated and it is not. Why a single direction of SRTP traffic is impacted has me up late at night. A side note… does anyone know of a SIPP replacement that does SRTP so I can test load against this to isolate? Thanks, Matthew Meek _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Richard Chan Chief Architect TreeBox Solutions Pte Ltd 1 Commonwealth Lane #03-01 Singapore 149544 Tel: 6570 3725 http://www.treeboxsolutions.com Co.Reg.No<http://Co.Reg.No>. 201100585R