[OpenSIPS-Users] Dialog timeout_avp kills call

[Duane Larson]

There are no future ACKs that are refreshing the call for another 2 hours.
Here is the SIP flow

INVITE
                $avp(i:30)=120;   <----- Sets timeout to 2 minutes
                setflag(30);   <---- "bye_on_timeout_flag"
100 Giving a try
180 Ringing
200 OK
ACK
        if (has_totag()) {
                if ( is_method("ACK") ) {
                                $avp(i:30)=7200;   <----- Sets timeout to 2
hours
                                setflag(30);
                }
                if (loose_route()) {


So now the call will last at most for 2 hours if the no one hangs up.  But
with the Bria and Blink clients there will be no more SIP methods sent that
can refresh the timeout value to another 2 hours if the call is about to go
longer than 2 hours.  So if the caller or callee is on a long conference
call or IT support call that goes longer than 2 hours the call will hang up
because there is no way to refresh the timeout to another 2 hours.  So there
aren't any messages I can use to renew the timeout.  So I don't think I can
use a flag for anything.

So with the Snom phones I wouldn't have this issue of the call getting cut
off after 2 hours since it looks like the Snom phones send REINVITEs every
30 minutes I believe.  Hope that explains it a little better.

With all that being said I think me setting the call to 5 hours should kind
of fix this issue since calls really shouldn't go 5 hours.  The main issue
that started all this was to get rid of calls that didn't even get to the
ACK phase.



On Thu, May 12, 2011 at 9:34 AM, Brett Nemeroff <brett at nemeroff.com> wrote:

>
>
> On Thu, May 12, 2011 at 9:30 AM, Duane Larson <duane.larson at gmail.com>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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


-- 
--
*--*--*--*--*--*
Duane
*--*--*--*--*--*
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110512/cad68b51/attachment.htm>