[asterisk-ss7] Another STRANGE "feature/bug" of libss7 !

[Marcelo Pacheco]

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