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