[asterisk-r2] Only one channel IDLE, the others are BLOCK
Marcelo Pacheco
marcelo at m2j.com.br
Thu May 9 16:53:53 CDT 2013
I have seen this happen when there are quick alarm on the trunk,
OK->RED, 1-4 seconds later, RED->OK, check for alarms on the log.
If it's this problem, a dahdi restart will rectify.
Let the developers know, I'm trying to get 100% rid of all MFC R2 with
Asterisk due to this kind of issues, but ISDN is impossible to obtain in
the countryside.
Marcelo
On 05/09/13 17:00, ServTelar wrote:
> Check the bit status using dahdi_tool. ABCD=1101 means block, 1001
> means idle (showing in vertical).
>
> ????????????????? T4XXP (PCI) Card 0 Span 3 ??????????????????
>
> ???????
> ? ?????
>
> ? ?
> ? ?
>
> ? ? Current
> Alarms: No alarms. ? ?
>
> ? ? Sync Source:
> T4XXP (PCI) Card 0 Span 1 ? ? ?
>
> ? ? IRQ Misses:
> 0 ? ? ?
>
> ? ? Bipolar
> Viol: 0 ? ? ?
>
> ? ? Tx/Rx
> Levels: 0/ 0 ? ? ?
>
> ? ?
> Total/Conf/Act: 31/ 30/ 30 ? ? ?
>
> ? ?
> 1111111111222222222233 ???????? ? ? ?
>
> ? ?
> 1234567890123456789012345678901 ? Back ? ? ? ?
>
> ? ? TxA
> 111111111111111 111111111111111 ???????? ? ? ?
>
> ? ? TxB
> 111111111111111 111111111111111 ? ? ?
>
> ? ? TxC
> 000000000000000 000000000000000 ? ? ?
>
> ? ? TxD
> 111111111111111 111111111111111 ? ?
>
> ? ?
> ? ?
>
> ? ? RxA
> 111111111111111 111111111111111 ? ?
>
> ? ? RxB
> 011111111111111 111111111111111 ? ?
>
> ? ? RxC
> 000000000000000 000000000000000 ? ?
>
> ? ? RxD
> 111111111111111 111111111111111
>
> In this case just ch=1 is receiving idle, the rest are blocked, and
> we're transmitting blocked.
>
> Regards
>
> Gustavo
>
>
> On May 9, 2013, at 3:51 PM, Christian Cabrera <ccabrera at gmail.com
> <mailto:ccabrera at gmail.com>> wrote:
>
>> Hello,
>>
>> Recently, the E1 of one of my clients stopped "almost" working. They
>> have a 10 channel E1 with R2, but only the first channel appears as
>> IDLE, while the remaining stay at BLOCK.
>>
>> Here's what the mfcr2 show channels throws:
>>
>> Chan Variant Max ANI Max DNIS ANI First Immediate Accept Tx CAS Rx CAS
>> 1 MX 10 4 No No IDLE IDLE
>> 2 MX 10 4 No No IDLE BLOCK
>> 3 MX 10 4 No No IDLE BLOCK
>> 4 MX 10 4 No No IDLE BLOCK
>> 5 MX 10 4 No No IDLE BLOCK
>> 6 MX 10 4 No No IDLE BLOCK
>> 7 MX 10 4 No No IDLE BLOCK
>> 8 MX 10 4 No No IDLE BLOCK
>> 9 MX 10 4 No No IDLE BLOCK
>> 10 MX 10 4 No No IDLE BLOCK
>>
>>
>> The configuration is as usual. Here's my system.conf:
>>
>> ------------------------------------------
>> span=1,1,0,cas,hdb3
>> cas=1-15:1101
>> cas=17-31:1101
>> echocanceller=mg2,1-15,17-31
>>
>> loadzone = mx
>> defaultzone = mx
>> ------------------------------------------
>>
>>
>> And here's my chan_dahdi.conf
>>
>> ------------------------------------------
>> signalling=mfcr2
>> mfcr2_variant=mx
>> mfcr2_get_ani_first=no
>> mfcr2_max_ani=10
>> mfcr2_max_dnis=4
>> mfcr2_category=national_subscriber
>> mfcr2_mfback_timeout=-1
>> mfcr2_metering_pulse_timeout=-1
>> mfcr2_forced_release=no
>> context=from-pstn
>> group=0
>>
>> mfcr2_logdir=span1
>> mfcr2_call_files=yes
>> mfcr2_logging=all
>> channel => 1-10
>> ------------------------------------------
>>
>>
>> Unless I just got blind, everything is by the book (and this setup
>> was working fine). These are the specifics of the system:
>>
>> OpenR2 1.3.2
>> Asterisk 1.8.21.0
>> Digium Wildcard TE121
>> Carrier: Telmex (México)
>> CentOS 6.4 (just recently did yum -y upgrade so everything is the
>> most recent version as of today)
>>
>>
>> Apart from checking the config files again and again, this is what I
>> also tried:
>>
>> - Plugging/unplugging the cable
>> - Rebooting
>> - Switching the card from PCIe slot
>>
>>
>> As you can imagine, Telmex says "its fine from my side". Since
>> everything started to malfunction with no users involved, my guts
>> tell me its them, not us. How can I prove it with a Digium card? I
>> know the commands from Sangoma for wanpipe debugging, but this cards
>> are not my strongest point when it comes to debugging.
>>
>> Any ideas? Any commands I can execute to mail Telmex and prove whose
>> fault is this?
>>
>> Regards,
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-r2 mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-r2 mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-r2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20130509/7598a313/attachment-0001.htm>
More information about the asterisk-r2
mailing list