Hi,
What is difference between modules rtpproxy and rtpengine?
Best regards.
On 10/17/2016 02:29 PM, Rodrigo Moreira wrote:
What is difference between modules rtpproxy and rtpengine?
rtpproxy is a userspace process which, historically, has a relatively limited call throughput capacity (maybe a few hundred calls), though this might be addressed to some degree in rtpproxy 2.0. Nevertheless, it has been commonly used and well supported in the *SER family for long time.
RTPEngine is a newer initiative from Sipwise, and uses kernel-mode forwarding to achieve close to on-the-wire RTP forwarding speeds. It can do 10,000+ concurrent bidirectional RTP streams. It also has lots of other features which can be useful in, for example, running an RTP relay in 1:1 NAT environments such as AWS, or in enabling WebRTC.
However, it is a bit more complicated to set up than vanilla rtpproxy. Not much more, though.
-- Alex
Alex, with all due respect, things you said about rtpproxy capacity is somewhat outdated and misleading. We have some nodes in the field, that handle 5,000-6,000 rtp sessions in peak. Those are running 6 rtpproxy instances, 1,000 sessions each. 2-3 year old CPUs, 12 cores in total.
We also have an open source solution called rtp_cluster, which allows building larger scale deployments, for at least up to 50,000 bidirectional streams using multiple nodes running rtpproxy. Available here https://github.com/sippy/rtp_cluster. You are also welcome to check our talk last summer at the opensips devsummit in Austin where we gave it some limelight.
So you are off by two orders of magnitude roughly with regards to the capacity. :)
And yes, we've been happily running large deployments at AWS for at least 6 years now.
Rodrigo, speaking about your original question, I could not tell much about rtpengine due to a lack of practical experience with it. But from what I read on its website it seems to be logical continuation of the mediaproxy package packed with some cutting edge sexy features.
In a nutshell rtpproxy and mediaproxy/rtpengine are just two independently developed pieces of software, doing somewhat similar function. What would work in your particular setting depends on your requirements and constraints.
Here at Sippy Labs we focus on stability, compatibility and portability for a predominantly regular audio traffic.
We also have a test suite that check compatibility of the latest production and development versions of the rtpproxy against array of different SIP engines, including Kamailio. https://travis-ci.org/sippy/voiptests
So with rtpproxy you are not locked in into single SIP engine, you can mix and match to fit your particular goal.
And yes, last but not least, all our code is BSD licensed, so you can build you proprietary box that uses it.
Hope it helps.
-Max
On Oct 17, 2016 11:33 AM, "Alex Balashov" abalashov@evaristesys.com wrote:
On 10/17/2016 02:29 PM, Rodrigo Moreira wrote:
What is difference between modules rtpproxy and rtpengine?
rtpproxy is a userspace process which, historically, has a relatively limited call throughput capacity (maybe a few hundred calls), though this might be addressed to some degree in rtpproxy 2.0. Nevertheless, it has been commonly used and well supported in the *SER family for long time.
RTPEngine is a newer initiative from Sipwise, and uses kernel-mode forwarding to achieve close to on-the-wire RTP forwarding speeds. It can do 10,000+ concurrent bidirectional RTP streams. It also has lots of other features which can be useful in, for example, running an RTP relay in 1:1 NAT environments such as AWS, or in enabling WebRTC.
However, it is a bit more complicated to set up than vanilla rtpproxy. Not much more, though.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Maxim,
Duly noted! I certainly did not intend to mislead anyone or to be disingenuous; I gave information that was, to the best of my knowledge, true. I appreciate your followup and clarification, which certainly is useful for my own knowledge as well!
My sincere apologies...
-- Alex
On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev sobomax@sippysoft.com wrote:
Alex, with all due respect, things you said about rtpproxy capacity is somewhat outdated and misleading. We have some nodes in the field, that handle 5,000-6,000 rtp sessions in peak. Those are running 6 rtpproxy instances, 1,000 sessions each. 2-3 year old CPUs, 12 cores in total.
We also have an open source solution called rtp_cluster, which allows building larger scale deployments, for at least up to 50,000 bidirectional streams using multiple nodes running rtpproxy. Available here https://github.com/sippy/rtp_cluster. You are also welcome to check our talk last summer at the opensips devsummit in Austin where we gave it some limelight.
So you are off by two orders of magnitude roughly with regards to the capacity. :)
And yes, we've been happily running large deployments at AWS for at least 6 years now.
Rodrigo, speaking about your original question, I could not tell much about rtpengine due to a lack of practical experience with it. But from what I read on its website it seems to be logical continuation of the mediaproxy package packed with some cutting edge sexy features.
In a nutshell rtpproxy and mediaproxy/rtpengine are just two independently developed pieces of software, doing somewhat similar function. What would work in your particular setting depends on your requirements and constraints.
Here at Sippy Labs we focus on stability, compatibility and portability for a predominantly regular audio traffic.
We also have a test suite that check compatibility of the latest production and development versions of the rtpproxy against array of different SIP engines, including Kamailio. https://travis-ci.org/sippy/voiptests
So with rtpproxy you are not locked in into single SIP engine, you can mix and match to fit your particular goal.
And yes, last but not least, all our code is BSD licensed, so you can build you proprietary box that uses it.
Hope it helps.
-Max
On Oct 17, 2016 11:33 AM, "Alex Balashov" abalashov@evaristesys.com wrote:
On 10/17/2016 02:29 PM, Rodrigo Moreira wrote:
What is difference between modules rtpproxy and rtpengine?
rtpproxy is a userspace process which, historically, has a relatively limited call throughput capacity (maybe a few hundred calls), though
this
might be addressed to some degree in rtpproxy 2.0. Nevertheless, it
has
been commonly used and well supported in the *SER family for long
time.
RTPEngine is a newer initiative from Sipwise, and uses kernel-mode forwarding to achieve close to on-the-wire RTP forwarding speeds. It
can do
10,000+ concurrent bidirectional RTP streams. It also has lots of
other
features which can be useful in, for example, running an RTP relay in
1:1
NAT environments such as AWS, or in enabling WebRTC.
However, it is a bit more complicated to set up than vanilla
rtpproxy. Not
much more, though.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
Alex, no problem. Nobody knows everything. :)
-Max
On Wed, Oct 19, 2016 at 12:35 AM, Alex Balashov abalashov@evaristesys.com wrote:
Hi Maxim,
Duly noted! I certainly did not intend to mislead anyone or to be disingenuous; I gave information that was, to the best of my knowledge, true. I appreciate your followup and clarification, which certainly is useful for my own knowledge as well!
My sincere apologies...
-- Alex
On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev sobomax@sippysoft.com wrote:
Alex, with all due respect, things you said about rtpproxy capacity is somewhat outdated and misleading. We have some nodes in the field, that handle 5,000-6,000 rtp sessions in peak. Those are running 6 rtpproxy instances, 1,000 sessions each. 2-3 year old CPUs, 12 cores in total.
We also have an open source solution called rtp_cluster, which allows building larger scale deployments, for at least up to 50,000 bidirectional streams using multiple nodes running rtpproxy. Available here https://github.com/sippy/rtp_cluster. You are also welcome to check our talk last summer at the opensips devsummit in Austin where we gave it some limelight.
So you are off by two orders of magnitude roughly with regards to the capacity. :)
And yes, we've been happily running large deployments at AWS for at least 6 years now.
Rodrigo, speaking about your original question, I could not tell much about rtpengine due to a lack of practical experience with it. But from what I read on its website it seems to be logical continuation of the mediaproxy package packed with some cutting edge sexy features.
In a nutshell rtpproxy and mediaproxy/rtpengine are just two independently developed pieces of software, doing somewhat similar function. What would work in your particular setting depends on your requirements and constraints.
Here at Sippy Labs we focus on stability, compatibility and portability for a predominantly regular audio traffic.
We also have a test suite that check compatibility of the latest production and development versions of the rtpproxy against array of different SIP engines, including Kamailio. https://travis-ci.org/sippy/voiptests
So with rtpproxy you are not locked in into single SIP engine, you can mix and match to fit your particular goal.
And yes, last but not least, all our code is BSD licensed, so you can build you proprietary box that uses it.
Hope it helps.
-Max
On Oct 17, 2016 11:33 AM, "Alex Balashov" abalashov@evaristesys.com wrote:
On 10/17/2016 02:29 PM, Rodrigo Moreira wrote:
What is difference between modules rtpproxy and rtpengine?
rtpproxy is a userspace process which, historically, has a relatively limited call throughput capacity (maybe a few hundred calls), though
this
might be addressed to some degree in rtpproxy 2.0. Nevertheless, it
has
been commonly used and well supported in the *SER family for long
time.
RTPEngine is a newer initiative from Sipwise, and uses kernel-mode forwarding to achieve close to on-the-wire RTP forwarding speeds. It
can do
10,000+ concurrent bidirectional RTP streams. It also has lots of
other
features which can be useful in, for example, running an RTP relay in
1:1
NAT environments such as AWS, or in enabling WebRTC.
However, it is a bit more complicated to set up than vanilla
rtpproxy. Not
much more, though.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello Maxim,
given the discussion here, I would like to get some updates for myself regarding 2.0 in terms of capacity and other stuff.
I was using rtpproxy 1.x with kamailio doing load balancing across many instances of rtpproxy. I was using 1000 streams as estimation for one instance and I see it's what you mentioned as well. Is it the recommended (or the good) value for 2.0? Most of deployments still use v1.2, given it's presence in stable/old OS distros.
It's any relevant architectural change in 2.0? Like more threads used by the app or other I/O refactoring? Iirc, v1.x uses one for control commands?
I wanted to report at some point, with v1.x, on some centos (iirc), when there was no active call, rtpproxy was eating a lot of cpu. With a call (or more) going on, the cpu went to normal. I think it was like waiting for I/O was using the cpu. Switching to debian was a solution at that moment, so might not be rtpproxy, but I am wondering if you or anyone else faced same issue. Also, if I am not wrong, the person that reported to me said that 2.0 didn't revealed the same behaviour.
Cheers, Daniel
On 19/10/16 09:46, Maxim Sobolev wrote:
Alex, no problem. Nobody knows everything. :)
-Max
On Wed, Oct 19, 2016 at 12:35 AM, Alex Balashov <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
Hi Maxim, Duly noted! I certainly did not intend to mislead anyone or to be disingenuous; I gave information that was, to the best of my knowledge, true. I appreciate your followup and clarification, which certainly is useful for my own knowledge as well! My sincere apologies... -- Alex On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev <sobomax@sippysoft.com <mailto:sobomax@sippysoft.com>> wrote: >Alex, with all due respect, things you said about rtpproxy capacity is >somewhat outdated and misleading. We have some nodes in the field, that >handle 5,000-6,000 rtp sessions in peak. Those are running 6 rtpproxy >instances, 1,000 sessions each. 2-3 year old CPUs, 12 cores in total. > >We also have an open source solution called rtp_cluster, which allows >building larger scale deployments, for at least up to 50,000 >bidirectional >streams using multiple nodes running rtpproxy. Available here >https://github.com/sippy/rtp_cluster <https://github.com/sippy/rtp_cluster>. You are also welcome to check our >talk last summer at the opensips devsummit in Austin where we gave it >some >limelight. > >So you are off by two orders of magnitude roughly with regards to the >capacity. :) > >And yes, we've been happily running large deployments at AWS for at >least 6 >years now. > >Rodrigo, speaking about your original question, I could not tell much >about >rtpengine due to a lack of practical experience with it. But from what >I >read on its website it seems to be logical continuation of the >mediaproxy >package packed with some cutting edge sexy features. > >In a nutshell rtpproxy and mediaproxy/rtpengine are just two >independently >developed pieces of software, doing somewhat similar function. What >would >work in your particular setting depends on your requirements and >constraints. > >Here at Sippy Labs we focus on stability, compatibility and portability >for >a predominantly regular audio traffic. > >We also have a test suite that check compatibility of the latest >production >and development versions of the rtpproxy against array of different SIP >engines, including Kamailio. https://travis-ci.org/sippy/voiptests <https://travis-ci.org/sippy/voiptests> > >So with rtpproxy you are not locked in into single SIP engine, you can >mix >and match to fit your particular goal. > >And yes, last but not least, all our code is BSD licensed, so you can >build >you proprietary box that uses it. > >Hope it helps. > >-Max > >On Oct 17, 2016 11:33 AM, "Alex Balashov" <abalashov@evaristesys.com <mailto:abalashov@evaristesys.com>> >wrote: > >> On 10/17/2016 02:29 PM, Rodrigo Moreira wrote: >> >> What is difference between modules rtpproxy and rtpengine? >>> >> >> rtpproxy is a userspace process which, historically, has a relatively >> limited call throughput capacity (maybe a few hundred calls), though >this >> might be addressed to some degree in rtpproxy 2.0. Nevertheless, it >has >> been commonly used and well supported in the *SER family for long >time. >> >> RTPEngine is a newer initiative from Sipwise, and uses kernel-mode >> forwarding to achieve close to on-the-wire RTP forwarding speeds. It >can do >> 10,000+ concurrent bidirectional RTP streams. It also has lots of >other >> features which can be useful in, for example, running an RTP relay in >1:1 >> NAT environments such as AWS, or in enabling WebRTC. >> >> However, it is a bit more complicated to set up than vanilla >rtpproxy. Not >> much more, though. >> >> -- Alex >> >> -- >> Alex Balashov | Principal | Evariste Systems LLC >> >> Tel: +1-706-510-6800 <tel:%2B1-706-510-6800> (direct) / +1-800-250-5920 <tel:%2B1-800-250-5920> (toll-free) >> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >list >> sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> -- Alex -- Principal, Evariste Systems LLC (www.evaristesys.com <http://www.evaristesys.com>) Sent from my Google Nexus. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>-- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com mailto:sales@sippysoft.com Skype: SippySoft
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi guys,
In addition to this interesting and useful thread, what is the best way to implement media session recovery, for example in Active/Passive HA scenario? I know that it is possible with rtpengine (redis db), is it possible with rtpproxy?
Thanks, Arsen.
On Wed, Oct 19, 2016 at 11:19 AM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello Maxim, given the discussion here, I would like to get some updates for myself regarding 2.0 in terms of capacity and other stuff.
I was using rtpproxy 1.x with kamailio doing load balancing across many instances of rtpproxy. I was using 1000 streams as estimation for one instance and I see it's what you mentioned as well. Is it the recommended (or the good) value for 2.0? Most of deployments still use v1.2, given it's presence in stable/old OS distros.
It's any relevant architectural change in 2.0? Like more threads used by the app or other I/O refactoring? Iirc, v1.x uses one for control commands?
I wanted to report at some point, with v1.x, on some centos (iirc), when there was no active call, rtpproxy was eating a lot of cpu. With a call (or more) going on, the cpu went to normal. I think it was like waiting for I/O was using the cpu. Switching to debian was a solution at that moment, so might not be rtpproxy, but I am wondering if you or anyone else faced same issue. Also, if I am not wrong, the person that reported to me said that 2.0 didn't revealed the same behaviour.
Cheers, Daniel
On 19/10/16 09:46, Maxim Sobolev wrote:
Alex, no problem. Nobody knows everything. :)
-Max
On Wed, Oct 19, 2016 at 12:35 AM, Alex Balashov <abalashov@evaristesys.com
wrote:
Hi Maxim,
Duly noted! I certainly did not intend to mislead anyone or to be disingenuous; I gave information that was, to the best of my knowledge, true. I appreciate your followup and clarification, which certainly is useful for my own knowledge as well!
My sincere apologies...
-- Alex
On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev sobomax@sippysoft.com wrote:
Alex, with all due respect, things you said about rtpproxy capacity is somewhat outdated and misleading. We have some nodes in the field, that handle 5,000-6,000 rtp sessions in peak. Those are running 6 rtpproxy instances, 1,000 sessions each. 2-3 year old CPUs, 12 cores in total.
We also have an open source solution called rtp_cluster, which allows building larger scale deployments, for at least up to 50,000 bidirectional streams using multiple nodes running rtpproxy. Available here https://github.com/sippy/rtp_cluster. You are also welcome to check our talk last summer at the opensips devsummit in Austin where we gave it some limelight.
So you are off by two orders of magnitude roughly with regards to the capacity. :)
And yes, we've been happily running large deployments at AWS for at least 6 years now.
Rodrigo, speaking about your original question, I could not tell much about rtpengine due to a lack of practical experience with it. But from what I read on its website it seems to be logical continuation of the mediaproxy package packed with some cutting edge sexy features.
In a nutshell rtpproxy and mediaproxy/rtpengine are just two independently developed pieces of software, doing somewhat similar function. What would work in your particular setting depends on your requirements and constraints.
Here at Sippy Labs we focus on stability, compatibility and portability for a predominantly regular audio traffic.
We also have a test suite that check compatibility of the latest production and development versions of the rtpproxy against array of different SIP engines, including Kamailio. https://travis-ci.org/sippy/voiptests
So with rtpproxy you are not locked in into single SIP engine, you can mix and match to fit your particular goal.
And yes, last but not least, all our code is BSD licensed, so you can build you proprietary box that uses it.
Hope it helps.
-Max
On Oct 17, 2016 11:33 AM, "Alex Balashov" abalashov@evaristesys.com wrote:
On 10/17/2016 02:29 PM, Rodrigo Moreira wrote:
What is difference between modules rtpproxy and rtpengine?
rtpproxy is a userspace process which, historically, has a relatively limited call throughput capacity (maybe a few hundred calls), though
this
might be addressed to some degree in rtpproxy 2.0. Nevertheless, it
has
been commonly used and well supported in the *SER family for long
time.
RTPEngine is a newer initiative from Sipwise, and uses kernel-mode forwarding to achieve close to on-the-wire RTP forwarding speeds. It
can do
10,000+ concurrent bidirectional RTP streams. It also has lots of
other
features which can be useful in, for example, running an RTP relay in
1:1
NAT environments such as AWS, or in enabling WebRTC.
However, it is a bit more complicated to set up than vanilla
rtpproxy. Not
much more, though.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Arsen, there is no readily-made solution with rtpproxy unfortunately for that. Some time around 1.0 times circa 2007-2009, somebody submitted a very rough patch to implement master/hot-standby scenario, but the patch was not production-ready back then and the contributor was not available to refine it further, so it ended up stashed somewhere on the branch in git. I'd be happy to say we are working on that, but our resources are limited and priority is to get features like SRTP, trans-coding and video support. As always, pull requests/patches are welcome. With 2.x code is much more modular, so it should be easier to get something like that working.
-Max
On Wed, Oct 19, 2016 at 3:55 AM, Arsen arsen.semionov@gmail.com wrote:
Hi guys,
In addition to this interesting and useful thread, what is the best way to implement media session recovery, for example in Active/Passive HA scenario? I know that it is possible with rtpengine (redis db), is it possible with rtpproxy?
My personal opinion on this is that it should be very low-priority. It's one of those problems that takes 99% effort for 1% marginal results, and even then, rather imperfect ones.
For almost any service provider, having a media relay while calls are on it is not the worst possible problem—certainly not when set against the expense and complexity of solving it. If the calls are properly distributed across an array of media servers, it shouldn't be a total service-impacting event for anyone, anyway.
On 10/19/2016 10:54 AM, Maxim Sobolev wrote:
Arsen, there is no readily-made solution with rtpproxy unfortunately for that. Some time around 1.0 times circa 2007-2009, somebody submitted a very rough patch to implement master/hot-standby scenario, but the patch was not production-ready back then and the contributor was not available to refine it further, so it ended up stashed somewhere on the branch in git. I'd be happy to say we are working on that, but our resources are limited and priority is to get features like SRTP, trans-coding and video support. As always, pull requests/patches are welcome. With 2.x code is much more modular, so it should be easier to get something like that working.
-Max
On Wed, Oct 19, 2016 at 3:55 AM, Arsen <arsen.semionov@gmail.com mailto:arsen.semionov@gmail.com> wrote:
Hi guys, In addition to this interesting and useful thread, what is the best way to implement media session recovery, for example in Active/Passive HA scenario? I know that it is possible with rtpengine (redis db), is it possible with rtpproxy?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel, thank you for your interest. Yes, there were many architectural changes between 1.x and 2.0. The most noticeable is that we've decoupled I/O from the control channel handling and also split I/O into two threads, one for poll/receive and the second one for the sending. We've also refactored our scheduling algorithms to provide much better performance jitter-wise. There are more threads than two in 2.0, but most of them are not using much CPU if any. As such as a rule of thumb you'd want to run max one rtpproxy per two CPU cores with 2.0, up from one instance per core with 1.x. Yes, 1000 bi-directional streams is realistic value, at least in a situation when you have multiple rtpproxy instances running concurrently on the box which creates non-trivial overhead in terms of system calls contention. You can probably go higher than 1,000 if you have single instance and/or latest CPU. There is detailed 2.0 release notes document available at our github project.
In terms of cpu usage while idle, I am not aware of any major issues with 2.0. That being said, rtpproxy is known to be somewhat wasteful in general while running with no load, it still does 200 poll's a second and that tends to consume <1% of single core CPU per running instance. I've got some ideas on how to fix it, but that would not be available until 2.2 is out somewhere in 2017. We are working on getting 2.1 out, which would include new plain text accounting module more refinements and improvements. Among those, we've added experimental support for running control channel over TCPv4 and TCPv6 sockets, still something that needs to be integrated back into all children of SER.
We are aware that packaging is somewhat behind in some distros*. However, we ourselves and most of our biggest customers roll their own builds anyway, so we just rely on the community to take care of. That being said, we always welcome pull requests to get stuff that might help others to package it on FooLinux.
Please don't hesitate to ask if something is unclear or if you have more questions. Thanks!
-Max *) Sometimes I get a feeling that there are too many to chose from these days, but oh well... :)
On Wed, Oct 19, 2016 at 1:19 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello Maxim, given the discussion here, I would like to get some updates for myself regarding 2.0 in terms of capacity and other stuff.
I was using rtpproxy 1.x with kamailio doing load balancing across many instances of rtpproxy. I was using 1000 streams as estimation for one instance and I see it's what you mentioned as well. Is it the recommended (or the good) value for 2.0? Most of deployments still use v1.2, given it's presence in stable/old OS distros.
It's any relevant architectural change in 2.0? Like more threads used by the app or other I/O refactoring? Iirc, v1.x uses one for control commands?
I wanted to report at some point, with v1.x, on some centos (iirc), when there was no active call, rtpproxy was eating a lot of cpu. With a call (or more) going on, the cpu went to normal. I think it was like waiting for I/O was using the cpu. Switching to debian was a solution at that moment, so might not be rtpproxy, but I am wondering if you or anyone else faced same issue. Also, if I am not wrong, the person that reported to me said that 2.0 didn't revealed the same behaviour.
Cheers, Daniel
On 19/10/16 09:46, Maxim Sobolev wrote:
Alex, no problem. Nobody knows everything. :)
-Max
On Wed, Oct 19, 2016 at 12:35 AM, Alex Balashov <abalashov@evaristesys.com
wrote:
Hi Maxim,
Duly noted! I certainly did not intend to mislead anyone or to be disingenuous; I gave information that was, to the best of my knowledge, true. I appreciate your followup and clarification, which certainly is useful for my own knowledge as well!
My sincere apologies...
-- Alex
On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev sobomax@sippysoft.com wrote:
Alex, with all due respect, things you said about rtpproxy capacity is somewhat outdated and misleading. We have some nodes in the field, that handle 5,000-6,000 rtp sessions in peak. Those are running 6 rtpproxy instances, 1,000 sessions each. 2-3 year old CPUs, 12 cores in total.
We also have an open source solution called rtp_cluster, which allows building larger scale deployments, for at least up to 50,000 bidirectional streams using multiple nodes running rtpproxy. Available here https://github.com/sippy/rtp_cluster. You are also welcome to check our talk last summer at the opensips devsummit in Austin where we gave it some limelight.
So you are off by two orders of magnitude roughly with regards to the capacity. :)
And yes, we've been happily running large deployments at AWS for at least 6 years now.
Rodrigo, speaking about your original question, I could not tell much about rtpengine due to a lack of practical experience with it. But from what I read on its website it seems to be logical continuation of the mediaproxy package packed with some cutting edge sexy features.
In a nutshell rtpproxy and mediaproxy/rtpengine are just two independently developed pieces of software, doing somewhat similar function. What would work in your particular setting depends on your requirements and constraints.
Here at Sippy Labs we focus on stability, compatibility and portability for a predominantly regular audio traffic.
We also have a test suite that check compatibility of the latest production and development versions of the rtpproxy against array of different SIP engines, including Kamailio. https://travis-ci.org/sippy/voiptests
So with rtpproxy you are not locked in into single SIP engine, you can mix and match to fit your particular goal.
And yes, last but not least, all our code is BSD licensed, so you can build you proprietary box that uses it.
Hope it helps.
-Max
On Oct 17, 2016 11:33 AM, "Alex Balashov" abalashov@evaristesys.com wrote:
On 10/17/2016 02:29 PM, Rodrigo Moreira wrote:
What is difference between modules rtpproxy and rtpengine?
rtpproxy is a userspace process which, historically, has a relatively limited call throughput capacity (maybe a few hundred calls), though
this
might be addressed to some degree in rtpproxy 2.0. Nevertheless, it
has
been commonly used and well supported in the *SER family for long
time.
RTPEngine is a newer initiative from Sipwise, and uses kernel-mode forwarding to achieve close to on-the-wire RTP forwarding speeds. It
can do
10,000+ concurrent bidirectional RTP streams. It also has lots of
other
features which can be useful in, for example, running an RTP relay in
1:1
NAT environments such as AWS, or in enabling WebRTC.
However, it is a bit more complicated to set up than vanilla
rtpproxy. Not
much more, though.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Just a little comment on the numbers that I've thrown out earlier today. Those are probably somewhat pessimistic, with some creative tuneup you can probably go much higher. But we also constrained by some other considerations (i.e. running fully redundant network connection with FEC, full firewall etc, custom OS), so those are what we get.
Also, I wanted to point to the list, speaking about number of sessions is pretty much pointless, as the main thing that keeps us busy is packet per second rate. Since same 10,000 sessions might translate to as much as half of PPS rate if use 10ms ptype versus 20ms ptype. Our limit at this point of time is some 450k PPS in and 450k PPS out, 16 cores, FreeBSD 10.3, which could be either 4.5k sessions with 10ms packets or 9k sessions with 20ms or somewhere in between if you have mixed traffic (as most of our customers do). Latest Linux kernels might get better contention control on higher CPU count systems, or at least it is what I've seen on some of the benchmarks not so long time ago, We've planned to run some evaluations but have not got time to do so yet.
On top of that, even if you can push say 1 million PPS through single tuned up box (10k sessions at 10ms), some other constrains may arise. Most of the general-purpose DC providers we've encountered in our somewhat limited practice, design their networks with much lower PPS per port in mind. It's often an issue with a new DC here that we bump into all sorts of automated DDoS prevention systems once we reach 100-200k PPS per box/port. So at the end of the day it might be more practical and economical to run bunch of the smaller nodes and spread the load across them using something like rtp_cluster rather than try to cram all that traffic into a single box/port.
-Max
Hello,
thanks for all those details, very useful ...
To be clear -- the issue of using high cpu on idle (no active calls) was with rtpproxy v1.2 on a centos (iirc, v6), not with rtpproxy 2.0. On debian, same version of rtpproxy was not exposing this. I was just curios to see if anyone else saw it ... might have been just that system...
Cheers, Daniel
On 19/10/16 20:00, Maxim Sobolev wrote:
Just a little comment on the numbers that I've thrown out earlier today. Those are probably somewhat pessimistic, with some creative tuneup you can probably go much higher. But we also constrained by some other considerations (i.e. running fully redundant network connection with FEC, full firewall etc, custom OS), so those are what we get.
Also, I wanted to point to the list, speaking about number of sessions is pretty much pointless, as the main thing that keeps us busy is packet per second rate. Since same 10,000 sessions might translate to as much as half of PPS rate if use 10ms ptype versus 20ms ptype. Our limit at this point of time is some 450k PPS in and 450k PPS out, 16 cores, FreeBSD 10.3, which could be either 4.5k sessions with 10ms packets or 9k sessions with 20ms or somewhere in between if you have mixed traffic (as most of our customers do). Latest Linux kernels might get better contention control on higher CPU count systems, or at least it is what I've seen on some of the benchmarks not so long time ago, We've planned to run some evaluations but have not got time to do so yet.
On top of that, even if you can push say 1 million PPS through single tuned up box (10k sessions at 10ms), some other constrains may arise. Most of the general-purpose DC providers we've encountered in our somewhat limited practice, design their networks with much lower PPS per port in mind. It's often an issue with a new DC here that we bump into all sorts of automated DDoS prevention systems once we reach 100-200k PPS per box/port. So at the end of the day it might be more practical and economical to run bunch of the smaller nodes and spread the load across them using something like rtp_cluster rather than try to cram all that traffic into a single box/port.
-Max
And yes, I was remiss in failing to mention that an effective solution to scaling out rtpproxy is to bind multiple instances with different core affinities.
-
Alex Balashov -
Arsen -
Daniel-Constantin Mierla -
Maxim Sobolev -
Rodrigo Moreira