Re: [asterisk-users] Asterisk ZAP/DAHDI reads phantom digit on overlap PRI
On Mon, Dec 14, 2009 at 05:32:21AM -0800, Vieri wrote: Hi, I've noticed that a small but meaningful quota of calls from my Alcatel PBX to Asterisk are failing. This does not always happen and it is not easily reproducible but on high traffic I do get a large number of cases. Example: Alcatel PBX extension 7085 calls Asterisk PBX extension 6145 over a PRI E1 link. I see this in the Asterisk log: Dec 14 14:10:31 VERBOSE[11378] logger.c: -- Accepting overlap call from '7085' to '6145' on channel 1/31, span 1 Dec 14 14:10:31 VERBOSE[5558] logger.c: -- Starting simple switch on 'Zap/31-1' Dec 14 14:10:32 DEBUG[5558] chan_zap.c: DTMF digit: 5 on Zap/31-1 Dec 14 14:10:40 DEBUG[5558] chan_zap.c: No such possible extension '61455' in context 'from-alcatel' Obviously, it's failing because Asterisk is trying to match destination+extra DTMF digit (ie. 6145+5). However, noone ever dialed that extra digit! So how did it get there? I guess I could disable overlap in Asterisk but that isn't the right way to go. What else can I do (where else can I look) to solve this issue? Please provide trace from 'pri debug' . -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk ZAP/DAHDI reads phantom digit on overlap PRI
--- On Mon, 12/14/09, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Mon, Dec 14, 2009 at 05:32:21AM -0800, Vieri wrote: Hi, I've noticed that a small but meaningful quota of calls from my Alcatel PBX to Asterisk are failing. This does not always happen and it is not easily reproducible but on high traffic I do get a large number of cases. Example: Alcatel PBX extension 7085 calls Asterisk PBX extension 6145 over a PRI E1 link. I see this in the Asterisk log: Dec 14 14:10:31 VERBOSE[11378] logger.c: -- Accepting overlap call from '7085' to '6145' on channel 1/31, span 1 Dec 14 14:10:31 VERBOSE[5558] logger.c: -- Starting simple switch on 'Zap/31-1' Dec 14 14:10:32 DEBUG[5558] chan_zap.c: DTMF digit: 5 on Zap/31-1 Dec 14 14:10:40 DEBUG[5558] chan_zap.c: No such possible extension '61455' in context 'from-alcatel' Obviously, it's failing because Asterisk is trying to match destination+extra DTMF digit (ie. 6145+5). However, noone ever dialed that extra digit! So how did it get there? I guess I could disable overlap in Asterisk but that isn't the right way to go. What else can I do (where else can I look) to solve this issue? Please provide trace from 'pri debug' . OK, I just grabbed a log for an Alcatel PBX extension 6166 calling an Asterisk PBX extension 6158 over a PRI E1 link: (not omitting any lines, just in case useful info is inadvertantly removed) Dec 14 20:15:53 VERBOSE[11378] logger.c: Protocol Discriminator: Q.931 (8) len=39 Dec 14 20:15:53 VERBOSE[11378] logger.c: Call Ref: len= 2 (reference 28696/0x7018) (Originator) Dec 14 20:15:53 VERBOSE[11378] logger.c: Message type: SETUP (5) Dec 14 20:15:53 VERBOSE[11378] logger.c: [04 03 80 90 a3] Dec 14 20:15:53 VERBOSE[11378] logger.c: Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Dec 14 20:15:53 VERBOSE[11378] logger.c: Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Dec 14 20:15:53 VERBOSE[11378] logger.c: User information layer 1: A-Law (35) Dec 14 20:15:53 VERBOSE[11378] logger.c: [18 03 a9 83 8e] Dec 14 20:15:53 VERBOSE[11378] logger.c: Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 Dec 14 20:15:53 VERBOSE[11378] logger.c: ChanSel: As indicated in following octets Dec 14 20:15:53 VERBOSE[11378] logger.c:Ext: 1 Coding: 0 Number Specified Channel Type: 3 Dec 14 20:15:53 VERBOSE[11378] logger.c:Ext: 1 Channel: 14 ] Dec 14 20:15:53 VERBOSE[11378] logger.c: [1e 02 80 83] Dec 14 20:15:53 VERBOSE[11378] logger.c: Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0) Dec 14 20:15:53 VERBOSE[11378] logger.c:Ext: 1 Progress Description: Calling equipment is non-ISDN. (3) ] Dec 14 20:15:53 VERBOSE[11378] logger.c: [6c 06 00 81 36 31 36 36] Dec 14 20:15:53 VERBOSE[11378] logger.c: Calling Number (len= 8) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) Dec 14 20:15:53 VERBOSE[11378] logger.c: Presentation: Presentation permitted, user number passed network screening (1) '6166' ] Dec 14 20:15:53 VERBOSE[11378] logger.c: [70 05 80 36 31 35 38] Dec 14 20:15:53 VERBOSE[11378] logger.c: Called Number (len= 7) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '6158' ] Dec 14 20:15:53 VERBOSE[11378] logger.c: [7d 02 91 81] Dec 14 20:15:53 VERBOSE[11378] logger.c: IE: High-layer Compatibility (len = 4) Dec 14 20:15:53 VERBOSE[11378] logger.c: [a1] Dec 14 20:15:53 VERBOSE[11378] logger.c: Sending Complete (len= 1) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Making new call for cr 28696 Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing Q.931 Call Setup Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 4 (cs0, Bearer Capability) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 24 (cs0, Channel Identification) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 30 (cs0, Progress Indicator) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 108 (cs0, Calling Party Number) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 112 (cs0, Called Party Number) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 125 (cs0, High-layer Compatibility) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 161 (cs0, Sending Complete) Dec 14 20:15:53 VERBOSE[11378] logger.c: Protocol Discriminator: Q.931 (8) len=11 Dec 14 20:15:53 VERBOSE[11378] logger.c: Call Ref: len= 2 (reference 28696/0x7018) (Terminator) Dec 14 20:15:53 VERBOSE[11378] logger.c: Message type: CALL PROCEEDING (2) Dec 14 20:15:53 VERBOSE[11378] logger.c: [18 04 e9 81 83 8e] Dec 14 20:15:53 VERBOSE[11378] logger.c: Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0,
Re: [asterisk-users] Asterisk ZAP/DAHDI reads phantom digit on overlap PRI
--- On Mon, 12/14/09, Vieri rentor...@yahoo.com wrote: From: Vieri rentor...@yahoo.com Subject: Re: [asterisk-users] Asterisk ZAP/DAHDI reads phantom digit on overlap PRI To: asterisk-users@lists.digium.com Date: Monday, December 14, 2009, 3:26 PM --- On Mon, 12/14/09, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Mon, Dec 14, 2009 at 05:32:21AM -0800, Vieri wrote: Hi, I've noticed that a small but meaningful quota of calls from my Alcatel PBX to Asterisk are failing. This does not always happen and it is not easily reproducible but on high traffic I do get a large number of cases. Example: Alcatel PBX extension 7085 calls Asterisk PBX extension 6145 over a PRI E1 link. I see this in the Asterisk log: Dec 14 14:10:31 VERBOSE[11378] logger.c: -- Accepting overlap call from '7085' to '6145' on channel 1/31, span 1 Dec 14 14:10:31 VERBOSE[5558] logger.c: -- Starting simple switch on 'Zap/31-1' Dec 14 14:10:32 DEBUG[5558] chan_zap.c: DTMF digit: 5 on Zap/31-1 Dec 14 14:10:40 DEBUG[5558] chan_zap.c: No such possible extension '61455' in context 'from-alcatel' Obviously, it's failing because Asterisk is trying to match destination+extra DTMF digit (ie. 6145+5). However, noone ever dialed that extra digit! So how did it get there? I guess I could disable overlap in Asterisk but that isn't the right way to go. What else can I do (where else can I look) to solve this issue? Please provide trace from 'pri debug' . OK, I just grabbed a log for an Alcatel PBX extension 6166 calling an Asterisk PBX extension 6158 over a PRI E1 link: (not omitting any lines, just in case useful info is inadvertantly removed) Dec 14 20:15:53 VERBOSE[11378] logger.c: Protocol Discriminator: Q.931 (8) len=39 Dec 14 20:15:53 VERBOSE[11378] logger.c: Call Ref: len= 2 (reference 28696/0x7018) (Originator) Dec 14 20:15:53 VERBOSE[11378] logger.c: Message type: SETUP (5) Dec 14 20:15:53 VERBOSE[11378] logger.c: [04 03 80 90 a3] Dec 14 20:15:53 VERBOSE[11378] logger.c: Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Dec 14 20:15:53 VERBOSE[11378] logger.c: Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Dec 14 20:15:53 VERBOSE[11378] logger.c: User information layer 1: A-Law (35) Dec 14 20:15:53 VERBOSE[11378] logger.c: [18 03 a9 83 8e] Dec 14 20:15:53 VERBOSE[11378] logger.c: Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 Dec 14 20:15:53 VERBOSE[11378] logger.c: ChanSel: As indicated in following octets Dec 14 20:15:53 VERBOSE[11378] logger.c: Ext: 1 Coding: 0 Number Specified Channel Type: 3 Dec 14 20:15:53 VERBOSE[11378] logger.c: Ext: 1 Channel: 14 ] Dec 14 20:15:53 VERBOSE[11378] logger.c: [1e 02 80 83] Dec 14 20:15:53 VERBOSE[11378] logger.c: Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0) Dec 14 20:15:53 VERBOSE[11378] logger.c: Ext: 1 Progress Description: Calling equipment is non-ISDN. (3) ] Dec 14 20:15:53 VERBOSE[11378] logger.c: [6c 06 00 81 36 31 36 36] Dec 14 20:15:53 VERBOSE[11378] logger.c: Calling Number (len= 8) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) Dec 14 20:15:53 VERBOSE[11378] logger.c: Presentation: Presentation permitted, user number passed network screening (1) '6166' ] Dec 14 20:15:53 VERBOSE[11378] logger.c: [70 05 80 36 31 35 38] Dec 14 20:15:53 VERBOSE[11378] logger.c: Called Number (len= 7) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '6158' ] Dec 14 20:15:53 VERBOSE[11378] logger.c: [7d 02 91 81] Dec 14 20:15:53 VERBOSE[11378] logger.c: IE: High-layer Compatibility (len = 4) Dec 14 20:15:53 VERBOSE[11378] logger.c: [a1] Dec 14 20:15:53 VERBOSE[11378] logger.c: Sending Complete (len= 1) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Making new call for cr 28696 Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing Q.931 Call Setup Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 4 (cs0, Bearer Capability) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 24 (cs0, Channel Identification) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 30 (cs0, Progress Indicator) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 108 (cs0, Calling Party Number) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 112 (cs0, Called Party Number) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 125 (cs0, High-layer Compatibility) Dec 14 20:15:53 VERBOSE[11378] logger.c: -- Processing IE 161 (cs0, Sending Complete) Dec 14 20:15:53 VERBOSE[11378] logger.c: Protocol
