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

[Nic Bellamy]

Martin Joseph wrote:

> On 2006-10-08 21:28:08 -0700, Nic Bellamy <nicb-lists at vadacom.co.nz> 
> said:
>
>> Martin Joseph wrote:
>>
>>> 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.
>>>
>>> This is particularly annoying when the stuck channels include my 
>>> PSTN gateway (wellgate 3701a), which leaves incoming and outgoing 
>>> calls a busy signal.
>>>
>>> I see by googling that soft hangup is a good way to kill these 
>>> channels and that works fine for me.
>>>
>>> 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. Can 
the other end still hear you at this point?

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.

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> ;-)

HTH,
    Nic.

-- 
Nic Bellamy,
Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/