Summary:	ASTERISK-15368: Asterisk causes crosstalk between inbound and random channels
Reporter:	JonT (jmthomas)	Labels:
Date Opened:	2009-12-24 15:08:22.000-0600	Date Closed:	2011-07-26 14:35:51
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_zap
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
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. ****** ADDITIONAL INFORMATION ****** Please advise if additional debug logs are required.  As this is a cross-talk issue, and even google seems to be empty of these being reported, I'm unsure what additional logging would be beneficial.
Comments:	By: Leif Madsen (lmadsen) 2010-01-04 12:59:16.000-0600 I'd suggest that the console out with debug level logging enabled may be useful when the issue presents itself. logger.conf: full => notice,warning,error,debug,verbose CLI: core set verbose 10 core set debug 10 Then when it occurs, trim the file around the time the issue occurs, and upload it here. Thanks! By: Leif Madsen (lmadsen) 2010-01-04 12:59:48.000-0600 Additionally, testing with a newer version may also be beneficial, along with a description of your setup, etc... By: JonT (jmthomas) 2010-01-11 15:04:46.000-0600 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 By: Leif Madsen (lmadsen) 2011-07-26 14:35:45.169-0500 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines