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