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

[Marcelo Pacheco]

I noticed openr2 doesn't discard signalling if the fixed bits (usually 
01) are different from the proper settings.
I changed src/r2proto.c, function openr2_proto_handle_cas:

    adding:
  if ((cas & 3) != r2chan->r2context->cas_nonr2bits)
  { // Treat NON CAS bits diferent than expected as an invalid CAS bits
    r2chan->cas_tx_signal = OR2_CAS_INVALID;
    return 0;
   }
   /* pick up only the R2 bits */ <- This comment already existed

In addition, ignore alarms (continue handling input CAS bits as normal).
Now searching for that pesky bleed through of configurations of spans 
with 15 or less channels.

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 byhttp://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/20120207/68a8519d/attachment.htm>