[asterisk-r2] Only one channel IDLE, the others are BLOCK

Moises Silva moises.silva at gmail.com
Thu May 9 17:06:24 CDT 2013


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20130509/2e3471c2/attachment-0001.htm>


More information about the asterisk-r2 mailing list