[asterisk-r2] Only one channel IDLE, the others are BLOCK
Gerardo Barajas
gerardo.barajas at gmail.com
Fri May 10 12:06:16 CDT 2013
What about testing with lower versions of dahdi?
Saludos/Regards
--
Ing. Gerardo Barajas Puente
On Thu, May 9, 2013 at 5:06 PM, Moises Silva <moises.silva at gmail.com> wrote:
> If someone is able to reproduce this behavior (unstable bits after red
> alarm bouncing) I can take a look, however, if the ABCD bits as reported by
> the DAHDI driver are the problem, there is nothing openr2 can do as it
> trusts what DAHDI says
>
> Moy
>
>
>
> On Thu, May 9, 2013 at 4:53 PM, Marcelo Pacheco <marcelo at m2j.com.br>wrote:
>
>> 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>
>> 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
>>
>>
>>
>> --
>> _____________________________________________________________________
>> -- 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/20130510/fa998099/attachment-0001.htm>
More information about the asterisk-r2
mailing list