PRI debug of the entire call would be great, also, switchtype would be awesome as well. Thanks! Matthew Fredrickson On Thu, Mar 24, 2016 at 4:07 PM, Carlos Rojas <crt.rojas at gmail.com> wrote:> Hi > > Did you activate the pri debug on the cli asterisk? > > On Thu, Mar 24, 2016 at 12:59 PM, Carlos Chavez <cursor at telecomabmex.com> > wrote: >> >> We've been having some problems with an E1 PRI line for a few days. We >> get the following errors: >> >> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 ROSE REJECT: >> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 INVOKE ID: >> 316 >> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 PROBLEM: >> Invoke: Unrecognized Operation >> >> The telephone company says that everything is fine on their side, >> obviously. The problems started a few days ago when a user reported that >> incoming calls get dropped when you try to dial a particular extension from >> the main IVR. We are using Asterisk 1.8.15-cert2 on a CentOS 6.7 server, >> DAHDI 2.6.1 and libpri 1.4. Any recommendations? >> >> -- >> Telecomunicaciones Abiertas de M?xico S.A. de C.V. >> Carlos Ch?vez >> dCAP #1349 >> +52 (55)9116-91161 >> >> -- >> _____________________________________________________________________ >> -- 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-- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
On 2016-03-25 16:02, Matt Fredrickson wrote:> PRI debug of the entire call would be great, also, switchtype would be > awesome as well. > > Thanks! > > Matthew Fredrickson > > On Thu, Mar 24, 2016 at 4:07 PM, Carlos Rojas <crt.rojas at gmail.com> > wrote: >> Hi >> >> Did you activate the pri debug on the cli asterisk? >> >> On Thu, Mar 24, 2016 at 12:59 PM, Carlos Chavez >> <cursor at telecomabmex.com> >> wrote: >>> >>> We've been having some problems with an E1 PRI line for a few days. >>> We >>> get the following errors: >>> >>> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 ROSE REJECT: >>> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 >>> INVOKE ID: >>> 316 >>> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 >>> PROBLEM: >>> Invoke: Unrecognized Operation >>> >>> The telephone company says that everything is fine on their side, >>> obviously. The problems started a few days ago when a user reported >>> that >>> incoming calls get dropped when you try to dial a particular >>> extension from >>> the main IVR. We are using Asterisk 1.8.15-cert2 on a CentOS 6.7 >>> server, >>> DAHDI 2.6.1 and libpri 1.4. Any recommendations? >>> >>> --system.conf: # Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) span=1,2,0,cas,hdb3 cas=1-15:1101 cas=17-31:1101 # Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" span=2,1,0,ccs,hdb3 # termtype: te bchan=32-46 dchan=47 bchan=48-62 loadzone = mx defaultzone = mx chan_dahdi.conf: language=es context=e1-incoming usecallerid=yes hidecallerid=no callwaiting=no canpark=no usecallingpres=no callwaitingcallerid=no threewaycalling=no transfer=yes cancallforward=no callreturn=no echocancel=yes echocancelwhenbridged=no echotraining=yes rxgain=0.0 txgain=0.0 accountcode=E1 amaflags=default signalling=pri_cpe pridialplan=unknown prilocaldialplan=unknown switchtype=euroisdn overlapdial=no immediate=no group=2 faxdetect=no callerid=asreceived mohinterpret=default mohsuggest=default dahdichan=32-46,48-62 Here is the pri debug: -- Accepting call from '55XXXXXXXX' to '5732' on channel 0/1, span 2 -- Executing [5732 at e1-incoming:1] Goto("DAHDI/i2/55XXXXXXXX-3c", "menu-gci,s,1") in new stack -- Goto (menu-gci,s,1) -- Executing [s at menu-gci:1] Wait("DAHDI/i2/55XXXXXXXX-3c", "2") in new stack -- Executing [s at menu-gci:2] Answer("DAHDI/i2/55XXXXXXXX-3c", "") in new stack PRI Span: 2 q931.c:4683 q931_connect: Call 48 enters state 8 (Connect Request). Hold state: Idle PRI Span: 2 PRI Span: 2 > DL-DATA request PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=14 PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to originator) PRI Span: 2 > Message Type: CONNECT (7) PRI Span: 2 TEI=0 Transmitting N(S)=98, window is open V(A)=98 K=7 PRI Span: 2 PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=14 PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to originator) PRI Span: 2 > Message Type: CONNECT (7) PRI Span: 2 > [18 03 a9 83 81] PRI Span: 2 > Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0 PRI Span: 2 > ChanSel: As indicated in following octets PRI Span: 2 > Ext: 1 Coding: 0 Number Specified Channel Type: 3 PRI Span: 2 > Ext: 1 Channel: 1 Type: CPE] PRI Span: 2 > [1e 02 81 82] PRI Span: 2 > Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) PRI Span: 2 > Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ] -- Executing [s at menu-gci:3] BackGround("DAHDI/i2/55XXXXXXXX-3c", "menugci") in new stack -- <DAHDI/i2/55XXXXXXXX-3c> Playing 'menugci.slin' (language 'es') PRI Span: 2 PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=5 PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent from originator) PRI Span: 2 < Message Type: CONNECT ACKNOWLEDGE (15) PRI Span: 2 Received message for call 0x2aaaac5e9c10 on 0x326b290 TEI/SAPI 0/0, call->pri is 0x326b290 TEI/SAPI 0/0 PRI Span: 2 q931.c:7024 post_handle_q931_message: Call 48 enters state 10 (Active). Hold state: Idle [Mar 25 20:01:52] WARNING[14859]: pbx.c:5465 __ast_pbx_run: Invalid extension '8', but no rule 'i' or 'e' in context 'menu-gci' PRI Span: 2 q931_hangup: other hangup PRI Span: 2 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Active, hold-state Idle PRI Span: 2 q931.c:4768 q931_disconnect: Call 48 enters state 11 (Disconnect Request). Hold state: Idle PRI Span: 2 PRI Span: 2 > DL-DATA request PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9 PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to originator) PRI Span: 2 > Message Type: DISCONNECT (69) PRI Span: 2 TEI=0 Transmitting N(S)=99, window is open V(A)=99 K=7 PRI Span: 2 PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9 PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to originator) PRI Span: 2 > Message Type: DISCONNECT (69) PRI Span: 2 > [08 02 81 90] PRI Span: 2 > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) PRI Span: 2 > Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] -- Hungup 'DAHDI/i2/55XXXXXXXX-3c' PRI Span: 2 PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=5 PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent from originator) PRI Span: 2 < Message Type: RELEASE (77) PRI Span: 2 Received message for call 0x2aaaac5e9c10 on 0x326b290 TEI/SAPI 0/0, call->pri is 0x326b290 TEI/SAPI 0/0 PRI Span: 2 q931.c:7123 post_handle_q931_message: Call 48 enters state 0 (Null). Hold state: Idle Span 2: Processing event PRI_EVENT_HANGUP PRI Span: 2 q931_hangup: other hangup PRI Span: 2 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request, hold-state Idle PRI Span: 2 PRI Span: 2 > DL-DATA request PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9 PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to originator) PRI Span: 2 > Message Type: RELEASE COMPLETE (90) PRI Span: 2 TEI=0 Transmitting N(S)=100, window is open V(A)=100 K=7 PRI Span: 2 PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9 PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to originator) PRI Span: 2 > Message Type: RELEASE COMPLETE (90) PRI Span: 2 > [08 02 81 90] PRI Span: 2 > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1) PRI Span: 2 > Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] PRI Span: 2 q931_hangup: other hangup PRI Span: 2 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null, hold-state Idle PRI Span: 2 NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null, hold-state Idle From what I can now see is that Asterisk seems to be ignoring the dtmf while it is playing the background sound file. I try dialing the extension number but nothing happens for the first or second digits and then I get the "invalid extension" because I have no extensions that start with the remaining digits. This is the only IVR I have in this span, all others go straight to a queue so no problems there. The other E1 on this system is R2 and you can dial the same IVR through another number and it will recognize the dtmf immediately. This E1 link had been working without any problems for over 5 years until last week with the same exact configuration. Thanks. -- Telecomunicaciones Abiertas de M?xico S.A. de C.V. Carlos Ch?vez dCAP #1349 +52 (55)9116-91161
Perhaps it's taking a bit longer in the network for the media path to open after the CONNECT, which would explain why the first digit is not being detected. Also, what changed last week? I don't see the ROSE REJECT message anywhere in the pri debug - perhaps you didn't catch it. Matthew Fredrickson On Fri, Mar 25, 2016 at 9:15 PM, Carlos Chavez <cursor at telecomabmex.com> wrote:> On 2016-03-25 16:02, Matt Fredrickson wrote: >> >> PRI debug of the entire call would be great, also, switchtype would be >> awesome as well. >> >> Thanks! >> >> Matthew Fredrickson >> >> On Thu, Mar 24, 2016 at 4:07 PM, Carlos Rojas <crt.rojas at gmail.com> wrote: >>> >>> Hi >>> >>> Did you activate the pri debug on the cli asterisk? >>> >>> On Thu, Mar 24, 2016 at 12:59 PM, Carlos Chavez <cursor at telecomabmex.com> >>> wrote: >>>> >>>> >>>> We've been having some problems with an E1 PRI line for a few days. We >>>> get the following errors: >>>> >>>> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 ROSE REJECT: >>>> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 INVOKE >>>> ID: >>>> 316 >>>> [Mar 24 10:13:39] ERROR[22009] chan_dahdi.c: PRI Span: 2 PROBLEM: >>>> Invoke: Unrecognized Operation >>>> >>>> The telephone company says that everything is fine on their side, >>>> obviously. The problems started a few days ago when a user reported >>>> that >>>> incoming calls get dropped when you try to dial a particular extension >>>> from >>>> the main IVR. We are using Asterisk 1.8.15-cert2 on a CentOS 6.7 >>>> server, >>>> DAHDI 2.6.1 and libpri 1.4. Any recommendations? >>>> >>>> -- > > > system.conf: > # Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) > span=1,2,0,cas,hdb3 > cas=1-15:1101 > cas=17-31:1101 > > # Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" > span=2,1,0,ccs,hdb3 > # termtype: te > bchan=32-46 > dchan=47 > bchan=48-62 > > loadzone = mx > defaultzone = mx > > chan_dahdi.conf: > language=es > context=e1-incoming > usecallerid=yes > hidecallerid=no > callwaiting=no > canpark=no > usecallingpres=no > callwaitingcallerid=no > threewaycalling=no > transfer=yes > cancallforward=no > callreturn=no > echocancel=yes > echocancelwhenbridged=no > echotraining=yes > rxgain=0.0 > txgain=0.0 > accountcode=E1 > amaflags=default > signalling=pri_cpe > pridialplan=unknown > prilocaldialplan=unknown > switchtype=euroisdn > overlapdial=no > immediate=no > group=2 > faxdetect=no > callerid=asreceived > mohinterpret=default > mohsuggest=default > dahdichan=32-46,48-62 > > Here is the pri debug: > -- Accepting call from '55XXXXXXXX' to '5732' on channel 0/1, span 2 > -- Executing [5732 at e1-incoming:1] Goto("DAHDI/i2/55XXXXXXXX-3c", > "menu-gci,s,1") in new stack > -- Goto (menu-gci,s,1) > -- Executing [s at menu-gci:1] Wait("DAHDI/i2/55XXXXXXXX-3c", "2") in new > stack > -- Executing [s at menu-gci:2] Answer("DAHDI/i2/55XXXXXXXX-3c", "") in new > stack > PRI Span: 2 q931.c:4683 q931_connect: Call 48 enters state 8 (Connect > Request). Hold state: Idle > PRI Span: 2 > PRI Span: 2 > DL-DATA request > PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=14 > PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to > originator) > PRI Span: 2 > Message Type: CONNECT (7) > PRI Span: 2 TEI=0 Transmitting N(S)=98, window is open V(A)=98 K=7 > PRI Span: 2 > PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=14 > PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to > originator) > PRI Span: 2 > Message Type: CONNECT (7) > PRI Span: 2 > [18 03 a9 83 81] > PRI Span: 2 > Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) > Spare: 0 Exclusive Dchan: 0 > PRI Span: 2 > ChanSel: As indicated in following > octets > PRI Span: 2 > Ext: 1 Coding: 0 Number Specified > Channel Type: 3 > PRI Span: 2 > Ext: 1 Channel: 1 Type: CPE] > PRI Span: 2 > [1e 02 81 82] > PRI Span: 2 > Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) > standard (0) 0: 0 Location: Private network serving the local user (1) > PRI Span: 2 > Ext: 1 Progress Description: > Called equipment is non-ISDN. (2) ] > -- Executing [s at menu-gci:3] BackGround("DAHDI/i2/55XXXXXXXX-3c", > "menugci") in new stack > -- <DAHDI/i2/55XXXXXXXX-3c> Playing 'menugci.slin' (language 'es') > PRI Span: 2 > PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=5 > PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent from > originator) > PRI Span: 2 < Message Type: CONNECT ACKNOWLEDGE (15) > PRI Span: 2 Received message for call 0x2aaaac5e9c10 on 0x326b290 TEI/SAPI > 0/0, call->pri is 0x326b290 TEI/SAPI 0/0 > PRI Span: 2 q931.c:7024 post_handle_q931_message: Call 48 enters state 10 > (Active). Hold state: Idle > [Mar 25 20:01:52] WARNING[14859]: pbx.c:5465 __ast_pbx_run: Invalid > extension '8', but no rule 'i' or 'e' in context 'menu-gci' > PRI Span: 2 q931_hangup: other hangup > PRI Span: 2 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, > peerstate Active, hold-state Idle > PRI Span: 2 q931.c:4768 q931_disconnect: Call 48 enters state 11 (Disconnect > Request). Hold state: Idle > PRI Span: 2 > PRI Span: 2 > DL-DATA request > PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9 > PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to > originator) > PRI Span: 2 > Message Type: DISCONNECT (69) > PRI Span: 2 TEI=0 Transmitting N(S)=99, window is open V(A)=99 K=7 > PRI Span: 2 > PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9 > PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to > originator) > PRI Span: 2 > Message Type: DISCONNECT (69) > PRI Span: 2 > [08 02 81 90] > PRI Span: 2 > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) > Spare: 0 Location: Private network serving the local user (1) > PRI Span: 2 > Ext: 1 Cause: Normal Clearing (16), class > Normal Event (1) ] > -- Hungup 'DAHDI/i2/55XXXXXXXX-3c' > PRI Span: 2 > PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=5 > PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent from > originator) > PRI Span: 2 < Message Type: RELEASE (77) > PRI Span: 2 Received message for call 0x2aaaac5e9c10 on 0x326b290 TEI/SAPI > 0/0, call->pri is 0x326b290 TEI/SAPI 0/0 > PRI Span: 2 q931.c:7123 post_handle_q931_message: Call 48 enters state 0 > (Null). Hold state: Idle > Span 2: Processing event PRI_EVENT_HANGUP > PRI Span: 2 q931_hangup: other hangup > PRI Span: 2 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate > Release Request, hold-state Idle > PRI Span: 2 > PRI Span: 2 > DL-DATA request > PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9 > PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to > originator) > PRI Span: 2 > Message Type: RELEASE COMPLETE (90) > PRI Span: 2 TEI=0 Transmitting N(S)=100, window is open V(A)=100 K=7 > PRI Span: 2 > PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9 > PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 48/0x30) (Sent to > originator) > PRI Span: 2 > Message Type: RELEASE COMPLETE (90) > PRI Span: 2 > [08 02 81 90] > PRI Span: 2 > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) > Spare: 0 Location: Private network serving the local user (1) > PRI Span: 2 > Ext: 1 Cause: Normal Clearing (16), class > Normal Event (1) ] > PRI Span: 2 q931_hangup: other hangup > PRI Span: 2 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate > Null, hold-state Idle > PRI Span: 2 NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate > Null, hold-state Idle > > From what I can now see is that Asterisk seems to be ignoring the dtmf > while it is playing the background sound file. I try dialing the extension > number but nothing happens for the first or second digits and then I get the > "invalid extension" because I have no extensions that start with the > remaining digits. This is the only IVR I have in this span, all others go > straight to a queue so no problems there. The other E1 on this system is R2 > and you can dial the same IVR through another number and it will recognize > the dtmf immediately. This E1 link had been working without any problems > for over 5 years until last week with the same exact configuration. Thanks. > > > -- > Telecomunicaciones Abiertas de M?xico S.A. de C.V. > Carlos Ch?vez > dCAP #1349 > +52 (55)9116-91161-- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA