[asterisk-r2] Alarm on openR2 spans leave channels with RxCAS 0xC state
Marcelo Pacheco
marcelo at m2j.com.br
Wed Jan 11 09:36:46 CST 2012
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
> [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 byhttp://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/5f6d51f3/attachment-0001.htm>
More information about the asterisk-r2
mailing list