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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
Skype: SippySoft
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
