[OpenSIPS-Users] Killing confirmed no-ack dialogs

[Bogdan-Andrei Iancu]

Hi Guys,

trying to follow this up.

As Ovidiu said, you should be able to set different dialog timeouts. 
Like at INVITE request you set a 10 seconds lifetime, and at ACK time a 
2 hours lifetime.

Brett, have you tried this and didn't work ?

Regards,
Bogdan


On 03/30/2011 09:47 PM, Ovidiu Sas wrote:
> On Wed, Mar 30, 2011 at 2:30 PM, Brett Nemeroff<brett at nemeroff.com>  wrote:
>> Ovidiu,
>> It's been a number of things. The two latest problems causing this are:
>> 1. 200 Ok sent to call originator, originator never sends an ack. BUT then
>> after about 15 seconds, the originator sends a BYE with a Max-Forwards of 0.
>> (!!). Believe it or not, this happens a lot. Dialog stays active for 12
>> hours in this case.
>> 2. I have seen numerous UAs truncating RR uri params. Its ugly. Most of this
>> I've fixed by setting DID_FALLBACK for dialog matching.
>> There are numerous compatibility issues that I've seen pop up here are there
>> that cause these dialogs to get "stuck". Basically, I don't want any dialog
>> to stay in that unconfirmed state for any extended period of time. As Duane
>> was saying, there is a lot of sense in just writing a cron job that just
>> terminates dialogs that have been in that state for an extended period of
>> time (which I've considered doing) but really would like to do this in the
>> call flow itself.
>> I don't believe I've seen the race condition you mentioned. So you
>> mentioned:
>> "For case 1. the dialog timeout should be set to a short value and the
>> dialog should autoexpire by itself."
>> The problem is that I can't change the dialog timeout to be large once
>> confirmed, or at least, I don't know how. Specifically because the docs say
>> that for the dialog timeout avp, it can only be changed in a *request*.
>> Do you know some other way to do it?
> This should be done by the dialog itself (nothing to do from the
> script).  It's a bug.
>
> As for the other question, I haven't followed closely the latest fixes
> and additions to the dialog module.
> You could try to set the dialog timeout avp to a small value in the
> beginning and set it back to a higher value when an ACK is received,
> but I haven't checked the code if this will work.
>
>
>> Thanks,
>> Brett
>>
>> On Wed, Mar 30, 2011 at 1:20 PM, Ovidiu Sas<osas at voipembedded.com>  wrote:
>>> First, it needs to be identified how the dialog arrived in that state:
>>>   1. The ACK was not received and in this case the callee should send a
>>> BYE:
>>>   1a. The BYE was sent and received by opensips (then it's a bug
>>> handling the BYE);
>>>   1b. The BYE was not sent (and we deal with a bogus callee);
>>>   2. The ACK was received but we had a race between 200ok and ACK (I
>>> don't remember if this race was fixed).
>>>
>>> For case 1. the dialog timeout should be set to a short value and the
>>> dialog should autoexpire by itself.
>>> For case 2. the race must be fixed (otherwise we may end up
>>> terminating valid dialogs).
>>>
>>> Do you have any additional info that could help identifying the proper
>>> scenario that are we dealing with?
>>>
>>>
>>> Thanks,
>>> Ovidiu
>>>
>>> On Wed, Mar 30, 2011 at 12:50 PM, Brett Nemeroff<brett at nemeroff.com>
>>> wrote:
>>>> Yeah, I'm on the verge of doing that. but seems like I should be able to
>>>> be
>>>> smarter about it. right?
>>>>
>>>> On Wed, Mar 30, 2011 at 11:45 AM,<duane.larson at gmail.com>  wrote:
>>>>> One thing to do is write a script that will check your dialogs and how
>>>>> long they have been active. If they are older than X then delete the
>>>>> dialogs. You can use the "opensipsctl fifo dlg_end_dlg" to kill the
>>>>> dialogs.
>>>>>
>>>>> On Mar 30, 2011 11:24am, Brett Nemeroff<brett at nemeroff.com>  wrote:
>>>>>> Hello All,I've seen some incompatibilities pop up from time to time
>>>>>> that
>>>>>> leave dialogs in the invalid "CONFIRMED NO ACK" state. In general I'd
>>>>>> like
>>>>>> to end dialogs that stay in this state for more than X seconds. The
>>>>>> idea is,
>>>>>> either become confirmed, or die.
>>>>>>
>>>>>> I can't figure out how to do this. Originally I was going to use
>>>>>> dialog
>>>>>> timeouts. Set a short timeout (60 seconds) until the dialog becomes
>>>>>> confirmed, but then change the dialog timeout to a long timeout (2
>>>>>> hours)
>>>>>> once confirmed. But it doesn't seem like I can do that since the
>>>>>> dialog
>>>>>> timeout_avp can only be changed during a REQUEST (per docs

-- 
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"