[asterisk-r2] Alarm on openR2 spans leave channels with RxCAS 0xC state
Marcelo Pacheco
marcelo at m2j.com.br
Sat Jan 14 15:05:05 CST 2012
I saw the issue again on two customers.
This time I used dahdi_tool to compare the CAS bits.
On one customer, I have this on mfcr2 show channels:
Tx CAS Rx CAS
CLEAR BA 0x08
IDLE IDLE
IDLE 0x08
For instance this time, I see 4 channels with Rx CAS 0x08 (3 Tx IDLE, 1
Tx CLEAR BA).
The CLEAR BA 0x8 shows Tx 1101 Rx 1001 on dahdi_tool, all other channels
show Tx 1001 Rx 1001 on dahdi_tool, including the IDLE 0x08 channels.
It looks like this is a openr2 bug.
My guess is this happens when the E1 span gets an alarm with active
calls, the active calls get this Rx CAS 0x08 indication.
Anyhow, the workaround is a nightly module unload / module load on
chan_dahdi.so.
Moises, if you have a patch, I will be very happy to test it, once you
provide it, I'll apply it overnight, and it should take me a week to
report back if it fixes the issue, or a few days if it happens again.
Regards,
Marcelo Pacheco
M2J Communications - Brazil
On 01/10/12 20:42, Moises Silva wrote:
> On Tue, Jan 10, 2012 at 5:30 PM, Marcelo Pacheco <marcelo at m2j.com.br
> <mailto:marcelo at m2j.com.br>> wrote:
>
> I have the following chan_dahdi.conf (asterisk 1.6.2.18 / dahdi
> 2.3.0.1 / openR2 1.3.1):
>
> [channels]
> usecallerid=yes
> echocancel=no
> echocancelwhenbridged=no
>
> signalling=mfcr2
> mfcr2_variant=br
> mfcr2_forced_release=no
> mfcr2_get_ani_first=no
> mfcr2_category=national_subscriber
> mfcr2_allow_collect_calls=yes
> mfcr2_double_answer=no
>
> context=entrada
> group=1
> mfcr2_max_ani=14
> mfcr2_max_dnis=4
> channel => 1-15,17-21
>
> context=geral
> group=2
> mfcr2_max_ani=4
> mfcr2_max_dnis=16
> channel => 32-46,48-52
>
> And the following /etc/dahdi/system.conf
>
> span=1,1,0,cas,hdb3
> span=2,0,0,cas,hdb3
> span=3,0,0,esf,b8zs
> span=4,0,0,ccs,hdb3
> cas=1-15,17-21:1101
> cas=32-46,48-52:1101
> fxoks=63-86
> bchan=87-101,103-117
> dchan=102
> echocanceller=mg2,1-15,17-21,32-46,48-52,63-86
> loadzone = us
> defaultzone=us
>
>
> /etc/asterisk/chan_dahdi.conf (removed the comments to save space)
>
> [channels]
> usecallerid=yes
> callwaiting=no
> usecallingpres=yes
> callwaitingcallerid=yes
> threewaycalling=yes
> transfer=yes
> canpark=yes
> cancallforward=yes
> callreturn=yes
> echocancel=yes
> echocancelwhenbridged=no
>
> group=1
> callgroup=1
> pickupgroup=1
>
> signalling=mfcr2
> mfcr2_variant=br
> mfcr2_forced_release=no
> mfcr2_get_ani_first=no
> mfcr2_category=national_subscriber
> mfcr2_max_ani=14
> mfcr2_max_dnis=4
> mfcr2_allow_collect_calls=yes
> context=entrada
> group=1
> channel => 1-15,17-21
>
> mfcr2_max_ani=8
> mfcr2_max_dnis=16
> context=geral
> group=2
> channel => 32-46,48-52
>
>
> switchtype=euroisdn
> signalling=pri_net
> group=4
> context=geral
> channel => 87-101,103-117
>
>
> Frequently, after we get an alarm and the alarm clears, some or
> all channels are left with Rx CAS 0xC state.
> Reloading dahdi solves the issue, but it's extremely undesirable
> since this condition might leave no channels or very few channels
> in operable state for usage until restarting dahdi (and restarting
> dahdi kills all active dahdi calls). I just upgraded to OpenR2
> 1.3.2, but I saw nothing on the ChangeLog that might fix this.
>
>
> If you can reproduce this reliably and are willing to test a patch, I
> can write one.
>
> Can you reproduce the issue easily by unplugging/plugging the cable
> multiple times to generate alarms?
>
> *Moises Silva
> **/Software Engineer, Development Manager/***
>
> msilva at sangoma.com <mailto:msilva at sangoma.com>
>
> Sangoma Technologies
>
> 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada
>
>
>
>
> t. +1 800 388 2475 (N. America)
>
> t. +1 905 474 1990 x128
>
> f. +1 905 474 9223
>
>
>
> **
> <http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email+signatures>
>
> Products
> <http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> |
> Solutions
> <http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> |
> Events
> <http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> |
> Contact
> <http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> |
> Wiki
> <http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> |
> Facebook
> <http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> |
> Twitter
> <http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`|
> | YouTube
> <http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>
>
>
> --
> _____________________________________________________________________
> -- 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/20120114/8b815e73/attachment.htm>
More information about the asterisk-r2
mailing list