[OpenSIPS-Users] RTPproxy project
Răzvan Crainea
razvan at opensips.org
Fri Jun 27 16:51:02 CEST 2014
Hi, Maxim!
Good news, I am glad you are interested in these features. I will fork
the project in our organization and push the requests there so you can
revise them before merging them.
We currently have them implemented for 1.2 - shall we adapt the changes
for the master branch?
Best regards,
Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
On 06/20/2014 11:45 PM, Maxim Sobolev wrote:
> Hey Bogdan, thanks for sharing your ideas for us. In fact all of those
> items that you have listed are already on drawing board for the next 2-3
> months development here:
>
> - Send timeout notifications to different OpenSIPS servers (more than
> one)
> - Different timeout values for early media and established calls
> (longer for early, shorter for established)
> - Play music on hold in early media state
> - Detect on-hold and disable timeouts (search different solution here)
> - Do not send media timeout if other sessions are active (video and
> audio)
> - In bridge mode asymmetric should not be always assumed
> - Cache played files instead of reading them from the disk all the time
>
> I am particularly interested in the timeout notifications and cache for
> playing files, so maybe you can start with forking out main branch in
> the github and pushing your patches there? For playing cache, I have
> been planning to use mmap() and refcounting, so I am particularly
> curious which path did you take. We need this in order so that we can
> use rtpproxy to generate test streams for other rtpproxy, or maybe even
> to itself. I have started some automated regression testing suite here
> we will be pushing it our pretty soon.
>
>
>
>
> On Fri, Jun 20, 2014 at 2:22 AM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
> Hello Maxim, Hello Jev,
>
> Sorry for taking so long to answer to these emails.
>
> I'm really glad to find out that the rtpproxy project is actually
> moving along and even more, evolving - it is a critical component in
> our platforms (and for most OpenSIPS deployments) and we got a bit
> concerned about what is going on with rtpp. To be honest, we had on
> the table the possibility to fork it and continue by ourselves - but
> I do not want to re-invent the wheel or to pollute the environment
> with yet another relay relaying tool (anyhow, there is this
> rtpengine stuff popping around lately )
>
> We will be more than happy to get involved - as ideas, experience
> and work - in the rtpproxy evolution ; of course, if you guys are
> willing to accept it :). One again , rtpproxy is too important to
> us to stay neutral and lately there are more and more features
> touching both SIP and RTP ....so there is a strong need for a better
> integration between OpenSIPS and RTPProxy, IMHO.
>
> Now, technically speaking, the kind of problems we mainly faced are
> (a) scaling with HW (especially with the old single threaded model),
> (b) redundancy and (c) controlling streams (multiple streams
> audio/video in the same SIP session, on-hold, etc).
>
> What we did (and have as patches):
> - Send timeout notifications to different OpenSIPS servers (more
> than one)
> - Different timeout values for early media and established calls
> (longer for early, shorter for established)
> - Play music on hold in early media state
> - Detect on-hold and disable timeouts (search different solution
> here)
> - Do not send media timeout if other sessions are active (video
> and audio)
> - In bridge mode asymmetric should not be always assumed
> - Cache played files instead of reading them from the disk all
> the time
>
>
> Also we are looking into new features (things that we can work
> together) :
> - better structuring between sessions and streams
> - Send timeout notifications over UDP
> - Force specific ports in reply, if possible
> - Failover support
> - Provide statistics per session (even ended) back to OpenSIPS
> - Restart persistent
> - Change learning period (possibly linked with on-hold media
> disable)
> - ICE support
> - SRTP to RTP conversion
>
> Definitly we can look into transcoding part too - what we did is for
> Sangoma cards (so HW transcoding, not SW).
>
>
>
> So, we will look into the new work you guys did on rtpproxy - to
> have a starting point for the future planning. After that, if you
> agree on having us contributing to the rtpproxy, we can get involved
> in planning and actual development.
>
> Best regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 20.06.2014 02:16, Jev Björsell wrote:
>> Hi Guys,
>>
>> Some updates on the rtpproxy project;
>>
>> We have now moved the rtpproxy project from sourceforge to github
>> http://github.com/sippy/rtpproxy
>>
>> This change should make the project more visibility & and
>> transparency. Please feel free to create Issues for feature
>> requests and bugs, and of course Pull Requests are appreciated! :)
>>
>> We have also moved the mailing list over to Google Groups:
>> https://groups.google.com/forum/#!forum/rtpproxy
>> <https://groups.google.com/forum/#%21forum/rtpproxy>
>>
>> We will do a maintenance release - version 1.3, and Max is busy
>> working on a 2.0 release, which has some significant improvements
>> to jitter characteristics, and performance.
>>
>> Best Regards,
>> -Jev
>>
>>
>>
>> On Mon, Jun 9, 2014 at 8:25 AM, Maxim Sobolev
>> <sobomax at sippysoft.com <mailto:sobomax at sippysoft.com>> wrote:
>>
>> Hey Bogdan, sorry for missing your message. The mail traffic
>> these days is insane, so it's hard to keep atop of all issues.
>>
>> We are working behind the scene on what would become rtpproxy
>> 2.0, the code is pretty stable and we have it deployed in like
>> 30-40 places. The main changes are in the timing loop, which
>> improves the jitter significantly and recently we've also
>> split UDP sending code into its own thread(s). That code is
>> available here: https://bitbucket.org/sippysoft/rtpproxy. It's
>> only tested to compile on FreeBSD, but it should not be
>> difficult to compile it on Linux. This basically pushes it to
>> the limits of what's possible to achieve with the standard
>> POSIX facilities. We've been able to push 16-core machine up
>> to 400KPPS in and 400KPPS out with it, all the way up to 90%
>> CPU, while the older version started choking at about 30%. Our
>> plan is to tie few loose ends and push it out to the official
>> repo as a basis for 2.0.
>>
>> Beyond 2.0, there is another project in progress that is using
>> novel netmap framework to overcome performance issues of the
>> traditional kernel-based socket API. This potentially would
>> allow us to increase capacity at least 5 times on the
>> comparable hardware. The framework itself is pretty low-level,
>> so I am working on a library that would allow it to be more
>> easily integrated into an app. The WiP code is here.
>> https://bitbucket.org/sobomax/libsinet.
>>
>> Another direction that we are going to explore is to add
>> transcoding support. We have 2 cards in our lab now and
>> setting up the devtesting system just today. I've heard that
>> you have done some work in this direction, so if you want to
>> share something with us, we would be very interested to look
>> at those patches.
>>
>> On the open-source side we plan to move the project into some
>> modern project management facility, the favorite being github.
>> My colleague Jev is driving this change.
>>
>> In general I don't mind giving you or anyone else from the
>> OpenSIPS team read-write access to repository if you feel like
>> integrating some of your patches.
>>
>>
>> On Mon, Apr 14, 2014 at 5:03 AM, Bogdan-Andrei Iancu
>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>> Hello Maxim,
>>
>> Long time, no talks, but I hope everything is fine on your
>> side.
>>
>> I'm reaching you in order to ask about your future plans
>> in regards to the rtpproxy project? We see no much
>> activity around it and other media relays are popping around.
>>
>> RTPP is an essential component for us, we invested a lot
>> of work, we have many patches (extensions) for it (which
>> we want to push to the public tree, but there is no answer
>> on this) and we are also looking for investing a lot into
>> big future plans (as adding more functionalities).
>>
>> Now, my question is - what is your commitment and
>> disponibility for the RTPP project ? depending on that we
>> what to re-position ourselves, as we do not want to waste
>> time and work on things which are out of control.
>>
>> Best regards,
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>>
>>
>> --
>> Maksym Sobolyev
>> Sippy Software, Inc.
>> Internet Telephony (VoIP) Experts
>> Tel (Canada): +1-778-783-0474 <tel:%2B1-778-783-0474>
>> Tel (Toll-Free): +1-855-747-7779 <tel:%2B1-855-747-7779>
>> Fax: +1-866-857-6942 <tel:%2B1-866-857-6942>
>> Web: http://www.sippysoft.com
>> MSN: sales at sippysoft.com <mailto:sales at sippysoft.com>
>> Skype: SippySoft
>>
>>
>
>
>
>
> --
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sales at sippysoft.com <mailto:sales at sippysoft.com>
> Skype: SippySoft
More information about the Users
mailing list