[asterisk-users] PRI span configuration - span remains down

David Kennedy davepkennedy at gmail.com
Thu Oct 25 12:15:33 CDT 2007


Hi

While I have fixed the problem from this post, I do have another
problem, and you have asked for a debug output here, so I'll go
against my better instinct and reply here :)

-- Making new call for cr 32774
    -- Requested transfer capability: 0x00 - SPEECH

> [ 00 01 0e 06 08 02 00 06 05 04 03 80 90 a3 18 03 a9 83 86 6c 0c 21 83 38 34 35 38 39 39 31 30 30 31 70 0c 80 30 32 30 38 36 35 39 32 32 39 31 a1 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 007   0: 0
> N(R): 003   P: 0
> 44 bytes of data
-- Restarting T203 counter
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=44
> Call Ref: len= 2 (reference 6/0x6) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a3]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                              Ext: 1  User information layer 1: A-Law (35)
> [18 03 a9 83 86]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 6 ]
> [6c 0c 21 83 38 34 35 38 39 39 31 30 30 31]
> Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation allowed of network provided number (3)  '8458991001' ]
> [70 0c 80 30 32 30 38 36 35 39 32 32 39 31]
> Called Number (len=14) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)  '<My Phone Number>' ]
> [a1]
> Sending Complete (len= 1)
q931.c:2881 q931_setup: call 32774 on channel 6 enters state 1 (Call Initiated)
    -- Called g0/<My Phone Number>
-- T200 counter expired, What to do...
-- Retransmitting 48 bytes
voip1*CLI>
> [ 00 01 0e 07 08 02 00 06 05 04 03 80 90 a3 18 03 a9 83 86 6c 0c 21 83 38 34 35 38 39 39 31 30 30 31 70 0c 80 30 32 30 38 36 35 39 32 32 39 31 a1 ]
voip1*CLI>
> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 007   0: 0
> N(R): 003   P: 1
> 44 bytes of data
-- Rescheduling retransmission (1)
voip1*CLI>
< [ 00 01 01 11 ]
voip1*CLI>
< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 008 P/F: 1
< 0 bytes of data
-- ACKing all packets from 6 to (but not including) 8
-- ACKing packet 7, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter
voip1*CLI>
< [ 02 01 06 10 08 02 80 06 5a 08 03 82 ac 18 ]
voip1*CLI>
< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
< N(S): 003   0: 0
< N(R): 008   P: 0
< 10 bytes of data
-- ACKing all packets from 7 to (but not including) 8
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
< Protocol Discriminator: Q.931 (8)  len=10
< Call Ref: len= 2 (reference 6/0x6) (Terminator)
< Message type: RELEASE COMPLETE (90)
< [08 03 82 ac 18]
< Cause (len= 5) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0
Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Requested channel not available
(44), class = Network Congestion (resource unavailable) (2) ]
<              Cause data 1: 18 (24)
-- Processing IE 8 (cs0, Cause)
q931.c:3503 q931_receive: call 32774 on channel 6 enters state 0 (Null)
Sending Receiver Ready (4)
voip1*CLI>
> [ 02 01 01 08 ]
voip1*CLI>
> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 004 P/F: 0
> 0 bytes of data
-- Restarting T203 counter
-- Restarting T203 counter
    -- Channel 0/6, span 1 got hangup, cause 44
    -- Forcing restart of channel 0/6 on span 1 since channel reported in use
voip1*CLI>
> [ 00 01 10 08 08 02 00 00 46 18 03 a9 83 86 79 01 80 ]
voip1*CLI>
> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 008   0: 0
> N(R): 004   P: 0
> 13 bytes of data
-- Restarting T203 counter
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=13
> Call Ref: len= 2 (reference 0/0x0) (Originator)
> Message type: RESTART (70)
> [18 03 a9 83 86]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 6 ]
> [79 01 80]
> Restart Indentifier (len= 3) [ Ext: 1  Spare: 0  Resetting Indicated Channel (0) ]
voip1*CLI>
< [ 00 01 01 12 ]
voip1*CLI>
< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 009 P/F: 0
< 0 bytes of data
-- ACKing all packets from 7 to (but not including) 9
-- ACKing packet 8, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Nothing left, starting T203 counter
-- Restarting T203 counter
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
    -- Hungup 'Zap/6-1'
