[asterisk-r2] asterisk-r2 Digest, Vol 57, Issue 5
Edgar Cañizalez
ecaniz at gmail.com
Fri May 10 12:27:19 CDT 2013
cli>mfcr2 set idle 2
2013/5/10 <asterisk-r2-request at lists.digium.com>
> Send asterisk-r2 mailing list submissions to
> asterisk-r2 at lists.digium.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.digium.com/mailman/listinfo/asterisk-r2
> or, via email, send a message with subject or body 'help' to
> asterisk-r2-request at lists.digium.com
>
> You can reach the person managing the list at
> asterisk-r2-owner at lists.digium.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of asterisk-r2 digest..."
>
>
> Today's Topics:
>
> 1. Re: Only one channel IDLE, the others are BLOCK (Gerardo Barajas)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 10 May 2013 12:06:16 -0500
> From: Gerardo Barajas <gerardo.barajas at gmail.com>
> Subject: Re: [asterisk-r2] Only one channel IDLE, the others are BLOCK
> To: asterisk-r2 at lists.digium.com
> Message-ID:
> <
> CAOQhXxEH0aOORX1mQwKjgijMUw4LvY6q3wCQUT6WNqxqc-QR0w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.htm
> >
>
> ------------------------------
>
> _______________________________________________
> --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
>
> End of asterisk-r2 Digest, Vol 57, Issue 5
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20130510/76a8fc89/attachment.htm>
More information about the asterisk-r2
mailing list