[Home]

Summary:ASTERISK-15295: one way audio after call waiting
Reporter:Erik Smith (eeman)Labels:
Date Opened:2009-12-09 14:44:26.000-0600Date Closed:2011-06-07 14:00:50
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:System is CentOS 5.3
asterisk 1.6.1.11
addons 1.6.1.2
dahdi 2.2.0.2

TDM800P card w/ echo can, 1 quad FXO module chan 1-4 and 1 single FXS module chan 5

1. call comes into asterisk via SIP which then rings a ring group of devices
Local/101
Local/102
Local/103 etc

2. call answered on chan dahdi/5

3. while on call a second call comes in calling the same ring group and call waiting beep is heard on dahdi/5 device and the dahdi/5 device can still hear the remote user. the remote user can no longer hear audio from dahdi/5.

relative chan_dahdi.conf section

group = 1
context=from-inside
signalling=fxo_ks
callerid=House Phones<101>
mailbox=102
txgain=-4.0
rxgain=-2.0
callwaiting=no
callreturn=yes
callwaitingcallerid=no
threewaycalling=no
transfer=yes
cancallforward=yes
callreturn=yes
pickupgroup=1
callgroup=1
channel => 5


****** ADDITIONAL INFORMATION ******

This issue does not exist in 1.6.0 releases. I first encountered this problem when I went from 1.6.0 releases to 1.6.1.6 but reverted. Tried again to migrate to 1.6.1.11 to discover the problem still exists.
Comments:By: Leif Madsen (lmadsen) 2009-12-10 09:18:57.000-0600

Can you provide some console output and debugging (logger.conf) while this is happening?

Additionally, can you try 1.6.1.0 and see if the issue exists there? If not, then it might be worthwhile to see which version first introduces this regression.

Thanks!

By: Leif Madsen (lmadsen) 2010-01-05 10:19:52.000-0600

Suspended due to lack of feedback from reporter.

By: Michael J Miller (moikmellah) 2013-10-24 21:00:48.576-0500

I've encountered this same behavior with the following setup:

- Debian 6 w/kernel 2.6.32-5-amd64
- Asterisk 11.2.1
- dahdi-linux-complete-2.6.1+2.6.1
- Digium TE820 T1 card
- Adtran TA612

While a DAHDI FXS channel is in an active call, if another call from a non-FXS channel (reproduced with both SIP and PRI channels) rings in and hangs up while the CW pip is playing, audio is lost to the FXS channel (but the other party can still hear audio).  This can be reliably reproduced by answering a call to a DAHDI channel (or dialing out from it - call direction doesn't seem to matter), then dialing it from any other channel with a 30-second timeout:

- DAHDI/1 calls DAHDI/2; DAHDI/2 answers, call is bridged
- SIP/blah calls DAHDI/1 with Dial(DAHDI/1,30)
- Dial() times out
- DAHDI/2 can still hear audio from DAHDI/1, but DAHDI/1 hears nothing

This can also be seen by manually hanging up the CallWaiting channel during any CW pip - the 30 second timeout just coincides with one every time.  It doesn't seem to occur if the CallWaiting call is from another FXS channel.

As far as I can tell, there's a function (analog_cancel_cidspill()) which serves to both cancel any existing spill and restore the interrupted conference audio, but it never seems to be called in the scenario above (probably because it's only called in __analog_handle_events(), which doesn't apply to a PRI or SIP channel hangup).  Inserting a call to analog_cancel_cidspill() into analog_hangup() at line 1404 (in the else block under 'case ANALOG_SUB_CALLWAIT') seems to fix the issue on my test setup, but I'm not sure what other impact it might have.

I can provide some debug output and my DAHDI configs from the call scenario above; please let me know what other data I can provide to be of assistance.

Thanks,
-mm

By: Michael J Miller (moikmellah) 2013-10-24 21:03:45.042-0500

Also: since line numbers without a filename is not the most helpful thing ever.. I was referring to channels/sig_analog.c.

Thanks,
-mm