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

[Mc GRATH Ricardo]

Marcelo
As you report your problem, isn’t regardless to DAHDI or software trouble, by the way restarting DAHDI service is same as unplug and plug RJ45 connector.
By the way  Rx CAS 0xC state is related to PSTN frame, I guest problem could becomes PSTN side it loose Asterisk frame or shifted, whatever, these is what be called transmission problem or end mile installation, as could be possible it  should be analyzed by E1 protocols instrumental time after problem it evidence, it take time.
It common happens when frame is shifted by SDH units or wiring etc, between PSTN and customer side, Rx CAS 0xC state PSTN switch class after receiving a long rate of frame error it set block state.
I hope these could be help to find out the problem.
Best regards
 Mc GRATH Ricardo
E-Mail mcgrathr at mail2web.com<mailto:mcgrathr at mail2web.com>
________________________________
From: asterisk-r2-bounces at lists.digium.com [asterisk-r2-bounces at lists.digium.com] On Behalf Of Marcelo Pacheco [marcelo at m2j.com.br]
Sent: 10 January 2012 21:45
To: asterisk-r2 at lists.digium.com
Subject: Re: [asterisk-r2] Alarm on openR2 spans leave channels with RxCAS 0xC state

Moises,

Sure. I'll test it. Are you confident no changes were made that could fix this from 1.3.1 -> 1.3.2 ? I just upgraded, not enough time to notice if this is fixed.

Could this be a TDM card driver bug ? How does the DAHDI driver passes CAS bit changes to userland (change notifications, or userland constantly polls the bits and compare with the prior value) ? Perhaps could the driver be failing to pass changes in the bits to userland right after the alarm clears, keeping some corrupted state read during the alarm. Its interesting that 80+% of times this happens, only 3-6 channels get blocked with 0xC.

Marcelo

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/20120111/dee0e0d1/attachment.htm>