the pipelimit aims to be more dynamic, while dropping the queues
concepts of ratelimit, given those can be done with IF conditions inside
In ratelimit, the pipes are defined as parameters, with some limits in
the number of pipes as well as constrained to integer ids for pipes.
Pipelimit can load the definitions of pipes from database, making it
easier to provision via some gui. It doesn't store back anything, given
that even few seconds of shutdown will invalidate the pipes counters.
Moreover, the pipes can be created on the fly, they don't have to be
defined in advance via db or parameters. You can load the limit and
algorithm from a user profile and then just use them as parameter with
the username as pipe id parameter and you get a new pipe created at that
moment if there is none with same id.
On 30/08/16 12:15, Andreas Granig wrote:
another approach here. Tried it as a proof of concept recently and it
seems to do its job.
Seems like pipelimit is derived from ratelimit. What's the main
difference from ratelimit, other than named pipes and DB support? What's
the purpose of the DB support of pipelimit? Does it cache its values and
can be reloaded from DB on demand (I don't see an rpc command for that)?
That would be really valuable.
On 08/29/2016 05:39 PM, Alex Balashov wrote:
On 08/29/2016 11:37 AM, NITESH BANSAL wrote:
Finally I got it working. The issue was that I
was trying to use
pikelimit with Kamailio version 4.1, 4.1 version doesn't allow for
dynamic pipe creation.
In the end, I backported pipelimit code from Kamailio version 4.2 and
used pl_check function to create dynamic pipes.
Excellent. That was indeed an
important shift. :-)
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list