[asterisk-ss7] Link inactivity detection with dahdi based MTP2

[Marcelo Pacheco]

Hi Matt,

I might do this myself.
I know 'C' more than enough to get it done. I just don't have enough
kernel programming experience yet.
So far my priority is making dahdi_dynamic_loc work concurrently with
dahdi_dynamic_eth for testing. The current dahdi code lets
dahdi_dynamic_eth work, but dahdi_dynamic_loc doesn't (it freezes the
kernel, see https://issues.asterisk.org/view.php?id=15210), my work
around is barelly good enough for testing asterisk over local dynamic
channels, but too unstable for production, and dahdi_dynamic_eth crashes
quickly with the work around. Once I figure this out, I'll take a crack
at this mtp2 feature, as well as moving mtp2 to generic dahdi, so it
works for any channel capable of running a dchan (I need it work work
with dahdi_dynamic and non digium E1 cards).

If you could take a look at bug 15210 and give me any sugestion, I'm all
ears.

Marcelo

Matthew Fredrickson wrote:
> Marcelo Pacheco wrote:
>   
>> Hi Matt and asterisk-ss7 members,
>>
>> Looking at the dahdi-linux code, there seems to be an important feature
>> lacking on the dahdi mtp2 feature:
>>
>> Should the mtp channel go down, without the E1/T1 span go down (no
>> alarms), there's no notification sent to the application (usually asterisk).
>>
>>
>> I suggest an inactivity timer be implemented on dahdi, so if no new mtp2
>> messages get received over a 100ms period, a HDLC Abort message (or any
>> other specific message) gets send to userland. This way should libss7
>> receive say, 2 messages in close proximity it will consider the link
>> dead and initiate realignment.
>>
>> Additionally should this error condition be raised to userland, upon
>> receiving a valid repeated message, it would be sent to userland to
>> indicate things are back to normal.
>>
>> Without this, technically libss7 isn't compliant with a few of Q.7xx
>> specs. I've seen real world situations where lack of this feature would
>> cause serious problems.
>>
>> Specially this would be a serious issue with E1 links between Asterisk
>> and a TDM switch, where the signalling link is switched to a STP using a
>> semi permanent call. Should the STP or the link between the TDM switch
>> and the STP die, the only available indication would be that the
>> signalling link would go dead (with perhaps one HDLC Abort or CRC error
>> being detected, should the link go down preciselly between FISUs, then
>> no error at all might be detected). This is very common in Brazil, the
>> largest carriers use this layout exclusively on interconnects.
>>
>>
>> Matt, what do you think ? Do you have a better suggestion than an Abort
>> message ?
>>     
>
> Actually, this sounds like a very good idea.  I think that a better 
> indication might be a specific event related to this though, rather than 
> trying to overload abort events (since you can legitimately have abort 
> events on a link).  I will think about this and see if I can implement 
> something like this for the next release of DAHDI.
>
> Matthew Fredrickson
> Digium, Inc.
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-ss7
>
>