[asterisk-users] PRI error "ROSE REJECT"

Matt Fredrickson creslin at digium.com
Tue Mar 29 13:55:38 CDT 2016


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



More information about the asterisk-users mailing list