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.
Dave
On 10/25/07, Matthew Fredrickson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]:7]
> > ResetCDR("SIP/charlie59-082bc890", "w") in new stack
> > -- Executing [EMAIL PROTECTED]:8]
> > NoCDR("SIP/charlie59-082bc890", "") in new stack
> > -- Executing [EMAIL PROTECTED]:9]
> > Answer("SIP/charlie59-082bc890", "") in new stack
> > -- Executing [EMAIL PROTECTED]:10]
> > PlayTones("SIP/charlie59-082bc890", "congestion") in new stack
> > == Auto fallthrough, channel 'SIP/charlie59-082bc890' status is
> > 'CHANUNAVAIL'
> > -- Executing [EMAIL PROTECTED]: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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
