[asterisk-users] PRI span configuration - span remains down
Matthew Fredrickson
creslin at digium.com
Fri Oct 26 10:10:18 CDT 2007
Rony Ron wrote:
> Hi, in meantime if you have another type of digium pri
> card you can plug it into your box to confirm that it's not related to
> that card!
> Better eliminate any doubt about that card... it made me suffer !
Well, if signalling didn't work on the D-channel, that might be a more
plausible option. When the D-channel comes up, you've (for 99.9999% of
cases) usually eliminated the card being a problem. It looks like his
D-channel is up, if he's passing call signalling data back and forth
like this.
Matthew Fredrickson
>
> BR,
>
>
> 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