Since I developed the basic transport of MTP2 over UDP, I'm now able to use iptables to cause MTP2 messages to be dropped and watch the result, when the MTP2 is running over UDP. The MTP2 over UDP uses almost exactly the same functionality of DAHDI MTP2 channels, almost exact same behavior, except for a 200ms FISU / LSSU heartbeat (instead of continuous transmissions in dchan mode or no repetition at all between Asterisk and DAHDI in MTP2 mode). This lead to a very disturbing discovery ! If I fully block MTP2 messages between two Asterisk / libss7 endpoints, and cause MSUs to be sent by libss7 (but dropped by iptables): 1 - libss7 never times out, no periodic retransmissions (when you send an MSU, you must wait X miliseconds, if an ACK isn't received, retransmission must take place automatically), X should be configurable (depending on link round trip time), after Y failed retransmissions, the link must be faulted ! 2 - since it never retransmits, it never faults the MTP2 link 3 - retransmission only happens when a new MSU gets sent/received 4 - Receipt of FISUs showing missed MSUs are ignored !!!!! I got an IAM sent followed by a REL (try to place the call, hangup, without the other side ever receiving it, so no ACM/ANM/RLC backwards at this time) I left iptables DROP rules for 10 minutes, no retransmissions. Drop the iptables rules The MTP2 over UDP implementation sends FISUs every 200ms, so proper FISUs are being sent. The side with MSUs in the transmit queue is now receiving FISUs with received BSN < send FSN (the MSUs were not received by the other side), again, no retransmits performed Wait another 10 minutes, just in case Still no retransmissions, because no MSUs were sent (no ISUP or MTP3 traffic so no new MSUs either way) Add another MSU (initiate another call, another IAM), now retransmissions happen. You might ask, isn't this the function of E1/T1/V.35 ALARMS ? Not quite, 99% of the times you talk to an ITU STP belonging to another carrier, the E1 circuit ends in a TDM switch belonging to the other carrier and get a cross connect (DACS) to the STP. So if there's an alarm between the other TDM switch and the STP, it doesn't affect the E1 between the TDM switch and yourself: Physical circuit topology: STP <---> Other TDM switch <----> Asterisk (typically TS 1-15, 17-31 voice to the TDM switch, TS 16 DACS to the STP) The MTP2 link is between Asterisk and the STP, just one E0/DS0 is switched across, so alarms don't carry through. While this might work if everything is OK, this is completely outside proper MTP2 functionality, add this to the FACT that DAHDI MTP2 doesn't distinguish from (I'm receiving FISUs all the time from the link is DEAD), and this is a recipe for headaches if the SS7 link goes silent without an alarm (for instance the E1 is connected to other switch that DACS connection to a PTS, and the E1 between the other switch and the PTS fails), even if you have two links with completely separate spans all the way, libss7 will queue MSUs on the failed link instead of rerouting them to the link that's left alive ! Not good. The only reason this doesn't bit you in the ass HARD is because when you have libss7 on one side and a TDM switch / STP with a proper MTP2 implementation, the other side will fault the link, but still, this is very sloppy implementation. This would never pass a complete certification test. -- Atenciosamente, Marcelo Pacheco M2J Comunica??es e Inform?tica Fixo: (27)2222-8118 / (27)2233-2296 Vivo: (27)9964-5440 Claro: (62)9161-9047 MSN: marcelo at macp.eti.br E-mail: marcelo at m2j.com.br
|