Захаров Антон
2010-Sep-30 12:57 UTC
[asterisk-users] channel.c: Got a FRAME_CONTROL (8) frame on channel DAHDI
Hello everyone.
I have server with 2E1 PCI card, asterisk 1.4.35, dahdi 2.4.0, libpri
1.4.12-beta2. One PRI trunk looks to PSTN and take a clocksource from
telco. Another trunk looks to PBX with DECT system.
Some outgoing calls from asterisk to PSTN drops. The last message that
exists before hanging up process is:
DEBUG[28467] channel.c: Got a FRAME_CONTROL (8) frame on channel DAHDI/...
This frame come when call already established. So, when it come, the
call drops. "FRAME_CONTROL (8)" means 'Congestion' according
to
'frame.h'. I have already set debug 6, verbose 6 and enabled EXTENSIVE
debugging on span, but couldn't find incoming frame from telco with
information of 'Congestion' on this channel.
I want to debug this message. I want to know where the root of my
problem. And I'm sure that it's only my problem. That's why I
didn't
create issue ticket on bug tracker. So default methods of debug didn't
show me control frames.
I have a call log: http://pastebin.mozilla-russia.org/107089
Part of the full log file at the moment when this FRAME have been got:
http://pastebin.mozilla-russia.org/107090
Part of the full log file from start of the call to drop:
http://pastebin.com/MphaCkiV
I have from 3 to 5 call drops in hour so it's reproduce periodically :
http://pastebin.com/rdnYR8dU http://pastebin.com/KUJDPd3C
I'm sorry, but I can't remember what E1 card placed in server. But it
could be Digium or OpenVox.
Here is output of some commands:
lspci:
02:00.0 Communication controller: Digium, Inc. Wildcard TE210P dual-span
T1/E1/J1 card 3.3V (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d0100000 (32-bit, non-prefetchable) [size=128]
Kernel driver in use: wct4xxp
Kernel modules: wct4xxp
dmesg:
wct4xxp 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
wct4xxp 0000:02:00.0: Found TE2XXP at base address d0100000, remapped to
f90d4000
wct4xxp 0000:02:00.0: DMA memory base of size 2048 at f6829000. Read:
f6829400 and Write f6829000
wct4xxp 0000:02:00.0: Firmware Version: c01a0000
wct4xxp 0000:02:00.0: Burst Mode: On
wct4xxp 0000:02:00.0: FALC Framer Version: 2.1 or earlier
wct4xxp 0000:02:00.0: Board ID: 00
wct4xxp 0000:02:00.0: Reg 0: 0x36829400
wct4xxp 0000:02:00.0: Reg 1: 0x36829000
wct4xxp 0000:02:00.0: Reg 2: 0xd0100008
wct4xxp 0000:02:00.0: Reg 3: 0x00000000
wct4xxp 0000:02:00.0: Reg 4: 0x00000000
wct4xxp 0000:02:00.0: Reg 5: 0xd0100014
wct4xxp 0000:02:00.0: Reg 6: 0xc01a0000
wct4xxp 0000:02:00.0: Reg 7: 0x00001f00
wct4xxp 0000:02:00.0: Reg 8: 0x00000000
wct4xxp 0000:02:00.0: Reg 9: 0x00000000
wct4xxp 0000:02:00.0: Reg 10: 0xd0100028
IRQ 16/wct2xxp: IRQF_DISABLED is not guaranteed on shared IRQs
wct4xxp 0000:02:00.0: Found a Wildcard: Wildcard TE210P
dahdi_hardware:
pci:0000:02:00.0 wct4xxp+ d161:0210 Wildcard TE210P
As I think, it's really Digium TE210P. But I don't think, it's a
pci
card problem because call drops exist only on outgoing calls and 98%
DIDs is mobile phone numbers.
Any suggestions how to see this frame and who was the sender?
Захаров Антон
2010-Oct-15 10:27 UTC
[asterisk-users] channel.c: Got a FRAME_CONTROL (8) frame on channel DAHDI
My problem with call drops on PRI, followed by 'FRAME_CONTROL (8)' was successfully solved. The issue was in callprogress=yes option in chan_dahdi.conf. It seems that I wrong when I wrote configuration file and confused it with usecallingpres option. On 30.09.2010 16:57, ??????? ????? wrote:> Hello everyone. > > I have server with 2E1 PCI card, asterisk 1.4.35, dahdi 2.4.0, libpri > 1.4.12-beta2. One PRI trunk looks to PSTN and take a clocksource from > telco. Another trunk looks to PBX with DECT system. > Some outgoing calls from asterisk to PSTN drops. The last message that > exists before hanging up process is: > DEBUG[28467] channel.c: Got a FRAME_CONTROL (8) frame on channel > DAHDI/... > This frame come when call already established. So, when it come, the > call drops. "FRAME_CONTROL (8)" means 'Congestion' according to > 'frame.h'. I have already set debug 6, verbose 6 and enabled > EXTENSIVE debugging on span, but couldn't find incoming frame from > telco with information of 'Congestion' on this channel. > I want to debug this message. I want to know where the root of my > problem. And I'm sure that it's only my problem. That's why I didn't > create issue ticket on bug tracker. So default methods of debug didn't > show me control frames. > > I have a call log: http://pastebin.mozilla-russia.org/107089 > Part of the full log file at the moment when this FRAME have been got: > http://pastebin.mozilla-russia.org/107090 > Part of the full log file from start of the call to drop: > http://pastebin.com/MphaCkiV > I have from 3 to 5 call drops in hour so it's reproduce periodically > : http://pastebin.com/rdnYR8dU http://pastebin.com/KUJDPd3C > > I'm sorry, but I can't remember what E1 card placed in server. But it > could be Digium or OpenVox. > Here is output of some commands: > > lspci: > 02:00.0 Communication controller: Digium, Inc. Wildcard TE210P > dual-span T1/E1/J1 card 3.3V (rev 02) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 32 > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at d0100000 (32-bit, non-prefetchable) [size=128] > Kernel driver in use: wct4xxp > Kernel modules: wct4xxp > > dmesg: > wct4xxp 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > wct4xxp 0000:02:00.0: Found TE2XXP at base address d0100000, remapped > to f90d4000 > wct4xxp 0000:02:00.0: DMA memory base of size 2048 at f6829000. Read: > f6829400 and Write f6829000 > wct4xxp 0000:02:00.0: Firmware Version: c01a0000 > wct4xxp 0000:02:00.0: Burst Mode: On > wct4xxp 0000:02:00.0: FALC Framer Version: 2.1 or earlier > wct4xxp 0000:02:00.0: Board ID: 00 > wct4xxp 0000:02:00.0: Reg 0: 0x36829400 > wct4xxp 0000:02:00.0: Reg 1: 0x36829000 > wct4xxp 0000:02:00.0: Reg 2: 0xd0100008 > wct4xxp 0000:02:00.0: Reg 3: 0x00000000 > wct4xxp 0000:02:00.0: Reg 4: 0x00000000 > wct4xxp 0000:02:00.0: Reg 5: 0xd0100014 > wct4xxp 0000:02:00.0: Reg 6: 0xc01a0000 > wct4xxp 0000:02:00.0: Reg 7: 0x00001f00 > wct4xxp 0000:02:00.0: Reg 8: 0x00000000 > wct4xxp 0000:02:00.0: Reg 9: 0x00000000 > wct4xxp 0000:02:00.0: Reg 10: 0xd0100028 > IRQ 16/wct2xxp: IRQF_DISABLED is not guaranteed on shared IRQs > wct4xxp 0000:02:00.0: Found a Wildcard: Wildcard TE210P > > dahdi_hardware: > pci:0000:02:00.0 wct4xxp+ d161:0210 Wildcard TE210P > > As I think, it's really Digium TE210P. But I don't think, it's a pci > card problem because call drops exist only on outgoing calls and 98% > DIDs is mobile phone numbers. > > Any suggestions how to see this frame and who was the sender? >