[sr-dev] New module proposal : RTP Media Server

[Julien Chavanton]

I meant,

"The module is now working and was tested with several softphones."

On Thu, Nov 1, 2018 at 3:40 PM Julien Chavanton <jchavanton at gmail.com>
wrote:

> Dear Kamailians,
>
> I just opened a merge request for a new module called RTP Media Server
>
> I understand that integrating an RTP/Media endpoint directly in Kamailio
> may seems strange at first.
> Let me share my thoughts ...
>
> By combining Kamailio, oRTP and mediastreamer2
> this module is providing some very good foundation to support RTP endpoint
> and various media processing features.
>
> This seems like a great idea for various use cases like IoT, IVR or other
> specific needs.
>
> Kamailio is still handling everything related to SIP/SDP (the module is
> adding some SDP parsing, they could be integrated in the core if this seems
> fit).
>
> By doing integration with a library we can benefit from the scripting
> engine and probably KEMI.
> This does not means that everyone should run this module on a Kamailio
> sever acting as a load balancer, of course CPU intensive operations like
> resampling and encoding may be taking place on the server.
>
> oRTP is providing RTP endpoints compliant with (RFC 3550)
>
> MediaStreamer2, even if written in C is quite a high level library,
> because it is implementing a framework for audio processing using graphs of
> filters, filters can be to do various things.
> Similar to playing with lego blocks :)
>
> - Support for most free and some non free codecs can be added easily.
> - Work to bridge calls is already in progress in the module.
> - Mobile phone support ARM CPU and other embedded scenario should be
> supported
>
> Mediastream2 is creating one thread per call "msticker", this can work
> smoothly in Kamailio even if it is forking processes.
> Shared memory allocation is supported using wrapper around malloc/free
> used by the libraries.
>
> This project was started last year, I exposed the idea at
> KamailioWorld2017, the feedbacks I god where not all positives :)
>
> But we did speak about it again at ClueCon2018 and I was encouraged to
> complete the work and propose a MR.
>
> The module is not working and was tested with several softphones.
>
> I think it is time to submit it ... before considering adding more
> features or investing more time in it.
>
> Julien
>
>
> Example config using the features already implemented
>
> event_route[rms:start] {
>         xnotice("[rms:start] play ...\n");
>         rms_play("/tmp/reference_8000.wav", "rms:after_play");
> };
>
> event_route[rms:after_play] {
>         xnotice("[rms:after_play] play done...\n");
>         rms_hangup();
> };
>
> route {
>         if (t_precheck_trans()) {
>                 t_check_trans();
>                 exit;
>         }
>         t_check_trans();
>         if (is_method("INVITE") && !has_totag()) {
>                 if (!rms_answer()) {
>                         t_reply("503", "server error");
>                 }
>         }
>
>         if (is_method("BYE")){
>                 rms_media_stop();
>         }
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20181101/0f4d1499/attachment-0001.html>