Martin Joseph wrote:

On 2006-10-08 21:28:08 -0700, Nic Bellamy <[EMAIL PROTECTED]> 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/

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to