Re: [Asterisk-Users] TDM400 FXO stops handling outgoing calls, but still accepts incoming?
Having read through the Caller ID code, it appears that this is indeed what is
happening. The Caller ID code doesn't contain any logic to trigger a timeout
if no Caller ID data stream is found, or if a stream starts and does not
terminate.
The attached patch causes the Caller ID to timeout after processing around 15
seconds of data. I assume that this should be quite long enough, but I am no
Caller ID expert!
I've tested this patch with BT's automated line test (dial 17070, options 3,
1, 2). It appears to work fine:
== Starting post polarity CID detection on channel 3
-- Starting simple switch on 'Zap/3-1'
Nov 22 13:16:03 NOTICE[7862]: chan_zap.c:5257 ss_thread: Got event 17 (Polarity
Reversal)...
Nov 22 13:16:13 ERROR[7862]: callerid.c:257 callerid_feed: Caller ID processed
120160 samples, giving up.
Nov 22 13:16:13 WARNING[7862]: chan_zap.c:5272 ss_thread: CallerID feed failed:
Success
Nov 22 13:16:13 WARNING[7862]: chan_zap.c:5284 ss_thread: CallerID returned
with error on channel 'Zap/3-1'
Nov 22 13:16:15 WARNING[7862]: chan_zap.c:5293 ss_thread: CID timed out waiting
for ring. Exiting simple switch
-- Hungup 'Zap/3-1'
Mark, how do I go about getting this included in CVS?
Thanks,
Will
On Sun, Nov 21, 2004 at 10:34:27PM +, William R Sowerbutts wrote:
H.
Is it possible that the line is detecting a polarity event, decided that the
line is ringing and started listening for a non-existant V23 data stream, and
then the line has not in fact rung?
This would mark the line as busy (and unable to handle an outgoing call) but
when a call did in fact come in the line would then ring correctly.
I believe BT's automated testing equipment can produce these line conditions.
Will
_
William R Sowerbutts [EMAIL PROTECTED]
Carpe post meridiem http://sowerbutts.com
main(){char*s=#=0 [EMAIL PROTECTED]@^7=,c=0,m;for(;c15;c++)for
(m=-1;m7;putchar(m++/6c%3/2?10:s[c]-311m?42:32));}
--- asterisk/callerid.c.orig2004-11-22 13:01:33.0 +
+++ asterisk/callerid.c 2004-11-22 13:01:59.0 +
@@ -43,6 +43,7 @@
int flags;
int sawflag;
int len;
+ int eaten;
};
@@ -132,6 +133,7 @@
cid-fskd.cont = 0; /* Digital PLL reset */
cid-fskd.x0 = 0.0;
cid-fskd.state = 0;
+ cid-eaten = 0;
memset(cid-name, 0, sizeof(cid-name));
memset(cid-number, 0, sizeof(cid-number));
cid-flags = CID_UNKNOWN_NAME | CID_UNKNOWN_NUMBER;
@@ -249,6 +251,12 @@
ast_log(LOG_WARNING, Out of memory\n);
return -1;
}
+ cid-eaten += len;
+ if(cid-eaten (8000 * 15)){
+ /* we've eaten over 15 seconds of data */
+ ast_log(LOG_ERROR, Caller ID processed %d samples, giving up.\n,
cid-eaten);
+ return -1;
+ }
memset(buf, 0, 2 * len + cid-oldlen);
memcpy(buf, cid-oldstuff, cid-oldlen);
mylen += cid-oldlen/2;
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] TDM400 FXO stops handling outgoing calls, but still accepts incoming?
Hi Will, snip Having read through the Caller ID code, it appears that this is indeed what is happening. The Caller ID code doesn't contain any logic to trigger a timeout if no Caller ID data stream is found, or if a stream starts and does not terminate. /snip I submitted a patch for this which was included in the the CVS build of the 19th of November. See bug http://bugs.digium.com/bug_view_page.php?bug_id=0002909 Regards Ian ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] TDM400 FXO stops handling outgoing calls, but still accepts incoming?
On Mon, Nov 22, 2004 at 04:09:21PM -, Ian D. Wlloughby wrote:
I submitted a patch for this which was included in the the CVS build of
the 19th of November.
See bug http://bugs.digium.com/bug_view_page.php?bug_id=0002909
Ian,
The code I am running includes this patch already (I checked it out from CVS
on the 21st), and it does not seem to resolve the problem on my line.
The patch I have posted earlier today, which causes the Caller-ID code to
abort after 15 seconds, does resolve the problem.
I think applying both patches should be fine -- the belt and braces approach!
I'll append my patch to bug 0002909.
Thanks,
Will
_
William R Sowerbutts [EMAIL PROTECTED]
Carpe post meridiem http://sowerbutts.com
main(){char*s=#=0 [EMAIL PROTECTED]@^7=,c=0,m;for(;c15;c++)for
(m=-1;m7;putchar(m++/6c%3/2?10:s[c]-311m?42:32));}
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] TDM400 FXO stops handling outgoing calls, but still accepts incoming?
Ian, The code I am running includes this patch already (I checked it out from CVS on the 21st), and it does not seem to resolve the problem on my line. The patch I have posted earlier today, which causes the Caller-ID code to abort after 15 seconds, does resolve the problem. Hmmm, it should bail out when you get Event 17. This was the patch I put in if you get an event then bail. Here is my log:- Nov 21 16:19:04 VERBOSE[1974]: == Starting post polarity CID detection on channel 4 Nov 21 16:19:04 NOTICE[28670]: Got event 17 (Polarity Reversal)... Nov 21 16:19:06 WARNING[28670]: CID timed out waiting for ring. Exiting simple switch Which looks the same as yours so I am confuse as to why yours isn't bailing as the code is in the same if block as the Got event 17. Are you using V23 and Polarity Reversal as this is the only bit of code I changed, the Bell stuff already had conditions to allow it to bail out. R's Ian ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] TDM400 FXO stops handling outgoing calls, but still accepts incoming?
I have a bit of a weird problem that I'm having great trouble debugging.
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. Both asterisk and zaptel are fresh from CVS.
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.
One point, not sure if it's related: In order to make remote disconnect
supervision work with my BT line, I've had to modify the wctdm (previously
wcfxs) driver slightly; I had to raise BATT_THRESH to 8. Without this
modification, the FXO modules cannot detect the loss of battery used to
indicate that the remote party has terminated the call. Ideally I'd prefer to
not make this modification, but without it remote disconnect supervision
doesn't work.
I assume that some event is happening to tie up the channel. How can I get
Asterisk to dump a full log of all events on the zap channels for debugging
purposes?
Any help would be greatly appreciated.
Cheers,
Will
_
William R Sowerbutts [EMAIL PROTECTED]
Carpe post meridiem http://sowerbutts.com
main(){char*s=#=0 [EMAIL PROTECTED]@^7=,c=0,m;for(;c15;c++)for
(m=-1;m7;putchar(m++/6c%3/2?10:s[c]-311m?42:32));}
;
; Zapata telephony interface
;
; Configuration file
[trunkgroups]
;
; Trunk groups are used for NFAS or GR-303 connections.
;
; Group: Defines a trunk group.
;group = trunkgroup,dchannel[,backup1...]
;
;trunkgroup is the numerical trunk group to create
;dchannelis the zap channel which will have the
;d-channel for the trunk.
;backup1 is an optional list of backup d-channels.
;
;trunkgroup = 1,24,48
;
; Spanmap: Associates a span with a trunk group
;spanmap = zapspan,trunkgroup[,logicalspan]
;
;zapspan is the zap span number to associate
;trunkgroup is the trunkgroup (specified above) for the mapping
;logicalspan is the logical span number within the trunk group to use.
;if unspecified, no logical span number is used.
;
;spanmap = 1,1,1
;spanmap = 2,1,2
;spanmap = 3,1,3
;spanmap = 4,1,4
[channels]
;
; Default language
;
;language=en
;
; Default context
;
context=default
;
; Switchtype: Only used for PRI.
;
; national: National ISDN 2 (default)
; dms100: Nortel DMS100
; 4ess: ATT 4ESS
; 5ess: Lucent 5ESS
; euroisdn: EuroISDN
; ni1:Old National ISDN 1
;
switchtype=national
;
; Some switches (ATT especially) require network specific facility IE
; supported values are currently 'none', 'sdn', 'megacom', 'accunet'
;
;nsf=none
;
; PRI Dialplan: Only RARELY used for PRI.
;
; unknown:Unknown
; private:Private ISDN
; local: Local ISDN
; national: National ISDN
; international: International ISDN
;
;pridialplan=national
;
; Overlap dialing mode (sending overlap digits)
;
;overlapdial=yes
;
; Signalling method (default is fxs). Valid values:
; em: E M
; em_w:E M Wink
; featd: Feature Group D (The fake, Adtran style, DTMF)
; featdmf: Feature Group D (The real thing, MF (domestic, US))
; featb: Feature Group B (MF (domestic, US))
; fxs_ls: FXS (Loop Start)
; fxs_gs: FXS (Ground Start)
; fxs_ks: FXS (Kewl Start)
; fxo_ls: FXO (Loop Start)
; fxo_gs: FXO (Ground Start)
; fxo_ks: FXO (Kewl Start)
; pri_cpe: PRI signalling, CPE side
; pri_net: PRI signalling, Network side
; gr303fxoks_net: GR-303 Signalling, FXO Loopstart, Network side
; gr303fxsks_cpe: GR-303 Signalling, FXS Loopstart, CPE side
; sf: SF (Inband Tone) Signalling
; sf_w: SF Wink
; sf_featd: SF Feature Group D (The fake, Adtran style, DTMF)
; sf_featdmf: SF Feature Group D (The real thing, MF (domestic, US))
; sf_featb: SF Feature Group B (MF (domestic, US))
; The following are used for Radio interfaces:
; fxs_rx: Receive audio/COR on an FXS kewlstart interface (FXO at the channel
bank)
; fxs_tx: Transmit audio/PTT on an FXS loopstart interface (FXO at the channel
bank)
;
Re: [Asterisk-Users] TDM400 FXO stops handling outgoing calls, but still accepts incoming?
H.
Is it possible that the line is detecting a polarity event, decided that the
line is ringing and started listening for a non-existant V23 data stream, and
then the line has not in fact rung?
This would mark the line as busy (and unable to handle an outgoing call) but
when a call did in fact come in the line would then ring correctly.
I believe BT's automated testing equipment can produce these line conditions.
Will
On Sun, Nov 21, 2004 at 07:18:33PM +, William R Sowerbutts wrote:
I have a bit of a weird problem that I'm having great trouble debugging.
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. Both asterisk and zaptel are fresh from CVS.
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.
One point, not sure if it's related: In order to make remote disconnect
supervision work with my BT line, I've had to modify the wctdm (previously
wcfxs) driver slightly; I had to raise BATT_THRESH to 8. Without this
modification, the FXO modules cannot detect the loss of battery used to
indicate that the remote party has terminated the call. Ideally I'd prefer to
not make this modification, but without it remote disconnect supervision
doesn't work.
I assume that some event is happening to tie up the channel. How can I get
Asterisk to dump a full log of all events on the zap channels for debugging
purposes?
Any help would be greatly appreciated.
Cheers,
Will
_
William R Sowerbutts [EMAIL PROTECTED]
Carpe post meridiem http://sowerbutts.com
main(){char*s=#=0 [EMAIL PROTECTED]@^7=,c=0,m;for(;c15;c++)for
(m=-1;m7;putchar(m++/6c%3/2?10:s[c]-311m?42:32));}
;
; Zapata telephony interface
;
; Configuration file
[trunkgroups]
;
; Trunk groups are used for NFAS or GR-303 connections.
;
; Group: Defines a trunk group.
;group = trunkgroup,dchannel[,backup1...]
;
;trunkgroup is the numerical trunk group to create
;dchannelis the zap channel which will have the
;d-channel for the trunk.
;backup1 is an optional list of backup d-channels.
;
;trunkgroup = 1,24,48
;
; Spanmap: Associates a span with a trunk group
;spanmap = zapspan,trunkgroup[,logicalspan]
;
;zapspan is the zap span number to associate
;trunkgroup is the trunkgroup (specified above) for the mapping
;logicalspan is the logical span number within the trunk group to use.
;if unspecified, no logical span number is used.
;
;spanmap = 1,1,1
;spanmap = 2,1,2
;spanmap = 3,1,3
;spanmap = 4,1,4
[channels]
;
; Default language
;
;language=en
;
; Default context
;
context=default
;
; Switchtype: Only used for PRI.
;
; national: National ISDN 2 (default)
; dms100:Nortel DMS100
; 4ess: ATT 4ESS
; 5ess: Lucent 5ESS
; euroisdn: EuroISDN
; ni1:Old National ISDN 1
;
switchtype=national
;
; Some switches (ATT especially) require network specific facility IE
; supported values are currently 'none', 'sdn', 'megacom', 'accunet'
;
;nsf=none
;
; PRI Dialplan: Only RARELY used for PRI.
;
; unknown:Unknown
; private:Private ISDN
; local: Local ISDN
; national: National ISDN
; international: International ISDN
;
;pridialplan=national
;
; Overlap dialing mode (sending overlap digits)
;
;overlapdial=yes
;
; Signalling method (default is fxs). Valid values:
; em: E M
; em_w:E M Wink
; featd: Feature Group D (The fake, Adtran style, DTMF)
; featdmf: Feature Group D (The real thing, MF (domestic, US))
; featb: Feature Group B (MF (domestic, US))
; fxs_ls: FXS (Loop Start)
; fxs_gs: FXS (Ground Start)
; fxs_ks: FXS (Kewl Start)
; fxo_ls: FXO (Loop Start)
; fxo_gs: FXO (Ground Start)
; fxo_ks: FXO (Kewl Start)
; pri_cpe: PRI signalling, CPE side
; pri_net: PRI signalling, Network side
; gr303fxoks_net: GR-303 Signalling, FXO Loopstart, Network side
; gr303fxsks_cpe: GR-303
