Hey Bobby,
Thank you for the your input.
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.
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.
As it is not clear for me, could you detail a bit on:
"multiple opensips instances can talk to the same rtp_cluster, meaning
that you get a distributed session state map can be highly available"
What do you mean by "session state map can be highly available" ?
Also , on :
"Maybe adding rtpproxy session replication through the binary data
interface recently introduced to opensips could help with some of this"
You mean to replicate the info on sessions between multiple rtpproxy
instances ?
Thanks and regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 14.06.2014 16:17, Bobby Smith wrote:
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.
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.
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.
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.
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.
And this is coming from the SP with a capital V.
On Fri, Jun 13, 2014 at 1:55 PM, <[email protected]
<mailto:[email protected]>> wrote:
Guys,
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.
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.
Adrian
On 13 Jun 2014, at 14:18, Bogdan-Andrei Iancu <[email protected]
<mailto:[email protected]>> wrote:
Hi Maxim,
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 .
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.
Thanks and Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com/>
On 13.06.2014 00:36, Maxim Sobolev wrote:
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.
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.
http://sourceforge.net/p/sippy/sippy/ci/master/tree/rtp_cluster/
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.
On Tue, May 27, 2014 at 6:52 AM, Brett Nemeroff
<[email protected] <mailto:[email protected]>> wrote:
Just wanted to add my 0.02 here..
I totally agree with Bogdan. For the applications where
opensips + a RTP relay make sense, HA and persistence are
much more important.
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.
Not only that, consider that applications requiring ICE or
WebRTC will greatly benefit from HA / persistence, but not
so much the other way around :)
YMMV
-Brett
On Sun, May 25, 2014 at 6:30 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hello,
As always, the truth is in the middle.
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
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.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
<http://www.opensips-solutions.com/>
On 24.05.2014 01 <tel:24.05.2014%2001>:59, Muhammad
Shahzad Shafi wrote:
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.
I would like to suggest that opensips team should
consider adding support for rtpengine from SIPWise,
https://github.com/sipwise/rtpengine
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).
Thank you.
On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:
Going for a public exposure on this question to Maxim,
maybe we will get an answer here.
-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea
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/>
--
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell:+49 176 99 83 10 85 <tel:%2B49%20176%2099%2083%2010%2085>
MSN:[email protected] <mailto:[email protected]>
Email:[email protected]
<mailto:[email protected]>
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Devel mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
--
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 <http://www.sippysoft.com/>
MSN: [email protected] <mailto:[email protected]>
Skype: SippySoft
_______________________________________________
Devel mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
