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

Matthew Fredrickson creslin at digium.com
Fri Oct 26 10:08:02 CDT 2007


David Kennedy wrote:
> Is there some part of the debug output I need to tell the telco about?
> When I was on to them earlier today, the engineer only seemed to know
> how to turn bits of their network on and off, not much about settings
> I need my end etc.
> 

Just tell them when you try to make a call, you get cause code 44 back 
(channel unavailable).  They can look at their switch to figure out 
what's going on.

Matthew Fredrickson

> Dave
> 
> On 10/25/07, Matthew Fredrickson <creslin at digium.com> wrote:
>> 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.
>>
>> _______________________________________________
>> --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