Hey Alex,
On 10.10.2011 19:53, Alex Balashov wrote:
> Not only that, but the fix is not trivial. Contrary to how it may
> appear to a non-developer, this problem cannot be solved by just making
> a little patch.
>
> Stateless replies have that name for a reason; they lack state. They
> don't t
Alex,
We use our own kernel-based mediaproxy in our systems, so I can't tell
much about rtpproxy, beside that our ngcp-mediaproxy-ng uses the same
control protocol (or a basic sub-set of it, e.g. no recording or stream
forking etc), so you can use it as drop-in replacement of rtpproxy.
See http:/
Andreas,
Good to know. These tens of thousands of concurrent calls are bridged
signaling-only, I assume? What about RTP relay performance?
One of the reasons I've always liked rtpproxy is that it forwards quite a
respectable number of streams concurrently, for a userspace process, and is
e
Alex,
We've had huge performance and stability issues with SEMS in the past as
well, but together with the Frafos guys we've brought version 1.4 with
thread-pool enabled into a stable state for large-scale deployments.
We're running it in production in various deployments with thousands of
parall
In theory, this sounds appealing. But we have had a lot of problems with SEMS
performance and stability with a large number of calls. We are rather fond of
the proxy-based approach because it works, and works well.
--
This message was painstakingly thumbed out on my mobile, so apologies for
b
Alex Balashov writes:
> Stateless replies have that name for a reason; they lack state. They
> don't trigger any TM callbacks that the dialog module can latch onto.
> So, figuring out how to remove a dialog to which a stateless final
> failure reply has been sent is actually quite difficult, and
Not only that, but the fix is not trivial. Contrary to how it may appear to a
non-developer, this problem cannot be solved by just making a little patch.
Stateless replies have that name for a reason; they lack state. They don't
trigger any TM callbacks that the dialog module can latch onto.
On 10.10.2011 19:00, Jim Lucas wrote:
> On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote:
>> 2011/10/10 Jim Lucas :
>>> On 10/8/2011 6:03 PM, Timo Reimann wrote:
As explained by myself in Flyspray issue #146[1], a fix to this
> problem is
quite feasible. Overall, I believe that dialog
On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote:
> 2011/10/10 Jim Lucas :
>> On 10/8/2011 6:03 PM, Timo Reimann wrote:
>>>
>>> As explained by myself in Flyspray issue #146[1], a fix to this problem is
>>> quite feasible. Overall, I believe that dialog module usage should be more
>>> robust and wor
2011/10/10 Jim Lucas :
> On 10/8/2011 6:03 PM, Timo Reimann wrote:
>>
>> As explained by myself in Flyspray issue #146[1], a fix to this problem is
>> quite feasible. Overall, I believe that dialog module usage should be more
>> robust and work out of the box; that is, it shouldn't matter where you
On Monday 10 October 2011, Jim Lucas wrote:
> > As explained by myself in Flyspray issue #146[1], a fix to this problem
> > is quite feasible. Overall, I believe that dialog module usage should be
> > more robust and work out of the box; that is, it shouldn't matter where
> > you place dlg_manage()
On 10/8/2011 6:03 PM, Timo Reimann wrote:
>
> As explained by myself in Flyspray issue #146[1], a fix to this problem is
> quite feasible. Overall, I believe that dialog module usage should be more
> robust and work out of the box; that is, it shouldn't matter where you place
> dlg_manage(), things
Am 08.10.2011 um 21:44 schrieb Iñaki Baz Castillo:
> 2011/10/3 Jon Bonilla :
>> Due to a couple of bugs in the dialog module I'd suggest you to run this code
>> after the user auth has been successfull. You'll need to call dlg_manage()
>> function first.
>>
>> The other bug makes the dialog not be
2011/10/3 Jon Bonilla :
> Due to a couple of bugs in the dialog module I'd suggest you to run this code
> after the user auth has been successfull. You'll need to call dlg_manage()
> function first.
>
> The other bug makes the dialog not being freed if you send a sl reply
> generated
> by the prox
On Monday 03 October 2011, Uri Shacked wrote:
> Thanks for the help.
>
> The idea of using SQLOPS for many things crossed my mind ButI am
> using ACC with DB, Dialog with DB and so... isnt it too much? i mean for
> load and capacity reasons?
Hi Uri,
this depends on your exact load situ
El Sun, 02 Oct 2011 21:03:38 -0500
Graham Wooden escribió:
> Hi Uri,
>
> I just got done tailoring this exact concept with the dialog module (you may
> have just read my posts).
>
Two tips here:
Due to a couple of bugs in the dialog module I'd suggest you to run this code
after the user auth
Hi,
Thanks for the help.
The idea of using SQLOPS for many things crossed my mind ButI am
using ACC with DB, Dialog with DB and so... isnt it too much? i mean for
load and capacity reasons?
BR,
Uri
___
SIP Express Router (SER) and Kamailio (Ope
Graham,
Good deal. The one improvement I would suggest would be to use sqlops for
custom DB queries as it is more flexible, and is the canonical way to do them
now as of >= 1.5.0. avp_db_query() could go away at some point.
--
This message was painstakingly thumbed out on my mobile, so apolog
Hi Uri,
I just got done tailoring this exact concept with the dialog module (you may
have just read my posts).
Here is how I am doing it, roughly, for me. I have two places where I am
executing the 3rd section below (for outbound and inbound).
Your mileage will vary.
modparam("auth_db", "load_cr
Hi,
I am trying to create concurrent calls limitations.
two questions:
1. should i use dialog module? or is there a better module?
2. i was trying to work with the dialog module, but didnt understand how and
where to configure the commands and which to use any examples or ideas?
BR,
Uri
20 matches
Mail list logo
