[asterisk-bugs] [Asterisk 0016514]: Asterisk causes crosstalk between inbound and random channels

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16514 
====================================================================== 
Reported By:                jmthomas
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16514
Category:                   Channels/chan_zap
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           Older 1.4 - please test a newer version 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-12-24 15:08 CST
Last Modified:              2010-01-11 15:04 CST
====================================================================== 
Summary:                    Asterisk causes crosstalk between inbound and random
channels
Description: 
This issue occurs approximately every 2 weeks.  A reboot of Asterisk seems
to resolve the issue for another 10-14 days.  There are no other related
errors, warnings or failures in the Asterisk logs.  ZTTOOL indicates no
alarms or issues with the PRI.  All vendors involved have checked line
attenuation to our demarcation point - passed without error.

When the following appears in the full log - the audio from this inbound
caller is broadcast to random channels: 

<snip>
chan_zap.c: Ring requested on channel 0/4 already in use or previously
requested on span 1.  Attempting to renegotiating channel.
</snip>

In the above example, this inbound caller was then negotiated to channel
0/5.  His/her audio was then broadcast to everyone in an ongoing
meetme-conference.  
Periodic automatic Zap clearing is set to 1800 seconds.

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016549 Conference Calls
====================================================================== 

---------------------------------------------------------------------- 
 (0116466) jmthomas (reporter) - 2010-01-11 15:04
 https://issues.asterisk.org/view.php?id=16514#c116466 
---------------------------------------------------------------------- 
I have traced the issue down a tad further and believe the additional
information may assist.

Asterisk appears to not be actually hanging up the connection when the
call disconnects.  For eg: Channel 2 was used by a caller who hung
up...however, the next call that comes in on Channel 2 will recieve the
following entry in the logs:
Jan 11 10:22:21 DEBUG[5714] chan_zap.c: Ring requested on channel 0/2
already in use or previously requested on span 1.  Attempting to
renegotiating channel.

Once this entry appears, once the inbound caller is 'renegotiated' - it is
THEIR audio which is suddenly broadcast to random channels.

In the above example, if I examine the FULL logs (verbosity cranked up to
30 with pri debugging) the following is noted:
*  Original caller uses channel 0/2
*  Call creation is shown, but there is NOT an entry indicating the call
ever ended
*  PRI debug shows there was a disconnect - but Asterisk does not follow
with it's typical '-- Channel 0/2, span 1 got hangup request'  type
message...
* CLI: show channels verbose    results: 0 active channels, 1 active call 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-01-11 15:04 jmthomas       Note Added: 0116466                          
======================================================================