[asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP

Olivier oza_4h07 at yahoo.fr
Tue Jun 26 02:20:32 CDT 2012


2012/6/22, Olivier <oza_4h07 at yahoo.fr>:
> 2012/6/21, Richard Mudgett <rmudgett at digium.com>:
>>> My previous message was incomplete.
>>>
>>>
>>> On thing to note is I had to forbid hfcmulti in modprobe.d in the
>>> second box to comply with a warning from dahdi. Without that, I could
>>> see this line in the output of lsmod:
>>> mISDN-core  hfcmulti
>>>
>>>
>>> 1. What is the root cause that makes a board change its sync source ?
>>> How can I check this ?
>>
>> I would think layer 1 going down.
> I'm aware of this energy save mode.
> What surprises me a bit is the frequency with which this happens: a
> rough estimee is 60s or less before the line going down.
>
> Is there a practical way to double check that ? Using pri debug ?
> "core set debug" ?
>
>
>>  Many European telcos for BRI PTMP lines
>> drop layer 2 and then layer 1 to conserve power.
>>
>> Is the switching of clock sources causing a problem?
>
> Fortunately, beside having the log files cluttered with Alarm
> messages, the system is working ok.
>>
>>> 2.  How can I get rid of these alarms ?
>>
>> See the chan_dahdi.conf.sample file about the following options.
>>
>> You could use the layer1_presence option to make Asterisk ignore those
>> alarms.
>
> This is the option I will try.
> I'll report my findings here.

My findings, after setting layer1_presence=ignore in chan_dahdi.conf are :

  == Starting D-Channel on span 1
  == Starting D-Channel on span 2
  == Primary D-Channel on span 1 up
  == Primary D-Channel on span 2 up
foo*CLI> pri show spans
PRI span 1/0: Up, Active
PRI span 2/0: In Alarm, Down, Active
foo*CLI> pri show spans
PRI span 1/0: In Alarm, Down, Active
PRI span 2/0: Down, Active
foo*CLI> pri show spans
PRI span 1/0: Down, Active
PRI span 2/0: Down, Active
foo*CLI> pri show spans
PRI span 1/0: Down, Active
PRI span 2/0: Down, Active


So basically, "pri show spans" still reports lines being down, though
they are not.
So, my next option is to downgrade libpri to 1.4.10.2 and hope for a
better reporting.

>>
>> You could use the layer2_persistence option to keep layer 2 up.  To use
>> this option however, requires using libpri SVN 1.4 branch code as current
>> released versions do not support the option.
> I was aware of this improvement and I can't wait to see it published.
>
>>  Using the layer2_persistence
>> option restores behavior that was removed for better Q.921 conformance
>> for
>> PTMP after libpri v1.4.10.2 and is why you are seeing a behavior
>> difference
>> between versions.
>
> So, in a way, a better confiormance to Q.921 introduced the
> requirement to "explicitely ignore Layer1 status changes (in
> BRI/TE/PtmP) in chan_dahdi.conf".
>
> Though these layer1 and layer2 settings belongs to Asterisk's
> chan_dahdi.conf file, maybe an UPGRADE.txt file inside libpri
> directory would be useful to let sysadmins access to this information.
>
> What about adding an UPGRADE.txt in libpri ?
>
>>
>>> 3. Shall I report this ?
>>
>> It is normal with BRI PTMP lines.  It is also the reason for the
>> layer1_presence and layer2_persistence options.
>>
>>> 4. Waht would you suggest ?
>>>
>>> Regards
>>>
>>>
>>>
>>> 2012/6/21, Olivier <oza_4h07 at yahoo.fr>:
>>> > Hi,
>>> >
>>> > After an upgrade, I discovered yesterday strange things I would
>>> > like
>>> > to share here.
>>> >
>>> > Basically, I'me comparing platforms:
>>> > The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk
>>> > 1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3
>>> > and 2.5, I think).
>>> > The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk
>>> > 10.5.1, Libpri 1.4.12, Dahdi 2.6.1.
>>> > Both are connected to telco BRI lines in TE/PtmP mode through a
>>> > Junghanns QuadBRI board (wcb4xxp driver).
>>> > Both handle incoming and outgoing calls correctly, as far as I can
>>> > tell.
>>> >
>>> > But on the second one, though working fine, Dahdi keeps showing
>>> > alarm
>>> > messages such as:
>>> > [71765.784120] wcb4xxp 0000:01:0e.0: new card sync source: port 1
>>> > [71767.484151] wcb4xxp 0000:01:0e.0: new card sync source: port 1
>>> > [71771.184119] wcb4xxp 0000:01:0e.0: new card sync source: port 2
>>> > [71794.184164] wcb4xxp 0000:01:0e.0: new card sync source: port 1
>>> >
>>> > and "pri show spans" mostly (but not always) report worrying
>>> > status:
>>> > PRI span 1/0: Down, Active
>>> > PRI span 2/0: In Alarm, Down, Active
>>> >
>>> > On the first box "pri show spans" constantly reports the line is
>>> > up.
>>> >
>>> > On thing to note is I had to forbid hfcmulti in modprobe.d in the
>>> > second box to comply with a warning from dahdi. Without that, I
>>> > could
>>> > see this line in the output of lsmod:
>>> > mISDN-core
>>
>> Both mISDN and DAHDI have drivers for your BRI card.  Only one of them
>> should be loaded.  Since you are using DAHDI and not mISDN, you should
>> load the DAHDI version.
>>
>> Richard
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>                http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>



More information about the asterisk-users mailing list