Sorry I missed to see that this thread was already in full action and Daniel
got catched on...
Cheers,
--Timo
Am 20.02.2012 um 22:55 schrieb Timo Reimann:
> Hey all,
>
>
> Am 31.01.2012 um 14:06 schrieb Timo Reimann:
>> Am 31.01.2012 um 11:32 schrieb Marius Pedersen:
>>
>>> On 01/31/2012
Hey all,
Am 31.01.2012 um 14:06 schrieb Timo Reimann:
> Am 31.01.2012 um 11:32 schrieb Marius Pedersen:
>
>> On 01/31/2012 09:11 AM, Øyvind Kolbu wrote:
>>> On 2012-01-20 at 23:32, Timo Reimann wrote:
>>>
>>> Hi and sorry for the late response!
>>>
Another possible root cause: After calli
> On 2012-02-14 at 11:38, Daniel-Constantin Mierla wrote:
>> can you create the transaction with t_newtran() somewhere before calling
>> dlg manage? It should absorb retransmissions before going into dialog
>> processing. After creating the transaction, use either send_reply() or
>> t_reply() inste
On 2012-02-14 at 11:38, Daniel-Constantin Mierla wrote:
> can you create the transaction with t_newtran() somewhere before calling
> dlg manage? It should absorb retransmissions before going into dialog
> processing. After creating the transaction, use either send_reply() or
> t_reply() instead
On 2/14/12 10:17 AM, Øyvind Kolbu wrote:
On 2012-01-31 at 14:15, Øyvind Kolbu wrote:
On 2012-01-31 at 14:06, Timo Reimann wrote:
I'm currently in the process of investigating a dialog-related issue
together with Uri (see CC). It may be related to your problem, so let's
see if I can find somet
On 2012-01-31 at 14:15, Øyvind Kolbu wrote:
> On 2012-01-31 at 14:06, Timo Reimann wrote:
> > I'm currently in the process of investigating a dialog-related issue
> > together with Uri (see CC). It may be related to your problem, so let's
> > see if I can find something out that helps you as well.
On 2012-01-31 at 14:06, Timo Reimann wrote:
> I'm currently in the process of investigating a dialog-related issue
> together with Uri (see CC). It may be related to your problem, so let's
> see if I can find something out that helps you as well. If not, I/we
> should take a dedicated look at your
Hi,
Am 31.01.2012 um 11:32 schrieb Marius Pedersen:
> On 01/31/2012 09:11 AM, Øyvind Kolbu wrote:
>> On 2012-01-20 at 23:32, Timo Reimann wrote:
>>
>> Hi and sorry for the late response!
>>
>>> Another possible root cause: After calling dlg_manage() on an INVITE, you
>>> do not forward the req
On 01/31/2012 09:11 AM, Øyvind Kolbu wrote:
On 2012-01-20 at 23:32, Timo Reimann wrote:
Hi and sorry for the late response!
Another possible root cause: After calling dlg_manage() on an INVITE, you
do not forward the request (e.g., by calling exit() instead). Could that
be the case? If so, the
On 2012-01-20 at 23:32, Timo Reimann wrote:
Hi and sorry for the late response!
> Another possible root cause: After calling dlg_manage() on an INVITE, you
> do not forward the request (e.g., by calling exit() instead). Could that
> be the case? If so, the solution would be (again) to defer dialo
Hey,
Am 18.01.2012 um 13:46 schrieb Øyvind Kolbu:
> On 2012-01-17 at 23:47, Timo Reimann wrote:
>> Hey Øyvind,
>> Am 17.01.2012 um 13:41 schrieb Øyvind Kolbu:
>>>
>>> Then in the main route:
>>>
>>> if !allow_trusted() {
>>> route(AUTH);
>>> }
>>>
>>> if (is_me
On 2012-01-17 at 23:47, Timo Reimann wrote:
> Hey Øyvind,
> Am 17.01.2012 um 13:41 schrieb Øyvind Kolbu:
> >
> > Then in the main route:
> >
> >if !allow_trusted() {
> >route(AUTH);
> >}
> >
> >if (is_method("INVITE")) {
> >setflag(3);
> >
Hey Øyvind,
Am 17.01.2012 um 13:41 schrieb Øyvind Kolbu:
> we use the dialog-module to keep track of concurrent calls, and then set
> a treshold for simultanious calls. After we upgraded from 1.5 to 3.2, we've
> been having a lot of dialogs which are stuck in both the database and
> memory.
>
>
Hi,
we use the dialog-module to keep track of concurrent calls, and then set
a treshold for simultanious calls. After we upgraded from 1.5 to 3.2, we've
been having a lot of dialogs which are stuck in both the database and
memory.
kamailio -V
version: kamailio 3.2.1 (i386/linux) 918035-dirty
flag
14 matches
Mail list logo
