[asterisk-dev] Strange Asterisk Behaviour - Stuck channels

[John Todd]

At 3:19 PM -0500 2008/7/30, John Lange wrote:
>
>We do not use that setting but note that rtptimeout terminates a call if
>there is no RTP activity for a given number of seconds.
>
>What we have is lots of RTP activity but no SIP activity so I would
>assume rtptimeout wouldn't have any effect.
>
>Also, keep in mind that when a second call is placed to the device,
>Asterisk sends two RTP streams on the same port which results in the
>garbled audio I mentioned.
>
>This perhaps implies something more significant is wrong.
>
>--
>John Lange
>www.johnlange.ca

The RTP activity is from * -> SIP-UA in the problem case -  perhaps 
there is no return audio?  Asterisk is looking for the reply packets 
from the distant side to keep the rtptimeout counters from hanging up 
the call.  I would suggest setting an rtptimeout value for that peer 
in sip.conf to see if it solves the symptoms of your problem.  This, 
of course, solves only symptoms if it works - it does not solve the 
root of the problem even if it does work to close out the calls that 
are 'stuck' in some marginally timely manner.

If you were running 1.6, there is the SIP session-timer patch which 
also might work to solve the problem in a different way (RFC 4028 - 
sending periodic re-INVITEs that keep a live channel up, but will 
cause a "dead" channel to fail and get closed.)  However, as 
discussed with ctooley on the IRC channel yesterday this might not 
work either - if Asterisk is failing to hang up channels that it 
"knows" are dead, then it makes no difference how it discovers that 
the channel is gone if it can't succeed in clearing.

JT

-- 
--
John Todd
jtodd at digium.com        +1-256-428-6083
Asterisk Open Source Community Director