[Oct 25 18:01:46] NOTICE[20956]: cdr.c:434 ast_cdr_free: CDR on
channel 'Zap/6-1' not posted
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [s at macro-dialexternal:7]
ResetCDR("SIP/charlie59-082bc890", "w") in new stack
    -- Executing [s at macro-dialexternal:8]
NoCDR("SIP/charlie59-082bc890", "") in new stack
    -- Executing [s at macro-dialexternal:9]
Answer("SIP/charlie59-082bc890", "") in new stack
    -- Executing [s at macro-dialexternal:10]
PlayTones("SIP/charlie59-082bc890", "congestion") in new stack
  == Auto fallthrough, channel 'SIP/charlie59-082bc890' status is 'CHANUNAVAIL'
    -- Executing [h at route-ext-ycmcr:1]
Hangup("SIP/charlie59-082bc890", "") in new stack
  == Spawn extension (route-ext-ycmcr, h, 1) exited non-zero on
'SIP/charlie59-082bc890'

As I say, I've asked a separate question on this, so I don't really
want to end up with two thread on the one problem :)

Thanks

Dave

On 10/25/07, Matthew Fredrickson <creslin at digium.com> wrote:
> Rony Ron wrote:
> > Hello,
> > Quoting Digium Support:
> > "The TE110P has been discontinued and replaced in our product lineup with
> > the TE120P, which features many overall improvements and does not suffer
> > from the HDLC Abort/Bad FCS problems that the TE110P did."
>
> Although this is true ( :-) ) I think that it is likely his problem is
> not related to this.  Can you post a "pri intense debug span x" for the
> span in question?
>
> Matthew Fredrickson
>
> > On 10/25/07, David Kennedy <davepkennedy at gmail.com> wrote:
> >> Hi,
> >>
> >> I'm trying to connect to Telewest/Virgin Media with a TE110P using
> >> asterisk 1.4.13/zaptel 1.4.6. No matter what I try, my span always
> >> appears as
> >>
> >> PRI span 1/0: Provisioned, Down, Active
> >>
> >> My zapata.conf is currently
> >> -----------------------------------
> >> [channels]
> >> echocancel=yes
> >> echocancelwhenbridged=no
> >> echotraining=yes
> >> switchtype=euroisdn
> >> contect=from-pri
> >> signalling=pri_cpe
> >> group=1
> >> channel => 1-15
> >> channel => 17-31
> >> -----------------------------------
> >>
> >> zaptel.conf is
> >> -----------------------------------
> >> span=1,1,0,ccs,hdb3,crc4
> >> dchan=16
> >> bchan=1-15,17-31
> >> loadzone=uk
> >> defaultzone=uk
> >> -----------------------------------
> >>
> >> I'm in London and the server is in Manchester, so I can't look at the
> >> server directly, but when we first started setting it up, apparently a
> >> pair of cables were the wrong way round, so the card was in a RED
> >> alarm state. We've switched the cables and now the card is OK. We did
> >> have a lot of IRQ misses, so we've upgraded the kernel and now the
> >> accuracy reported by zttest is about 99.98%. Telewest have checked the
> >> line for faults and have reported that it's fine, but I just can't get
> >> it working.
> >>
> >> Does anyone have any ideas/suggestions?
> >>
> >> Thanks,
> >>
> >> Dave
> >>
> >> _______________________________________________
> >> --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
> >>
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > --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
>
>
> --
> Matthew Fredrickson
> Software/Firmware Engineer
> Digium, Inc.
>
> _______________________________________________
> --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
>



More information about the asterisk-users mailing list