[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?