[OpenSIPS-Users] Killing confirmed no-ack dialogs
osas at voipembedded.com
Wed Mar 30 20:47:16 CEST 2011
On Wed, Mar 30, 2011 at 2:30 PM, Brett Nemeroff <brett at nemeroff.com> wrote:
> 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
> "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.
> 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
>> 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?
>> On Wed, Mar 30, 2011 at 12:50 PM, Brett Nemeroff <brett at nemeroff.com>
>> > 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).
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users