Ovidiu,<div>It's been a number of things. The two latest problems causing this are:</div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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. </div>
<div><br></div><div>I don't believe I've seen the race condition you mentioned. So you mentioned: </div><div><br></div><div>"<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">For case 1. the dialog timeout should be set to a short value and the</span></div>
<meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">dialog should autoexpire by itself."</span><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">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*.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Do you know some other way to do it?</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Thanks,</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Brett</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font><div><br><div class="gmail_quote">On Wed, Mar 30, 2011 at 1:20 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com">osas@voipembedded.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
First, it needs to be identified how the dialog arrived in that state:<br>
1. The ACK was not received and in this case the callee should send a BYE:<br>
1a. The BYE was sent and received by opensips (then it's a bug<br>
handling the BYE);<br>
1b. The BYE was not sent (and we deal with a bogus callee);<br>
2. The ACK was received but we had a race between 200ok and ACK (I<br>
don't remember if this race was fixed).<br>
<br>
For case 1. the dialog timeout should be set to a short value and the<br>
dialog should autoexpire by itself.<br>
For case 2. the race must be fixed (otherwise we may end up<br>
terminating valid dialogs).<br>
<br>
Do you have any additional info that could help identifying the proper<br>
scenario that are we dealing with?<br>
<br>
<br>
Thanks,<br>
Ovidiu<br>
<div><div></div><div class="h5"><br>
On Wed, Mar 30, 2011 at 12:50 PM, Brett Nemeroff <<a href="mailto:brett@nemeroff.com">brett@nemeroff.com</a>> wrote:<br>
> Yeah, I'm on the verge of doing that. but seems like I should be able to be<br>
> smarter about it. right?<br>
><br>
> On Wed, Mar 30, 2011 at 11:45 AM, <<a href="mailto:duane.larson@gmail.com">duane.larson@gmail.com</a>> wrote:<br>
>><br>
>> One thing to do is write a script that will check your dialogs and how<br>
>> long they have been active. If they are older than X then delete the<br>
>> dialogs. You can use the "opensipsctl fifo dlg_end_dlg" to kill the dialogs.<br>
>><br>
>> On Mar 30, 2011 11:24am, Brett Nemeroff <<a href="mailto:brett@nemeroff.com">brett@nemeroff.com</a>> wrote:<br>
>> > Hello All,I've seen some incompatibilities pop up from time to time that<br>
>> > leave dialogs in the invalid "CONFIRMED NO ACK" state. In general I'd like<br>
>> > to end dialogs that stay in this state for more than X seconds. The idea is,<br>
>> > either become confirmed, or die.<br>
>> ><br>
>> > I can't figure out how to do this. Originally I was going to use dialog<br>
>> > timeouts. Set a short timeout (60 seconds) until the dialog becomes<br>
>> > confirmed, but then change the dialog timeout to a long timeout (2 hours)<br>
>> > once confirmed. But it doesn't seem like I can do that since the dialog<br>
>> > timeout_avp can only be changed during a REQUEST (per docs).<br>
><br>
</div></div>> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
><br>
</blockquote></div><br></div></div>