[asterisk-users] Re: SIP stuck channel soft hangup?

[Martin Joseph]

On 2006-10-10 20:25:44 -0700, Nic Bellamy <nicb-lists at vadacom.co.nz> said:
>>> On 2006-10-08 21:28:08 -0700, Nic Bellamy <nicb-lists at vadacom.co.nz> said:
>>> 
>>> 
>>>> I am seeing occasional stuck SIP channels that seem to occur when the 
>>>> fricking Nokia E60 drifts out of WIFI range in the midst of a call.
>>>> <snip>I wonder if there is some way to automatically soft hangup these 
>>>> channels when the qualify fails?
>>> 
>>> Take a look at rtptimeout in sip.conf - that might do what you need.
>> 
>> 
>> Thanks again for the idea Nic!  This does seem like a great way to do 
>> what I need, but it doesn't seem to work!
>> 
>> I have added the statement
>> 
>> rtptimeout=60
>> 
>> Into my extension for the Nokia E60. Then I reloaded asterisk.
>> 
>> I tried just now to call through my gateway and then walk out of wifi range.
>> 
>> The console continues to show me 2 active channels 1 active call, even 
>> after the minute (or several minutes) have passed?
>> 
>> Any thoughts on why this doesn't work in 1.2.12?
> 
> Hmm, this should work in 1.2.12 (I think it has for me). I'd recommend 
> watching with tcpdump while you try this, as it's possible that your AP 
> is picking up packets from your E60, but the E60 isn't getting them 
> from the AP - in this case, as Asterisk will still be seeing the RTP, 
> it won't time it out - even though it's dead from a users perpective.
I don't think that is the case since the e60 is off the network 
entirely at that point....
> Can the other end still hear you at this point?
No.
> 
> There was a patch added a couple of months back, but this made it into 1.2.11:
> http://bugs.digium.com/view.php?id=7459
> 
> Depending on the state of the call, it won't always do the job - for 
> instance if you're dialing but not connected, and the other end sends 
> perpetual call progress tones. Asterisk isn't expecting any RTP at this 
> point, so won't be able to do anything about it at this level.
Hmmm,  unlikely, but could still happen at some point.  I think that 
scenario would timeout though?
> 
> Even with this, if even one RTP packet gets through in that 60 seconds, 
> it'll reset the timeout. Trying to make this more robust would get 
> tricky, as we don't necessarily know what packetization interval the 
> peer is using, so working on a "% lost" basis would be quite tricky.
> 
> </braindump> ;-)
Thanks I appreciate your insight,  and ideas that seem to be pretty 
close to what I need...

Marty