On Thu, May 12, 2011 at 9:30 AM, Duane Larson <[email protected]>wrote:
> Hey Anca. Yeah it does kind of sound like a stupid question. I guess I > was trying to resolve this issue (*dialogs* in the invalid "CONFIRMED NO > ACK" state) > > http://opensips-open-sip-server.1449251.n2.nabble.com/Killing-confirmed-no-ack-dialogs-td6223926.html > > The timeout_avp during the initial INVITE and then during the ACK does > solve this issue, but I was thinking that the SIP clients might send a > REINVITE or an UPDATE every X minutes to reaffirm that the call is still up > or good. I am pretty sure from my testing that the Snom phones do send > REINVITES and I think the Cisco phones send UPDATES. It looks like the > Counterpath Bria client and Blink don't do anything like this. But now that > I really think about it I guess I could just raise the timeout value to > something larger than 2 hours like 5 hours or 8 hours. I guess there aren't > that many types of phone calls that should last 5 to 8 hours. The main > thing I wanted was the 120 second timeout in case there wasn't an ACK. > Duane, I'm glad you got around to testing this out. I hadn't had a chance yet to test it out. Instead I had created a cronjob that checks the dialogs via fifo and then ends calls that have been in that state for longer than X seconds. For the particular problem you are mentioning, can't you just set a flag on the call to indicate if you've already extended the timeout? That way, future ACKs don't keep pushing the timeout out further? Or am I missing something? Thanks, Brett
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
