If you can adapt it to rtpp_2_0 that would be great. This is our latest
production code and it's pretty much superset of the 1.x feature and
performance wise. I've just pushed some fixes to get it compile cleanly
on Ubuntu using just GNU make.
Are you guys registered on github? I've been trying to add you to the
repository ACL list but could not find anyone. Jev is off for few days,
but he should be back tomorrow to finish migration of the website etc.
Thanks!
-Maxim
On Fri, Jun 27, 2014 at 7:51 AM, Răzvan Crainea <raz...@opensips.org
<mailto:raz...@opensips.org>> wrote:
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 <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
<bog...@opensips.org <mailto:bog...@opensips.org>
<mailto:bog...@opensips.org <mailto:bog...@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
<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
<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/#!forum/rtpproxy>
<https://groups.google.com/__forum/#%21forum/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
<sobo...@sippysoft.com <mailto:sobo...@sippysoft.com>
<mailto:sobo...@sippysoft.com
<mailto:sobo...@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
<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
<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
<bog...@opensips.org <mailto:bog...@opensips.org>
<mailto:bog...@opensips.org <mailto:bog...@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
<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:%2B1-778-783-0474>
Tel (Toll-Free): +1-855-747-7779
<tel:%2B1-855-747-7779> <tel:%2B1-855-747-7779>
Fax: +1-866-857-6942 <tel:%2B1-866-857-6942>
<tel:%2B1-866-857-6942>
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
<mailto:sa...@sippysoft.com> <mailto:sa...@sippysoft.com
<mailto:sa...@sippysoft.com>>
Skype: SippySoft
--
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: sa...@sippysoft.com <mailto:sa...@sippysoft.com>
<mailto:sa...@sippysoft.com <mailto:sa...@sippysoft.com>>
Skype: SippySoft
