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.
|