Feature #3102
Updated by neels about 6 years ago
After issue #3041 was fixed by the new gscon FSM, it became apparent that the a_reset.c FSM is actually no longer used at all: a_reset_conn_fail() is never invoked. I also noticed in osmo_bsc_reset.c, we have an evil twin of a_reset.c still in the code base. Its events also seem to never be invoked. (BTW, in osmo-msc, we also never invoke a_reset_conn_fail()) In summary, the Reset FSMs are in desperate need of some tender loving care, they are currently abandoned and useless, apparently. The proper trigger to invoke a_reset_conn_fail(): it was mentioned that specific N-Disconnect causes indicate a failure versus a normal disconnect. a_reset_conn_fail() should only be invoked upon receiving such failure cause. If possible, some ttcn3 test should simulate such a failure disconnect. Also debatable is the conn_loss_count: if there are only two SCCP connections, and both of them go up in flames, the reset FSM should probably not wait for a third erratic disconnect; it should fire a BSSMAP BSSAP Reset as well?