<div dir="ltr">cli>mfcr2 set idle 2<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/10 <span dir="ltr"><<a href="mailto:asterisk-r2-request@lists.digium.com" target="_blank">asterisk-r2-request@lists.digium.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send asterisk-r2 mailing list submissions to<br>
<a href="mailto:asterisk-r2@lists.digium.com">asterisk-r2@lists.digium.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-r2" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:asterisk-r2-request@lists.digium.com">asterisk-r2-request@lists.digium.com</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:asterisk-r2-owner@lists.digium.com">asterisk-r2-owner@lists.digium.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of asterisk-r2 digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Only one channel IDLE, the others are BLOCK (Gerardo Barajas)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 10 May 2013 12:06:16 -0500<br>
From: Gerardo Barajas <<a href="mailto:gerardo.barajas@gmail.com">gerardo.barajas@gmail.com</a>><br>
Subject: Re: [asterisk-r2] Only one channel IDLE, the others are BLOCK<br>
To: <a href="mailto:asterisk-r2@lists.digium.com">asterisk-r2@lists.digium.com</a><br>
Message-ID:<br>
<<a href="mailto:CAOQhXxEH0aOORX1mQwKjgijMUw4LvY6q3wCQUT6WNqxqc-QR0w@mail.gmail.com">CAOQhXxEH0aOORX1mQwKjgijMUw4LvY6q3wCQUT6WNqxqc-QR0w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
What about testing with lower versions of dahdi?<br>
<br>
Saludos/Regards<br>
--<br>
Ing. Gerardo Barajas Puente<br>
<br>
<br>
<br>
On Thu, May 9, 2013 at 5:06 PM, Moises Silva <<a href="mailto:moises.silva@gmail.com">moises.silva@gmail.com</a>> wrote:<br>
<br>
> If someone is able to reproduce this behavior (unstable bits after red<br>
> alarm bouncing) I can take a look, however, if the ABCD bits as reported by<br>
> the DAHDI driver are the problem, there is nothing openr2 can do as it<br>
> trusts what DAHDI says<br>
><br>
> Moy<br>
><br>
><br>
><br>
> On Thu, May 9, 2013 at 4:53 PM, Marcelo Pacheco <<a href="mailto:marcelo@m2j.com.br">marcelo@m2j.com.br</a>>wrote:<br>
><br>
>> I have seen this happen when there are quick alarm on the trunk,<br>
>> OK->RED, 1-4 seconds later, RED->OK, check for alarms on the log.<br>
>> If it's this problem, a dahdi restart will rectify.<br>
>> Let the developers know, I'm trying to get 100% rid of all MFC R2 with<br>
>> Asterisk due to this kind of issues, but ISDN is impossible to obtain in<br>
>> the countryside.<br>
>><br>
>> Marcelo<br>
>><br>
>><br>
>> On 05/09/13 17:00, ServTelar wrote:<br>
>><br>
>> Check the bit status using dahdi_tool. ABCD=1101 means block, 1001 means<br>
>> idle (showing in vertical).<br>
>><br>
>> ????????????????? T4XXP (PCI) Card 0 Span 3 ??????????????????<br>
>><br>
>> ???????<br>
>> ? ?????<br>
>><br>
>> ? ?<br>
>> ? ?<br>
>><br>
>> ? ? Current Alarms:<br>
>> No alarms. ? ?<br>
>><br>
>> ? ? Sync Source:<br>
>> T4XXP (PCI) Card 0 Span 1 ? ? ?<br>
>><br>
>> ? ? IRQ Misses:<br>
>> 0 ? ? ?<br>
>><br>
>> ? ? Bipolar Viol:<br>
>> 0 ? ? ?<br>
>><br>
>> ? ? Tx/Rx Levels:<br>
>> 0/ 0 ? ? ?<br>
>><br>
>> ? ? Total/Conf/Act:<br>
>> 31/ 30/ 30 ? ? ?<br>
>><br>
>> ? ?<br>
>> 1111111111222222222233 ???????? ? ? ?<br>
>><br>
>> ? ?<br>
>> 1234567890123456789012345678901 ? Back ? ? ? ?<br>
>><br>
>> ? ? TxA<br>
>> 111111111111111 111111111111111 ???????? ? ? ?<br>
>><br>
>> ? ? TxB<br>
>> 111111111111111 111111111111111 ? ? ?<br>
>><br>
>> ? ? TxC<br>
>> 000000000000000 000000000000000 ? ? ?<br>
>><br>
>> ? ? TxD<br>
>> 111111111111111 111111111111111 ? ?<br>
>><br>
>> ? ?<br>
>> ? ?<br>
>><br>
>> ? ? RxA<br>
>> 111111111111111 111111111111111 ? ?<br>
>><br>
>> ? ? RxB<br>
>> 011111111111111 111111111111111 ? ?<br>
>><br>
>> ? ? RxC<br>
>> 000000000000000 000000000000000 ? ?<br>
>><br>
>> ? ? RxD<br>
>> 111111111111111 111111111111111<br>
>><br>
>> In this case just ch=1 is receiving idle, the rest are blocked, and<br>
>> we're transmitting blocked.<br>
>><br>
>> Regards<br>
>><br>
>> Gustavo<br>
>><br>
>><br>
>> On May 9, 2013, at 3:51 PM, Christian Cabrera <<a href="mailto:ccabrera@gmail.com">ccabrera@gmail.com</a>><br>
>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> Recently, the E1 of one of my clients stopped "almost" working. They<br>
>> have a 10 channel E1 with R2, but only the first channel appears as IDLE,<br>
>> while the remaining stay at BLOCK.<br>
>><br>
>> Here's what the mfcr2 show channels throws:<br>
>><br>
>> Chan Variant Max ANI Max DNIS ANI First Immediate Accept Tx CAS Rx CAS<br>
>> 1 MX 10 4 No No IDLE IDLE<br>
>> 2 MX 10 4 No No IDLE BLOCK<br>
>> 3 MX 10 4 No No IDLE BLOCK<br>
>> 4 MX 10 4 No No IDLE BLOCK<br>
>> 5 MX 10 4 No No IDLE BLOCK<br>
>> 6 MX 10 4 No No IDLE BLOCK<br>
>> 7 MX 10 4 No No IDLE BLOCK<br>
>> 8 MX 10 4 No No IDLE BLOCK<br>
>> 9 MX 10 4 No No IDLE BLOCK<br>
>> 10 MX 10 4 No No IDLE BLOCK<br>
>><br>
>><br>
>> The configuration is as usual. Here's my system.conf:<br>
>><br>
>> ------------------------------------------<br>
>> span=1,1,0,cas,hdb3<br>
>> cas=1-15:1101<br>
>> cas=17-31:1101<br>
>> echocanceller=mg2,1-15,17-31<br>
>><br>
>> loadzone = mx<br>
>> defaultzone = mx<br>
>> ------------------------------------------<br>
>><br>
>><br>
>> And here's my chan_dahdi.conf<br>
>><br>
>> ------------------------------------------<br>
>> signalling=mfcr2<br>
>> mfcr2_variant=mx<br>
>> mfcr2_get_ani_first=no<br>
>> mfcr2_max_ani=10<br>
>> mfcr2_max_dnis=4<br>
>> mfcr2_category=national_subscriber<br>
>> mfcr2_mfback_timeout=-1<br>
>> mfcr2_metering_pulse_timeout=-1<br>
>> mfcr2_forced_release=no<br>
>> context=from-pstn<br>
>> group=0<br>
>><br>
>> mfcr2_logdir=span1<br>
>> mfcr2_call_files=yes<br>
>> mfcr2_logging=all<br>
>> channel => 1-10<br>
>> ------------------------------------------<br>
>><br>
>><br>
>> Unless I just got blind, everything is by the book (and this setup was<br>
>> working fine). These are the specifics of the system:<br>
>><br>
>> OpenR2 1.3.2<br>
>> Asterisk 1.8.21.0<br>
>> Digium Wildcard TE121<br>
>> Carrier: Telmex (M?xico)<br>
>> CentOS 6.4 (just recently did yum -y upgrade so everything is the most<br>
>> recent version as of today)<br>
>><br>
>><br>
>> Apart from checking the config files again and again, this is what I<br>
>> also tried:<br>
>><br>
>> - Plugging/unplugging the cable<br>
>> - Rebooting<br>
>> - Switching the card from PCIe slot<br>
>><br>
>><br>
>> As you can imagine, Telmex says "its fine from my side". Since<br>
>> everything started to malfunction with no users involved, my guts tell me<br>
>> its them, not us. How can I prove it with a Digium card? I know the<br>
>> commands from Sangoma for wanpipe debugging, but this cards are not my<br>
>> strongest point when it comes to debugging.<br>
>><br>
>> Any ideas? Any commands I can execute to mail Telmex and prove whose<br>
>> fault is this?<br>
>><br>
>> Regards,<br>
>><br>
>> --<br>
>> _____________________________________________________________________<br>
>> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
>><br>
>> asterisk-r2 mailing list<br>
>> To UNSUBSCRIBE or update options visit:<br>
>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-r2" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> _____________________________________________________________________<br>
>> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
>><br>
>> asterisk-r2 mailing list<br>
>> To UNSUBSCRIBE or update options visit:<br>
>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-r2" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> _____________________________________________________________________<br>
>> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
>><br>
>> asterisk-r2 mailing list<br>
>> To UNSUBSCRIBE or update options visit:<br>
>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-r2" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br>
>><br>
><br>
><br>
> --<br>
> _____________________________________________________________________<br>
> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
><br>
> asterisk-r2 mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-r2" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.digium.com/pipermail/asterisk-r2/attachments/20130510/fa998099/attachment.htm" target="_blank">http://lists.digium.com/pipermail/asterisk-r2/attachments/20130510/fa998099/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
asterisk-r2 mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-r2" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br>
<br>
End of asterisk-r2 Digest, Vol 57, Issue 5<br>
******************************************<br>
</blockquote></div><br></div>