Module: kamailio Branch: master Commit: b4aef50ef2386e92c8c0bb1ad6232ae009d6621c URL: https://github.com/kamailio/kamailio/commit/b4aef50ef2386e92c8c0bb1ad6232ae0...
Author: Henning Westerholt hw@kamailio.org Committer: Henning Westerholt hw@kamailio.org Date: 2018-11-13T21:47:56+01:00
rtp_media_server: initial creation of README file
---
Added: src/modules/rtp_media_server/README
---
Diff: https://github.com/kamailio/kamailio/commit/b4aef50ef2386e92c8c0bb1ad6232ae0... Patch: https://github.com/kamailio/kamailio/commit/b4aef50ef2386e92c8c0bb1ad6232ae0...
A small typo here:
2.1. Kamailio Modules
The module depends on the following modules (in the other words the listed modules must be loaded before this module): * tm - accounting module
A question:
Is rms_play() done asynchronously or does it reserve the K process that handled the request for the duration of the play?
-- Juha
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@tutpro.com wrote:
A small typo here:
2.1. Kamailio Modules
The module depends on the following modules (in the other words the listed modules must be loaded before this module): * tm - accounting module
A question:
Is rms_play() done asynchronously or does it reserve the K process that handled the request for the duration of the play?
-- Juha
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Julien Chavanton writes:
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.
So just to clarify, if Kamailio is started, for example, with -n 8, it does not limit the number of simultaneous calls where Kamailio is running rms_play() to 8?
-- Juha
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@tutpro.com wrote:
Julien Chavanton writes:
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.
So just to clarify, if Kamailio is started, for example, with -n 8, it does not limit the number of simultaneous calls where Kamailio is running rms_play() to 8?
-- Juha
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
One more question: at this stage, rtp_media_server is not able to play early audio?
-- Juha
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@tutpro.com wrote:
One more question: at this stage, rtp_media_server is not able to play early audio?
-- Juha
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Am Mittwoch, 14. November 2018, 07:00:08 CET schrieb Julien Chavanton:
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.
Hi Julien,
there is SDP parser functionality in the core (core/parser/sdp/sdp.h), if you need more functionality for parsing this should be probably extended there. The sdpops module then provides SDP handling function to use in the cfg file, using the core. Maybe it would be sufficient to use existing functionality here, or change/add some new functions in this module.
Best regards,
Henning
Thanks for the clarification
On Tue, Nov 13, 2018 at 11:00 PM Henning Westerholt hw@kamailio.org wrote:
Am Mittwoch, 14. November 2018, 07:00:08 CET schrieb Julien Chavanton:
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.
Hi Julien,
there is SDP parser functionality in the core (core/parser/sdp/sdp.h), if you need more functionality for parsing this should be probably extended there. The sdpops module then provides SDP handling function to use in the cfg file, using the core. Maybe it would be sufficient to use existing functionality here, or change/add some new functions in this module.
Best regards,
Henning
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services Kamailio security assessment - https://skalatan.de/de/assessment
Julien Chavanton writes:
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.
One application that I had in mind is to play some kind of announcement in early media, e.g., about the cost of the call, forbidden call destination, etc., and then, depending on the case, close or continue the call.
-- Juha
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@tutpro.com wrote:
Julien Chavanton writes:
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.
One application that I had in mind is to play some kind of announcement in early media, e.g., about the cost of the call, forbidden call destination, etc., and then, depending on the case, close or continue the call.
-- Juha
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-
Henning Westerholt -
Juha Heinanen -
Julien Chavanton