Andy Brezinsky
2006-Jun-22 10:22 UTC
[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) '323801XXXX' ]
< [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) '800978XXXX' ]
-- 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 '323801XXXX' to '800978XXXX' 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 compatible with call state
(101), class = Protocol Error (6) ]
< Cause data 1: 07 (7)
< [14 01 13]
< Call State (len= 3) [ Ext: 0 Coding: CCITT (ITU) standard (0) Call
state: Release Request (19)
-- Processing IE 8 (cs0, Cause)
-- Processing IE 20 (cs0, Call State)
-- Executing DeadAGI("Zap/14-1", "disconnect_call.pl")
in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/disconnect_call.pl
-- AGI Script disconnect_call.pl completed, returning 0
-- Executing Hangup("Zap/14-1", "") in new stack
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release
Request
> Protocol Discriminator: Q.931 (8) len=9
> Call Ref: len= 2 (reference 48764/0xBE7C) (Terminator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0
Location: Private network serving the local user (1)
> Ext: 1 Cause: Normal Clearing (16), class = Normal
Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
-- Hungup 'Zap/14-1'
Steve Totaro
2006-Jun-22 11:28 UTC
[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) '323801XXXX' ] > < [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) '800978XXXX' ] > -- 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 '323801XXXX' to '800978XXXX' 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 compatible with call > state (101), class = Protocol Error (6) ] > < Cause data 1: 07 (7) > < [14 01 13] > < Call State (len= 3) [ Ext: 0 Coding: CCITT (ITU) standard (0) Call > state: Release Request (19) > -- Processing IE 8 (cs0, Cause) > -- Processing IE 20 (cs0, Call State) > -- Executing DeadAGI("Zap/14-1", "disconnect_call.pl") in new stack > -- Launched AGI Script /var/lib/asterisk/agi-bin/disconnect_call.pl > -- AGI Script disconnect_call.pl completed, returning 0 > -- Executing Hangup("Zap/14-1", "") in new stack > NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate > Release Request > > Protocol Discriminator: Q.931 (8) len=9 > > Call Ref: len= 2 (reference 48764/0xBE7C) (Terminator) > > Message type: RELEASE COMPLETE (90) > > [08 02 81 90] > > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 > Location: Private network serving the local user (1) > > Ext: 1 Cause: Normal Clearing (16), class = Normal > Event (1) ] > NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null > NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null > -- Hungup 'Zap/14-1' > _______________________________________________ > --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 >What are the perl scripts and the AGI? This is exactly the same setup I have but all Sangoma cards. I even have global crossing for the T3.
Dinesh Nair
2006-Jun-23 01:48 UTC
[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." dinesh@alphaque.com (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 | +=========================================================================+