Re: [asterisk-users] PRI issue its BUSY
hi: make sure your pri is up and active. Best regards, James.zhu Doing asterisk/PRI/ss7/dahdi, linux, asterisk cards, gateway(fxs/fxo/pri-SIP). website: www.voipviews.com From: ca...@usawide.net To: asterisk-users@lists.digium.com Date: Mon, 6 Jun 2011 20:24:06 -0500 Subject: Re: [asterisk-users] PRI issue its BUSY From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of satish patel Sent: Monday, June 06, 2011 8:20 PM To: asterisk-users Subject: [asterisk-users] PRI issue its BUSY Hi all, I just configures my PRI and incoming calls are working fine but outside calling giving error PRI is BUSY :( any idea ? I have same setup on other box and that boxes works perfect. -- DAHDI/i1/6463279153-2 is proceeding passing it to SIP/7328-0002 -- DAHDI/i1/6463279153-2 is making progress passing it to SIP/7328-0002 -- DAHDI/i1/6463279153-2 is busy -- Hungup 'DAHDI/i1/6463279153-2' == Everyone is busy/congested at this time (1:1/0/0) -- Auto fallthrough, channel 'SIP/7328-0002' status is 'BUSY' Maybe the problem is external to the box. Try swapping PRIs briefly for testing. C. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI issue its BUSY
sometime i am getting Span 1: Channel 0/23 got hangup request, cause 16 but my call doesn't get completed == Primary D-Channel on span 1 up -- Restart requested on entire span 1 == Using SIP RTP CoS mark 5 -- Executing [7076941815@from-sip:1] Dial(SIP/7328-0004, DAHDI/G1/17076941815) in new stack -- Requested transfer capability: 0x00 - SPEECH -- Called DAHDI/G1/17076941815 -- DAHDI/i1/17076941815-4 is proceeding passing it to SIP/7328-0004 -- DAHDI/i1/17076941815-4 is ringing -- DAHDI/i1/17076941815-4 is making progress passing it to SIP/7328-0004 -- DAHDI/i1/17076941815-4 answered SIP/7328-0004 -- Span 1: Channel 0/23 got hangup request, cause 16 -- Executing [h@from-sip:1] Hangup(SIP/7328-0004, ) in new stack == Spawn extension (from-sip, h, 1) exited non-zero on 'SIP/7328-0004' From: ca...@usawide.net To: asterisk-users@lists.digium.com Date: Mon, 6 Jun 2011 20:24:06 -0500 Subject: Re: [asterisk-users] PRI issue its BUSY From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of satish patel Sent: Monday, June 06, 2011 8:20 PM To: asterisk-users Subject: [asterisk-users] PRI issue its BUSY Hi all, I just configures my PRI and incoming calls are working fine but outside calling giving error PRI is BUSY :( any idea ? I have same setup on other box and that boxes works perfect. -- DAHDI/i1/6463279153-2 is proceeding passing it to SIP/7328-0002 -- DAHDI/i1/6463279153-2 is making progress passing it to SIP/7328-0002 -- DAHDI/i1/6463279153-2 is busy -- Hungup 'DAHDI/i1/6463279153-2' == Everyone is busy/congested at this time (1:1/0/0) -- Auto fallthrough, channel 'SIP/7328-0002' status is 'BUSY' Maybe the problem is external to the box. Try swapping PRIs briefly for testing. C. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI issue its BUSY
This is wired.. If i connect my old asterisk 1.2 box my PRI working great! all inbound outbound calls.. But its not working with asterisk 1.8 :( ( i can call in but not out) From: satish...@hotmail.com To: asterisk-users@lists.digium.com Date: Tue, 7 Jun 2011 02:11:28 + Subject: Re: [asterisk-users] PRI issue its BUSY sometime i am getting Span 1: Channel 0/23 got hangup request, cause 16 but my call doesn't get completed == Primary D-Channel on span 1 up -- Restart requested on entire span 1 == Using SIP RTP CoS mark 5 -- Executing [7076941815@from-sip:1] Dial(SIP/7328-0004, DAHDI/G1/17076941815) in new stack -- Requested transfer capability: 0x00 - SPEECH -- Called DAHDI/G1/17076941815 -- DAHDI/i1/17076941815-4 is proceeding passing it to SIP/7328-0004 -- DAHDI/i1/17076941815-4 is ringing -- DAHDI/i1/17076941815-4 is making progress passing it to SIP/7328-0004 -- DAHDI/i1/17076941815-4 answered SIP/7328-0004 -- Span 1: Channel 0/23 got hangup request, cause 16 -- Executing [h@from-sip:1] Hangup(SIP/7328-0004, ) in new stack == Spawn extension (from-sip, h, 1) exited non-zero on 'SIP/7328-0004' From: ca...@usawide.net To: asterisk-users@lists.digium.com Date: Mon, 6 Jun 2011 20:24:06 -0500 Subject: Re: [asterisk-users] PRI issue its BUSY From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of satish patel Sent: Monday, June 06, 2011 8:20 PM To: asterisk-users Subject: [asterisk-users] PRI issue its BUSY Hi all, I just configures my PRI and incoming calls are working fine but outside calling giving error PRI is BUSY :( any idea ? I have same setup on other box and that boxes works perfect. -- DAHDI/i1/6463279153-2 is proceeding passing it to SIP/7328-0002 -- DAHDI/i1/6463279153-2 is making progress passing it to SIP/7328-0002 -- DAHDI/i1/6463279153-2 is busy -- Hungup 'DAHDI/i1/6463279153-2' == Everyone is busy/congested at this time (1:1/0/0) -- Auto fallthrough, channel 'SIP/7328-0002' status is 'BUSY' Maybe the problem is external to the box. Try swapping PRIs briefly for testing. C. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] PRI ISSUE
hello everyone, Last week I installed asterisk 1.2.24 with digium TE220B card. I have a problem with our PRI and Asterisk: the call be interrupted.It happens either PSTN-to-SIP or SIP-to-SIP,almost every call. After spending several days searching on internet, I found a lot of discussion about this issue and I have tried many, but it still.I am totally new to Asterisk environment and suspect I am missing something somewhere :( I would welcome any suggestions you may have. Thank you in advance! here is the log .conf : LOG1: Feb 3 18:29:39 DEBUG[21583] chan_sip.c: Auto destroying call '[EMAIL PROTECTED]' Feb 3 18:29:43 DEBUG[21583] chan_sip.c: Auto destroying call '[EMAIL PROTECTED]' Feb 3 18:29:44 DEBUG[21583] chan_sip.c: Auto destroying call '[EMAIL PROTECTED]' Feb 3 18:29:44 DEBUG[21583] chan_sip.c: Auto destroying call '[EMAIL PROTECTED]' Feb 3 18:29:44 DEBUG[21583] chan_sip.c: Stopping retransmission on '[EMAIL PROTECTED]' of Request 102: Match Found Feb 3 18:29:47 DEBUG[21583] chan_sip.c: Stopping retransmission on '[EMAIL PROTECTED]' of Request 102: Match Found Feb 3 18:29:47 DEBUG[21583] chan_sip.c: Stopping retransmission on '[EMAIL PROTECTED]' of Request 102: Match Found Feb 3 18:29:48 DEBUG[21583] chan_sip.c: Stopping retransmission on '[EMAIL PROTECTED]' of Request 102: Match Found ##On internet someone saied it's normal infomation, is it right? LOG2: Feb 3 18:29:08 NOTICE[21587] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 2 Feb 3 18:29:08 NOTICE[21587] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 2 Feb 3 18:29:08 NOTICE[21587] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 2 Feb 3 18:29:08 NOTICE[21587] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 2 Feb 3 18:29:08 NOTICE[21587] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 2 Feb 3 18:29:08 NOTICE[21587] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 2 Feb 3 18:29:08 NOTICE[21587] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 2 Feb 3 18:29:08 NOTICE[21587] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 2 #I get the log even no one use the asterisk. some one saied this because the network card and harddisk taking an interrupt for too long.This will cause the calls to be drop. But how can I stop it? I have disabled the inbound/outbound recordings,disabled some modules not used, but the issue still.. call interrupt: Feb 3 15:01:16 VERBOSE[5956] logger.c: Ext: 1 User information layer 1: A-Law (35) Feb 3 15:01:16 VERBOSE[5956] logger.c: [18 03 a9 83 81] Feb 3 15:01:16 VERBOSE[5956] logger.c: Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 Feb 3 15:01:16 VERBOSE[5956] logger.c: ChanSel: Reserved Feb 3 15:01:16 VERBOSE[5956] logger.c:Ext: 1 Coding: 0 Number Specified Channel Type: 3 Feb 3 15:01:16 VERBOSE[5956] logger.c:Ext: 1 Channel: 1 ] Feb 3 15:01:16 VERBOSE[5956] logger.c: [6c 0a 00 80 38 34 32 36 38 35 39 39] Feb 3 15:01:16 VERBOSE[5956] logger.c: Calling Number (len=12) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) Feb 3 15:01:16 VERBOSE[5956] logger.c: Presentation: Presentation permitted, user number not screened (0) '84268599' ] Feb 3 15:01:16 VERBOSE[5956] logger.c: [70 09 80 38 35 37 34 30 38 34 38] Feb 3 15:01:16 VERBOSE[5956] logger.c: Called Number (len=11) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '85740848' ] Feb 3 15:02:12 DEBUG[5956] chan_zap.c: Exception on 45, channel 32 Feb 3 15:02:12 DEBUG[5956] chan_zap.c: Got event Alarm(4) on channel 32 (index 0) Feb 3 15:02:12 VERBOSE[5956] logger.c: NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Connect Request Feb 3 15:02:12 VERBOSE[5956] logger.c: Protocol Discriminator: Q.931 (8) len=9 Feb 3 15:02:12 VERBOSE[5956] logger.c: Call Ref: len= 2 (reference 173/0xAD) (Originator) Feb 3 15:02:12 VERBOSE[5956] logger.c: Message type: DISCONNECT (69) Feb 3 15:02:12 VERBOSE[5956] logger.c: [08 02 81 90] Feb 3 15:02:12 VERBOSE[5956] logger.c: Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Feb 3 15:02:12 VERBOSE[5956] logger.c: Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] Feb 3 15:02:12 VERBOSE[5956] logger.c: NEW_HANGUP DEBUG: Destroying the call, ourstate Disconnect Request, peerstate Disconnect Indication Feb 3 15:02:12 WARNING[5956] chan_zap.c: Detected alarm on channel 32: Recovering Feb 3 15:02:12 DEBUG[5956] chan_zap.c: disabled echo cancellation on channel 32 Feb 3 15:02:12 DEBUG[5956] channel.c: Didn't get a frame from
Re: [Asterisk-Users] PRI Issue - Calls being rejected with unacceptable channel
On 06/23/06 01:22 Andy Brezinsky said the following: Protocol Discriminator: Q.931 (8) len=47 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: SETUP (5) Protocol Discriminator: Q.931 (8) len=10 Call Ref: len= 2 (reference 48764/0xBE7C) (Terminator) Message type: CALL PROCEEDING (2) Protocol Discriminator: Q.931 (8) len=14 Call Ref: len= 2 (reference 48764/0xBE7C) (Terminator) Message type: CONNECT (7) i may be way offbase with this, but on our PRI calls, we usually have asterisk sending an ALERTING between the CALL PROCEEDING and CONNECT. this seems borne out by... Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: RELEASE (77) Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: STATUS (125) [08 03 83 e5 07] Cause (len= 5) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Transit network (3) Ext: 1 Cause: Message not compatible with call state (101), class = Protocol Error (6) ] ...Message not compatible with call state STATUS returned by the other side. you may want to experiment with a Wait(2) before the Answer(). -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] PRI Issue - Calls being rejected with unacceptable channel
Hey all. We have a DS3 circuit with GBLX split off into 7 systems with a 4 port sangoma card (A104D) in the first 2 systems, and digium T410P cards in the other 5. GBLX numbers their spans from 0 to 3 instead of 1-4 and we have a NFAS configuration with the d-channel on chan 96. All of our systems are running 1.0.7 for stability reasons (and no good time for maintaince, the entire platform is used most of the day) but if an upgrade will help us, we'll schedule it soon. We've recently been experiencing people not being able to get in. We have a hunt group tied in over our 7 trunks which will roll them if a trunk is busy or out of order. It seems that call comes into this termination system (see trace below), we fire back a Cause: Channel unacceptable (6) event to GBLX and they try the next system, even if this system isn't busy. Because of this, calls can eventually try all 7 systems, get rejected, and then users get busy messages even though we're not at total capacity yet. Below I've attached the entire pri debug of one of these events happening. Can anyone shed some light on where we should be looking to fix this stuff? milwia1-terma-2*CLI pri debug span 4 Enabled debugging on span 4 Protocol Discriminator: Q.931 (8) len=47 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: SETUP (5) [04 03 80 90 a2] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1 User information layer 1: u-Law (34) [18 04 e9 80 83 8e] Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 DS1 Identifier: 0 Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 14 ] [1e 02 81 83] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Calling equipment is non-ISDN. (3) ] [6c 0c 21 81 33 32 33 38 30 31 37 39 37 30] Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) Presentation: Presentation permitted, user number passed network screening (1) '323801' ] [70 0b a1 38 30 30 39 37 38 37 32 37 39] Called Number (len=13) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '800978' ] -- Making new call for cr 15996 -- Processing Q.931 Call Setup -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 30 (cs0, Progress Indicator) -- Processing IE 108 (cs0, Calling Party Number) -- Processing IE 112 (cs0, Called Party Number) Protocol Discriminator: Q.931 (8) len=10 Call Ref: len= 2 (reference 48764/0xBE7C) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 8e] Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 14 ] -- Accepting voice call from '323801' to '800978' on channel 0/14, span 4 -- Executing SetVar(Zap/14-1, SERVER_ID=2) in new stack -- Executing Answer(Zap/14-1, ) in new stack Protocol Discriminator: Q.931 (8) len=14 Call Ref: len= 2 (reference 48764/0xBE7C) (Terminator) Message type: CONNECT (7) [18 03 a9 83 8e] Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 14 ] [1e 02 81 82] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ] -- Executing AGI(Zap/14-1, incoming_call.pl) in new stack -- Launched AGI Script /var/lib/asterisk/agi-bin/incoming_call.pl Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: RELEASE (77) [08 02 83 86] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Transit network (3) Ext: 1 Cause: Channel unacceptable (6), class = Normal Event (0) ] -- Processing IE 8 (cs0, Cause) -- Channel 0/14, span 4 got hangup Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: STATUS (125) [08 03 83 e5 07] Cause (len= 5) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Transit network (3) Ext: 1 Cause: Message not
Re: [Asterisk-Users] PRI Issue - Calls being rejected with unacceptable channel
Andy Brezinsky wrote: Hey all. We have a DS3 circuit with GBLX split off into 7 systems with a 4 port sangoma card (A104D) in the first 2 systems, and digium T410P cards in the other 5. GBLX numbers their spans from 0 to 3 instead of 1-4 and we have a NFAS configuration with the d-channel on chan 96. All of our systems are running 1.0.7 for stability reasons (and no good time for maintaince, the entire platform is used most of the day) but if an upgrade will help us, we'll schedule it soon. We've recently been experiencing people not being able to get in. We have a hunt group tied in over our 7 trunks which will roll them if a trunk is busy or out of order. It seems that call comes into this termination system (see trace below), we fire back a Cause: Channel unacceptable (6) event to GBLX and they try the next system, even if this system isn't busy. Because of this, calls can eventually try all 7 systems, get rejected, and then users get busy messages even though we're not at total capacity yet. Below I've attached the entire pri debug of one of these events happening. Can anyone shed some light on where we should be looking to fix this stuff? milwia1-terma-2*CLI pri debug span 4 Enabled debugging on span 4 Protocol Discriminator: Q.931 (8) len=47 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: SETUP (5) [04 03 80 90 a2] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1 User information layer 1: u-Law (34) [18 04 e9 80 83 8e] Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 DS1 Identifier: 0 Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 14 ] [1e 02 81 83] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Calling equipment is non-ISDN. (3) ] [6c 0c 21 81 33 32 33 38 30 31 37 39 37 30] Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) Presentation: Presentation permitted, user number passed network screening (1) '323801' ] [70 0b a1 38 30 30 39 37 38 37 32 37 39] Called Number (len=13) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '800978' ] -- Making new call for cr 15996 -- Processing Q.931 Call Setup -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 30 (cs0, Progress Indicator) -- Processing IE 108 (cs0, Calling Party Number) -- Processing IE 112 (cs0, Called Party Number) Protocol Discriminator: Q.931 (8) len=10 Call Ref: len= 2 (reference 48764/0xBE7C) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 8e] Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 14 ] -- Accepting voice call from '323801' to '800978' on channel 0/14, span 4 -- Executing SetVar(Zap/14-1, SERVER_ID=2) in new stack -- Executing Answer(Zap/14-1, ) in new stack Protocol Discriminator: Q.931 (8) len=14 Call Ref: len= 2 (reference 48764/0xBE7C) (Terminator) Message type: CONNECT (7) [18 03 a9 83 8e] Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 14 ] [1e 02 81 82] Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ] -- Executing AGI(Zap/14-1, incoming_call.pl) in new stack -- Launched AGI Script /var/lib/asterisk/agi-bin/incoming_call.pl Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: RELEASE (77) [08 02 83 86] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Transit network (3) Ext: 1 Cause: Channel unacceptable (6), class = Normal Event (0) ] -- Processing IE 8 (cs0, Cause) -- Channel 0/14, span 4 got hangup Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 15996/0x3E7C) (Originator) Message type: STATUS (125) [08 03 83 e5 07] Cause (len= 5) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Transit network (3) Ext: 1
Re: [Asterisk-Users] PRI Issue: D-Channel woes
Terence Burnard wrote: # cat /etc/zaptel.conf span=1,0,0,esf,b8zs bchan=1-23 dchan=24 loadzone=us defaultzone=us I don't know if this will fix your problem, but the span line should read: span=1,1,0,esf,b8zs You get your timing from the telco. Doug -- Ben Franklin quote: Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] PRI Issue: D-Channel woes
On Monday 01 May 2006 01:42, Terence Burnard wrote: Module Size Used by wcusb 21760 0 wctdm 36512 0 wcfxo 13408 0 wcte11xp 24896 0 wct1xxp16544 0 wct4xxp97664 24 tor2 89856 0 First of all, don't load every Asterisk module under the sun. Load the modules for the hardware you have, and if you're using something like [EMAIL PROTECTED] which loads everything, edit your /etc/modules.conf to alias the ones you do NOT have to 'off' to prevent them from being loaded. # cat /etc/zaptel.conf span=1,0,0,esf,b8zs That should read '1,1,0' but is otherwise great. You want to synchronize to the telco. [channels] context=pri_inbound switchtype=dms100 signalling=pri_cpe group=1 channel = 1-23 I generally add pridialplan=unknown priindication=outofband overlapdial=no resetinterval=86400 to that as well (i.e. before the channel = line) to make things a little cleaner and clearer. Only the first line would have any effect on mitigating your problem, though. *CLI pri show span 1 Primary D-channel: 24 Status: Provisioned, Down, Active That's the problem: your D channel is not up. Either your switchtype is wrong (it is NOT set to the physical switch make/model on the other side, it is set to the signaling system it is emulating), the telco's brought the line down, or the two sides just can't see each other. Since you're running green-light, you're seeing each other. You can do a very simple test by plugging a loopback plug into the span instead of the PRI. just take an RJ45 end and two pieces of wire. plug one wire into pins 1 and 4, and the other into 2 and 5. Crimp it down and plug it in. The light on the back of the card should go green and the system should be in the exact same state it's in now. If you change your signalling to pri_net, you should see messages on the Asterisk console complaining about I'm set to pri_net, but the other side thinks it is pri_net!. Verify your switchtype... The Cisco should have a setting and you should set Asterisk in a similar fashion. Failing that I would try loading the wct4xxp module with the vpmsupport=0 parameter to disable the voice processing module just to see if that helps (i.e. possible card issue), and failing all of that, I would contact Digium technical support, as the price of that card included technical assistance and it is this type of problem that is a great use of that support. -A. ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] PRI Issue: D-Channel woes
Andrew Kohlsmith wrote: First of all, don't load every Asterisk module under the sun. Load the modules for the hardware you have, and if you're using something like [EMAIL PROTECTED] which loads everything, edit your /etc/modules.conf to alias the ones you do NOT have to 'off' to prevent them from being loaded. I believe you mean _Zaptel_ module, not _Asterisk_ module, in this case :-) ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] PRI Issue: D-Channel woes
On Monday 01 May 2006 07:27, Kevin P. Fleming wrote: I believe you mean _Zaptel_ module, not _Asterisk_ module, in this case :-) Ahh yes, you are correct. Place blame where due. :-) -A. ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] PRI Issue: D-Channel woes
Hi, I am about to pull my hair out after trying to get our PRI up and working. We are switching from a Cisco gateway to an Asterisk box which provides the 23 phone lines for our office. So, because the Cisco gateway is working I can assume I have all the settings right (b8zs, esf, dms100, etc) and the PRI is live (because we are switching over). When dialing from PSTN, I get busy signal. When dialing to the PSTN from the asterisk box I get the following error: == Primary D-Channel on span 1 down Apr 30 23:29:32 WARNING[12830]: chan_zap.c:2290 pri_find_dchan: No D-channels available! Using Primary channel 24 as D-channel anyway! -- Hungup 'Zap/1-1' == Everyone is busy/congested at this time (1:0/0/1) Below is the relevant information, if anyone could assist me at all it would be greatly appreciated. Thanks, Terence # lsmod Module Size Used by wcusb 21760 0 wctdm 36512 0 wcfxo 13408 0 wcte11xp 24896 0 wct1xxp16544 0 wct4xxp97664 24 tor2 89856 0 zaptel188452 59 wcusb,wctdm,wcfxo,wcte11xp,wct1xxp,wct4xxp,tor2 hdlc 23552 0 lapb 13312 1 hdlc syncppp14076 1 hdlc ipv6 221696 12 ip_vs 71392 0 joydev 8864 0 evdev 8800 0 crc_ccitt 1952 1 zaptel mousedev 10496 0 psmouse32356 0 serio_raw 6468 0 i2c_i8017916 0 shpchp 39712 0 pci_hotplug24756 1 shpchp i2c_core 19280 1 i2c_i801 rtc11316 0 pcspkr 1668 0 ext3 117768 2 jbd48404 1 ext3 mbcache 8484 1 ext3 ide_generic 1120 0 [permanent] ide_cd 36484 0 cdrom 33280 1 ide_cd sd_mod 17136 4 piix8964 0 [permanent] ata_piix8964 3 libata 51020 1 ata_piix scsi_mod 125736 2 sd_mod,libata ehci_hcd 28904 0 tg389540 0 generic 4260 0 [permanent] ide_core 112800 4 ide_generic,ide_cd,piix,generic uhci_hcd 28016 0 usbcore 113284 4 wcusb,ehci_hcd,uhci_hcd thermal13416 0 processor 22912 1 thermal fan 4580 0 # cat /proc/interrupts CPU0 0:3517028IO-APIC-edge timer 1: 12IO-APIC-edge i8042 4: 5IO-APIC-edge serial 8: 0IO-APIC-edge rtc 9: 1 IO-APIC-level acpi 14: 64IO-APIC-edge ide0 50: 14624 IO-APIC-level uhci_hcd:usb1, libata, ehci_hcd:usb4 66:3479230 IO-APIC-level wct4xxp 169: 37440 IO-APIC-level eth0 177: 0 IO-APIC-level uhci_hcd:usb2 185: 0 IO-APIC-level uhci_hcd:usb3 NMI: 0 LOC:3517023 ERR: 0 MIS: 0 # cat /proc/zaptel/1 Span 1: TE4/0/1 T4XXP (PCI) Card 0 Span 1 B8ZS/ESF ClockSource 1 TE4/0/1/1 Clear (In use) 2 TE4/0/1/2 Clear (In use) 3 TE4/0/1/3 Clear (In use) 4 TE4/0/1/4 Clear (In use) 5 TE4/0/1/5 Clear (In use) 6 TE4/0/1/6 Clear (In use) 7 TE4/0/1/7 Clear (In use) 8 TE4/0/1/8 Clear (In use) 9 TE4/0/1/9 Clear (In use) 10 TE4/0/1/10 Clear (In use) 11 TE4/0/1/11 Clear (In use) 12 TE4/0/1/12 Clear (In use) 13 TE4/0/1/13 Clear (In use) 14 TE4/0/1/14 Clear (In use) 15 TE4/0/1/15 Clear (In use) 16 TE4/0/1/16 Clear (In use) 17 TE4/0/1/17 Clear (In use) 18 TE4/0/1/18 Clear (In use) 19 TE4/0/1/19 Clear (In use) 20 TE4/0/1/20 Clear (In use) 21 TE4/0/1/21 Clear (In use) 22 TE4/0/1/22 Clear (In use) 23 TE4/0/1/23 Clear (In use) 24 TE4/0/1/24 HDLCFCS (In use) # ztcfg - Zaptel Configuration == SPAN 1: ESF/B8ZS Build-out: 0 db (CSU)/0-133 feet (DSX-1) Channel map: Channel 01: Clear channel (Default) (Slaves: 01) Channel 02: Clear channel (Default) (Slaves: 02) Channel 03: Clear channel (Default) (Slaves: 03) Channel 04: Clear channel (Default) (Slaves: 04) Channel 05: Clear channel (Default) (Slaves: 05) Channel 06: Clear channel (Default) (Slaves: 06) Channel 07: Clear channel (Default) (Slaves: 07) Channel 08: Clear channel (Default) (Slaves: 08) Channel 09: Clear channel (Default) (Slaves: 09) Channel 10: Clear channel (Default) (Slaves: 10) Channel 11: Clear channel (Default) (Slaves: 11) Channel 12: Clear channel (Default) (Slaves: 12) Channel 13: Clear channel (Default) (Slaves: 13) Channel 14: Clear channel (Default) (Slaves: 14) Channel 15: Clear
[Asterisk-Users] PRI issue
Hi, I recompiled asterisk today from CVS and Ive been having a number of problems, Ive read the deadlock page on the wiki and some of it sounds like that, however, the latest issue were having it that sometimes Asterisk doesnt seem to know the PRI channel has dropped, and assumes its still busy. However, that same channel can be used to make an outgoing call?! Has anyone experienced anything similar? Regards, Ben ___ 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] PRI issue
Ben, I ran into a similar issue on the 8/31 cvs, except it was backwards. Outbound calls would report a busy on the channel selected, yet a few minutes later the channel would be used for an inbound call. I had to revert back to my previous checkout from 8/16 to resolve the issue. The problems didn't break the channels completely, it happened probably every 5-10 minutes. Brian D'Arcy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Merrills Sent: Wednesday, September 08, 2004 7:51 AM To: [EMAIL PROTECTED] Subject: [Asterisk-Users] PRI issue Hi, I recompiled asterisk today from CVS and I've been having a number of problems, I've read the deadlock page on the wiki and some of it sounds like that, however, the latest issue we're having it that sometimes Asterisk doesn't seem to know the PRI channel has dropped, and assumes it's still busy. However, that same channel can be used to make an outgoing call?! Has anyone experienced anything similar? Regards, Ben ___ 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] PRI issue
I think this issues stems from the (in my case) wct4xxp driver. When updating libpri, I also updated zaptel, however, I'm unsure if I installed it correctly (i.e. updated to the newly compiled version). After stopping asterisk, doing rmmod wct4xxp, make install on zaptel and then restarting asterisk, so far, it seems to be working. I'm not 100% sure this is the problem, but it would seem this resolved the issue... time will tell :) Cheers, Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian D'Arcy Sent: 08 September 2004 16:34 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: [Asterisk-Users] PRI issue Ben, I ran into a similar issue on the 8/31 cvs, except it was backwards. Outbound calls would report a busy on the channel selected, yet a few minutes later the channel would be used for an inbound call. I had to revert back to my previous checkout from 8/16 to resolve the issue. The problems didn't break the channels completely, it happened probably every 5-10 minutes. Brian D'Arcy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Merrills Sent: Wednesday, September 08, 2004 7:51 AM To: [EMAIL PROTECTED] Subject: [Asterisk-Users] PRI issue Hi, I recompiled asterisk today from CVS and I've been having a number of problems, I've read the deadlock page on the wiki and some of it sounds like that, however, the latest issue we're having it that sometimes Asterisk doesn't seem to know the PRI channel has dropped, and assumes it's still busy. However, that same channel can be used to make an outgoing call?! Has anyone experienced anything similar? Regards, Ben ___ 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 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
