[asterisk-r2] Alarm on openR2 spans leave channels with RxCAS 0xC state

Moises Silva moises.silva at gmail.com
Tue Jan 10 16:42:07 CST 2012


On Tue, Jan 10, 2012 at 5:30 PM, Marcelo Pacheco <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

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


More information about the asterisk-r2 mailing list