PRI Error “ROSE REJECT”

Home » Asterisk Users » PRI Error “ROSE REJECT”
Asterisk Users 4 Comments

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

4 thoughts on - PRI Error “ROSE REJECT”

  • PRI debug of the entire call would be great, also, switchtype would be awesome as well.

    Thanks!

    Matthew Fredrickson


    Matthew Fredrickson Digium, Inc. | Engineering Manager
    445 Jan Davis Drive NW – Huntsville, AL 35806 – USA

  • 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
    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


    Matthew Fredrickson Digium, Inc. | Engineering Manager
    445 Jan Davis Drive NW – Huntsville, AL 35806 – USA