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 <[email protected]> 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 <[email protected]> wrote: >>> >>> Hi >>> >>> Did you activate the pri debug on the cli asterisk? >>> >>> On Thu, Mar 24, 2016 at 12:59 PM, Carlos Chavez <[email protected]> >>> 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@e1-incoming:1] Goto("DAHDI/i2/55XXXXXXXX-3c", > "menu-gci,s,1") in new stack > -- Goto (menu-gci,s,1) > -- Executing [s@menu-gci:1] Wait("DAHDI/i2/55XXXXXXXX-3c", "2") in new > stack > -- Executing [s@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@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 -- _____________________________________________________________________ -- 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
