Hi Juha, I see the typo, I will correct it next time I improve the module. No Kamailio processes are blocking, one thread is started for each call / media stream the thread is running a "ticker" that is processing all the samples in the audio streams. Here is an example of the audio stream running in the thread transmit : FilePlayer >> Resampler >> Encoder >> RTP Send In the same thread the received stream is runned receive : RTP Received >> Sink 5(8631) INFO: rtp_media_server [rms_media.c:244]: rms_start_media(): m[0x7fffef20bf58]call-id[0x7fffef20c158] 018-11-14 04:40:31:807 bctbx-message-ms_filter_link: MSFilePlayer:0x7fffef20fc40,0-->MSResample:0x7fffef20fff8, 018-11-14 04:40:31:807 bctbx-message-ms_filter_link: MSResample:0x7fffef20fff8,0-->MSUlawEnc:0x7fffef20f468,0 018-11-14 04:40:31:807 bctbx-message-ms_filter_link: MSUlawEnc:0x7fffef20f468,0-->MSRtpSend:0x7fffef20f170,0 018-11-14 04:40:31:807 bctbx-message-ms_filter_link: MSRtpRecv:0x7fffef20ef88,0-->MSVoidSink:0x7fffef2103c8,0 018-11-14 04:40:31:807 bctbx-message-Initializing speex resampler in mode [voip] =========================================================== AUDIO SESSION'S RTP STATISTICS ----------------------------------------------------------- sent 341 packets 0 duplicated packets 58652 bytes received 331 packets 0 duplicated packets 56772 bytes incoming delivered to the app 56084 bytes incoming cumulative lost 0 packets incoming received too late 0 packets incoming bad formatted 0 packets incoming discarded (queue overflow) 0 packets sent rtcp 0 packets received rtcp 4 packets =========================================================== =========================================================== FILTER USAGE STATISTICS Name Count Time/tick (ms) CPU Usage ----------------------------------------------------------- MSRtpSend 682 0.0192826 42.1762 MSRtpRecv 682 0.0171714 37.5585 MSFilePlayer 682 0.004722 10.3283 MSUlawEnc 682 0.00381368 8.34154 MSResample 682 0.000403905 0.883448 MSVoidSink 327 0.000677918 0.712085 MSUlawDec 0 0 0 =========================================================== On Tue, Nov 13, 2018 at 8:29 PM Juha Heinanen <jh(a)tutpro.com> wrote:

You are right, this limit does not exist, you can run Kamailio with only one UDP worker if you want, all the threads are started from a forked process, not even a worker process (to be precise). The reason to create all the threads from one specific process and centralize the interactions with the threads from one process is that we may not be forced to use shared memory, this can be problematic if there is a bug/limitation in the malloc wrapper/abstraction in one library. I do not know what are the bottlenecks, since I did not do any load tests yet. However I did a lot of tests and some profiling on the filters in the past, one thing that is very nice with MediaStreamer2 is that you can find where the CPU time is spent in each filter. One example of bottle neck that can be surprising is that the speex resampler that can be CPU intensive in some scenarios. Some encoder like Opus can be CPU intensive as well. If one filter is using too much CPU it will be easy to find it looking at the logs. At one point we could use the ticker filter stats to create overall perf reports to clarify in which filter was the CPU time spent. I know that oRTP was used 10 years ago to build server side applications handling 2000 calls on an x86 server. On Tue, Nov 13, 2018, 21:17 Juha Heinanen <jh(a)tutpro.com wrote:

Good question, not available at the moment since there is no call transfer/bridge command yet. We always answer before we start the RTP stream etc. The work is started to bridge call legs and I am hoping to complete it soon. However, bridging early media may be suffisant, in the end "faking" a remote ringing may not be a very good user experience. But maybe we want to play a customized ring back tone. The work in progress is more about activating a few codecs already available as filters for transcoding and SDP negociation on both side, this is one thing that needs to be done in Kamailio since this is not provided by oRTP and Mediastreamer2 and we are using only Kamailio for SIP and SDP. The module will have to provide the missing SDP handling, some of it could be moved in the core or SDPOPs not sure about that. On Tue, Nov 13, 2018, 21:19 Juha Heinanen <jh(a)tutpro.com wrote:

Thanks for the clarification On Tue, Nov 13, 2018 at 11:00 PM Henning Westerholt <hw(a)kamailio.org> wrote:

I see, we can consider supporting this "depending on the case" early media but it seems to me you will have only one way audio and no DTMF to take your decision. One other consideration is to remain in the media path for the entire call or not, we will have to re-invite both sides if we want to be removed from the media path even if it was just for early media. This is fine and proper support for re-invite is needed and interesting in the context of this module. Thanks for sharing On Wed, Nov 14, 2018 at 1:35 AM Juha Heinanen <jh(a)tutpro.com> wrote: