[OpenSIPS-Users] Killing confirmed no-ack dialogs

[Brett Nemeroff]

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?

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).
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110330/479c3f0c/attachment-0001.htm>