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

Wed Jan 11 10:50:22 CST 2012

Marcelo
Good luck, I think it’s crazy if unlatching pattern between Openr2 and dahdi, should be impossible and never could be happen to be, anyway it upon to when troubles coming up.
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: 11 January 2012 12:36
To: asterisk-r2 at lists.digium.com
Subject: Re: [asterisk-r2] Alarm on openR2 spans leave channels with RxCAS 0xC state

I'm still properly learning R2D, I know ISDN and ISUP well. go figure.

It seems the proper way to troubleshoot is to compare mfcr2 show channels with dahdi_tool, if the bits match and are both corrupt, then its not a openr2 bug, but something hardware/driver related. If the bits are in mismatch, then its an openr2 issue. I just thought about the dahdi_tool now, as I never used it with R2 before, just with T1 channel banks. Since the incorrect bits are received, if they show up on dahdi_tool, then it can't be the fault of openr2 generating improper signalling output.

I think I'll wait until it happens again, and then do the comparison. I'll report back.

Marcelo

On 01/11/12 10:44, Mc GRATH Ricardo wrote:
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<mailto:asterisk-r2-bounces at lists.digium.com> [asterisk-r2-bounces at lists.digium.com<mailto:asterisk-r2-bounces at lists.digium.com>] On Behalf Of Marcelo Pacheco [marcelo at m2j.com.br<mailto:marcelo at m2j.com.br>]
Sent: 10 January 2012 21:45
To: asterisk-r2 at lists.digium.com<mailto: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

--
_____________________________________________________________________
-- 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/c7130806/attachment-0001.htm>