[Home]

Summary:ASTERISK-02869: FXO interface stops handling outgoing calls following polarity reversal when using V23 signalling
Reporter:wrs (wrs)Labels:
Date Opened:2004-11-22 12:11:26.000-0600Date Closed:2008-01-15 15:14:40.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-callerid-limit.patch
Description:It would appear that random polarity reversal events on my flakey old BT line trick Asterisk into listening for a Caller ID data stream that simply isn't there. The polarity reversal is not followed by either a V23 caller ID stream, or a ringing. There is no timeout when processing Caller ID data, so this event removes the line from the pool which can handle outgoing calls. The situation persists until an incoming call comes in and (after hanging up) moves the line back into the idle state.

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

I have a TDM400P PCI card with two FXO and two FXS modules. Both FXO modules are connected to BT lines here in the UK. Both BT lines have V23 Caller-ID, which works fine with Asterisk. One line is fine. The other line is old and decidedly flakey.

Both FXO modules (channels 3 and 4) are in "group 1" for outgoing calls.

My calls are placed like this: Dial(Zap/g1/${EXTEN})

My understanding is that the first free channel in the group should be used to place calls. Much of the time, this is the case. However, after some seemingly random time interval, channel 3 stops accepting outgoing calls, even if the line is idle -- and all calls go out on channel 4. If channel 4 is busy, outgoing calls are rejected (I hear a congestion tone, and my Cisco 7960 says "Reorder") even though channel 3 is idle.

If I then call channel 3's number from another line (eg, my mobile), the incoming call is accepted entirely as normal. When the incoming call is completed, channel 3 will handle outgoing calls for a while. It invariably breaks itself, though.

I've tested in two different PCs, same results.

After a bit of fiddling I came to the conclusion that a polarity reversal was tricking Asterisk into thinking that the line was about to ring, and it was getting stuck listening for Caller ID data.

Both asterisk and zaptel are fresh from CVS, checked out on 2004-11-21. My CVS checkout includes the fix for bug 0002909 ("V23 CID hangs on polarity reversal that is not a RING") but this does not resolve the problem, presumably because the polarity reversal is NOT followed by a second polarity reversal -- without this second reversal, the Caller ID code continues to consume data endlessly. This wastes a small amount of processing time, but more importantly stops the line from being eligible to handle an outgoing call.

My patch is very simple, it makes the Caller ID code abort after processing 15 seconds of data. This seems like a sensible timeout, and it may avoid other similar bugs in the future.

The 15 second figure was a bit of a random guess. Feel free to raise or lower it.
Comments:By: Mark Spencer (markster) 2004-11-22 13:59:36.000-0600

The nature of the fix is correct, but callerid.c is not the right place for it since it's possible that there would be callerid signalling types which would not be preceeded by an event such as a polarity reversal where someone may well want to actually listen the whole time, so I did it in chan_zap.  If this doesn't fix it, feel free to reopen.  Note this is in CVS head only.
By: Digium Subversion (svnbot) 2008-01-15 15:14:40.000-0600

Repository: asterisk
Revision: 4315

U   trunk/channels/chan_zap.c

------------------------------------------------------------------------
r4315 | markster | 2008-01-15 15:14:40 -0600 (Tue, 15 Jan 2008) | 2 lines

Don't allow more than 10 seconds of audio for callerid (bug ASTERISK-2869)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4315