<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>Hey Bobby,<br>
<br>
Thank you for the your input.<br>
<br>
I have also a long list of goodies to be added to a rtpproxy
(fixes in multi-stream handling, new features, etc) and this is
why I started this discussion around the RTPproxy - I wanted to
understand what are the plans for the future.<br>
<br>
To be honest I was not aware of the latest work Maxim did on
rtpproxy (it is not so transparent via the rtpproxy.org site or
mailing lists) - but it looks interesting and before doing any
steps further I will need to look into that.<br>
<br>
As it is not clear for me, could you detail a bit on:<br>
<br>
"</tt><tt>multiple opensips instances can talk to the same
rtp_cluster, meaning that you get a distributed session state
map can be highly available"<br>
What do you mean by "</tt><tt><tt>session state map can be
highly available</tt>" ?<br>
<br>
Also , on :<br>
"</tt><tt> Maybe adding rtpproxy session replication through the
binary data interface recently introduced to opensips could help
with some of this"<br>
You mean to replicate the info on sessions between multiple
rtpproxy instances ?<br>
<br>
<br>
Thanks and regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
On 14.06.2014 16:17, Bobby Smith wrote:<br>
</div>
<blockquote
cite="mid:CAJQeEguLMNBH7LqSXJQABsc3uakx48eLdkrtyQ6ThumPwhR+sg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" 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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true" href="http://www.opensips-solutions.com/" target="_blank">http://www.opensips-solutions.com</a></pre>
</div>
<div>
<div> On <a
moz-do-not-send="true"
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
moz-do-not-send="true"
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="nowrap" valign="BASELINE">Subject:</th>
<td>RTPproxy
project</td>
</tr>
<tr>
<th
align="RIGHT"
nowrap="nowrap" valign="BASELINE">Date:</th>
<td>Mon, 14
Apr 2014
15:03:31 +0300</td>
</tr>
<tr>
<th
align="RIGHT"
nowrap="nowrap" valign="BASELINE">From:</th>
<td>Bogdan-Andrei
Iancu</td>
</tr>
<tr>
<th
align="RIGHT"
nowrap="nowrap" valign="BASELINE">To:</th>
<td>Maxim
Sobolev</td>
</tr>
<tr>
<th
align="RIGHT"
nowrap="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 moz-do-not-send="true" 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 moz-do-not-send="true" href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85</a>
MSN: <a moz-do-not-send="true" href="mailto:shari_786pk@hotmail.com" target="_blank">shari_786pk@hotmail.com</a>
Email: <a moz-do-not-send="true" href="mailto:shaheryarkh@googlemail.com" target="_blank">shaheryarkh@googlemail.com</a></pre>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Users mailing list
<a moz-do-not-send="true" href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org"
target="_blank">Users@lists.opensips.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Devel@lists.opensips.org"
target="_blank">Devel@lists.opensips.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="tel:%2B1-778-783-0474"
value="+17787830474" target="_blank">+1-778-783-0474</a><br>
Tel (Toll-Free): <a
moz-do-not-send="true"
href="tel:%2B1-855-747-7779"
value="+18557477779" target="_blank">+1-855-747-7779</a><br>
Fax: <a moz-do-not-send="true"
href="tel:%2B1-866-857-6942"
value="+18668576942" target="_blank">+1-866-857-6942</a><br>
Web: <a moz-do-not-send="true"
href="http://www.sippysoft.com/"
target="_blank">http://www.sippysoft.com</a><br>
MSN: <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Devel@lists.opensips.org"
target="_blank">Devel@lists.opensips.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>