<div dir="ltr">For us, transcoding support, being able to fork rtcp to a reporting server (or even better, becoming an rtcp client), and (in a distant third) SRTP termination would be the big features we're looking for. We would love to be able to do something around the nathelper API/rtpproxy API to offload to a transcoder only when we need it, similar to OpenSIPS added sangoma support, only with rtpproxy. If the mechanism was added, we'd probably contribute to some codec translation tables (remember, g711 and ilbc are eerily similar in frame size). FreeSWITCH does it by converting everything down to a common binary format before transcode, which is how I'd envision this would work. Transcoding in software only is a huge value-add gain for us, because it allows us to continue with a software only solution and scale easier.<div>
<br></div><div>We engineer around losing an rtpproxy on the wire (which almost never happens), with a few strategies around re-INVITE, silence packet detection, etc. It's not perfect, but it's well within the SLA we'd present our end users and it's probably an area of the system where we get the least complaints. A dropped call every few weeks is beyond acceptable from the generation that's used to going from 4 bars to 0 in a subway tunnel.</div>
<div><br></div><div>And rtp_cluster has been great for us, solely for the ability to tag an instance as down and bleed sessions off of it before terminating it. The load balancing is on parity with the features added to the rtpproxy module via opensips, with exception of this: multiple opensips instances can talk to the same rtp_cluster, meaning that you get a distributed session state map can be highly available, instead of relying upon what's in memory with opensips. That's how we achieve the failover features that I think the community want added. Maybe adding rtpproxy session replication through the binary data interface recently introduced to opensips could help with some of this.</div>
<div><br></div><div>So yes, feature parity is important, but it's also important that we maintain reliable performance. I know Maxim has worked on some stuff around threading that has helped us move forward to better reliability with rtpp (separating command protocol from packet processing), so there's some progress there. The last time we did a comparison and made a decision between the two major entities, we just found rtpproxy to be much better performant at handling multiple sessions per instance, in the 50-60% better range. We can squeeze around 6000 established "sessions" (if you come from an eSBC world) on an m3.xlarge ec2 instance and not break a sweat.</div>
<div><br></div><div>Ultimately, I think it's good for all of the community to show that a project is in active development. I think it's a win for both sides, and discussions on where something is going are well warranted.</div>
<div><br></div><div>And this is coming from the SP with a capital V.<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 1:55 PM, <span dir="ltr"><<a href="mailto:ag@ag-projects.com" target="_blank">ag@ag-projects.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Guys,<div><br></div><div>All these softwares are mature with many years in service both for the media relays and the SIP part. They deal find with most of the expected failures, which is what the customers expect. For the un-expected failures, well the sky if the limit for optimising with infinite cost/benefit ratio. I personally did not hear my customers asking for any more resilience or scalability for the media relay component, so I stopped optimising long time ago.</div>
<div><br></div><div>A better question is where would OpenSIPS project go next, beyond optimisations, as the outside world does not stay still and the perception of some of my customers is that we are being left behind feature-wise.</div>
<div><br></div><div>Adrian</div><div><div class="h5"><div><br></div><div><div><div>On 13 Jun 2014, at 14:18, Bogdan-Andrei Iancu <<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>> wrote:</div>
<br><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<div><tt>Hi Maxim,<br>
<br>
It is good to know about the rtp_cluster, but aside simplifying
things, it does not bring any new functionality - the LB and
failover between RTPproxy nodes can be done now in OpenSIPS
module .<br>
The most challenging thing we are looking at is the ability to
move calls between different instances of RTPP (for HA
purposes)..or some restart persistence for the sessions -
without something like that it's very hard to deal with SW/HW
failures ; there are ways to go around for scheduled
stops/restarts (maintenance), but non for unexpected failures.
<br>
<br>
Thanks and Regards,<br>
</tt>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com/" target="_blank">http://www.opensips-solutions.com</a></pre>
On 13.06.2014 00:36, Maxim Sobolev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Brett, on the HA/carrier-grade side there is
little-advertized middle-layer component called "rtp_cluster",
which in essence is load-balancing, transparent dispatcher
that can be inserted in between some call-controlling
component like OpenSIPS or Sippy B2BUA and bunch of RTPP
instances running on the same or multiple nodes. From the
point of view of that OpenSIPS it's just another RTPP
instance.<br>
<br>
And it handles all logic necessary to load-balance incoming
requests between online instances plus it can handle dynamic
re-confiduration of the cluster and track individual nodes
going up and down. The code is pretty usable, we have it
deployed for several customers and it's being actively
developed as well. We have it working reliably controlling up
to 30-40 RTPP instances scattered over at least 5 nodes.<br>
<br>
<a href="http://sourceforge.net/p/sippy/sippy/ci/master/tree/rtp_cluster/" target="_blank">http://sourceforge.net/p/sippy/sippy/ci/master/tree/rtp_cluster/</a><br>
<br>
</div>
We have at least one pretty well known service provider whose
name starts with capital V using it in combination with OpenSIPS
to load balance RTP traffic via bunch of Amazon EC2 instances.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, May 27, 2014 at 6:52 AM, Brett
Nemeroff <span dir="ltr"><<a href="mailto:brett@nemeroff.com" target="_blank">brett@nemeroff.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Just wanted to add my 0.02 here..
<div><br>
</div>
<div>I totally agree with Bogdan. For the applications
where opensips + a RTP relay make sense, HA and
persistence are much more important. </div>
<div><br>
</div>
<div>WebRTC and ICE are kinda applications in of
themselves. And although these applications are going to
grow in popularity, the "legacy" needs for an RTP relay
are still massively prevalent in the space. A general
push towards "Carrier Grade", resiliency and redundancy
I think is much better for the project as a whole. </div>
<div><br>
</div>
<div>Not only that, consider that applications requiring
ICE or WebRTC will greatly benefit from HA /
persistence, but not so much the other way around :) </div>
<div><br>
</div>
<div>YMMV</div>
<span><font color="#888888">
<div>
<br>
</div>
<div>-Brett</div>
<div><br>
</div>
</font></span></div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, May 25, 2014 at 6:30
AM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div><tt>Hello,<br>
<br>
As always, the truth is in the middle.<br>
<br>
I agree RTPP is behind on certain things
(and this is why we want to do them), but on
the other hand it is a good platform with
other good features (missing on the other
relays). RTPP has better ability in
individually controlling the stream (audio
/video), ability to set timeouts and onhold
with no conflicts, ability to generates
events on timeout, more flexibility in
handling symmetric / asymmetric NATs,
ability to do media injection (playback),
ability to do call recording<br>
<br>
What neither mediaproxy, nor rtpengine have
is a mechanism for implementing RTP failover
(for ongoing calls) or restart persistence .
This is something we want to look into. I
would love to have ICE and WebRTC on my
media relay, for the HA and persistence are
more important I would say.<br>
<br>
Regards,<br>
</tt>
<div>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com/" target="_blank">http://www.opensips-solutions.com</a></pre>
</div>
<div>
<div> On <a href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014
01</a>:59, Muhammad Shahzad Shafi wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div><p>To be honest, i have stopped using
rtpproxy for over 2 years now. It is not
evolving as fast as it should be,
specially in the context of ICE and
WebRTC technologies.</p><p>I would like to suggest that opensips
team should consider adding support for
rtpengine from SIPWise,</p><p><a href="https://github.com/sipwise/rtpengine" target="_blank">https://github.com/sipwise/rtpengine</a></p><p>For now mediaproxy from AG Projects is
the only good choice for handling media
in opensips with ICE support (though it
still lacks WebRTC features).</p><p>Thank you.</p><div> <br></div><p>On 2014-05-23 14:55, Bogdan-Andrei
Iancu wrote:</p>
<blockquote type="cite" style="padding-left:5px;border-left:#1010ff 2px solid;margin-left:5px;width:100%"><tt>Going
for a public exposure on this question
to Maxim, maybe we will get an answer
here.<br>
<br>
</tt>
<div><br>
-------- Original Message --------
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">Subject:</th>
<td>RTPproxy project</td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">Date:</th>
<td>Mon, 14 Apr 2014 15:03:31
+0300</td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">From:</th>
<td>Bogdan-Andrei Iancu</td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">To:</th>
<td>Maxim Sobolev</td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">CC:</th>
<td>Razvan Crainea</td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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
<a href="http://www.opensips-solutions.com/" target="_blank">http://www.opensips-solutions.com</a>
</pre>
</div>
</blockquote>
<div>
<pre>--
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85</a>
MSN: <a href="mailto:shari_786pk@hotmail.com" target="_blank">shari_786pk@hotmail.com</a>
Email: <a href="mailto:shaheryarkh@googlemail.com" target="_blank">shaheryarkh@googlemail.com</a></pre>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.opensips.org" target="_blank">Devel@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div dir="ltr">Maksym Sobolyev<br>
Sippy Software, Inc.<br>
Internet Telephony (VoIP) Experts<br>
Tel (Canada): <a href="tel:%2B1-778-783-0474" value="+17787830474" target="_blank">+1-778-783-0474</a><br>
Tel (Toll-Free): <a href="tel:%2B1-855-747-7779" value="+18557477779" target="_blank">+1-855-747-7779</a><br>
Fax: <a href="tel:%2B1-866-857-6942" value="+18668576942" target="_blank">+1-866-857-6942</a><br>
Web: <a href="http://www.sippysoft.com/" target="_blank">http://www.sippysoft.com</a><br>
MSN: <a href="mailto:sales@sippysoft.com" target="_blank">sales@sippysoft.com</a><br>
Skype: SippySoft<br>
</div>
</div>
</blockquote>
<br>
</div>
_______________________________________________<br>Devel mailing list<br><a href="mailto:Devel@lists.opensips.org" target="_blank">Devel@lists.opensips.org</a><br><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>