[asterisk-users] PRI span configuration - span remains down
Alejandro Kauffmann
akauffma at prodigy.net.mx
Fri Oct 26 01:53:18 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 :)
>
> -- 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
>
>
>
Unless behavior has changed in 1.4, I'm a bit confused by the following:
> > -- Called g0/<My Phone Number>
but your zapata.conf defines group=1. In addition, lower case "g" should use the first available channel from lowest to highest. Why is it starting on channel 6? Are the first 5 channels busy somehow? Did you change your configuration and not post the new one? Your other post shows it tried channel 4 with a return code of 44 which is "requested circuit/channel not available" which is the same cause code in the debug above. It seems the circuit is up but not the channels. What is the output of ztcfg -v?
I have all PRI setups and in my experience it very rarely has anything to do with the card and most often is one of the following:
1. I missed something. (modprobe zaptel, modprobe (card driver), or ztcfg)
2. Config mismatch between you and telco (i.e. using CRC4 when they are not)
3. They are lying out their butts about it being setup right
Option 3 is the one I have to deal with most often.
More information about the asterisk-users
mailing list