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

Matthew Fredrickson creslin at digium.com
Thu Oct 25 12:40:30 CDT 2007


David Kennedy wrote:
> 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 :)

I just looked through your debug and can't see any obvious problems. 
It's likely you'll need to ask your telco why the other switch is 
complaining about the channel selection.

Matthew Fredrickson

> 
> -- 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
>>
> 
> _______________________________________________
> --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.



More information about the asterisk-users mailing list