TTCN3 test TC_mo_setup_and_nothing does not pass
The TTCN3 test TC_mo_setup_and_nothing establishes a call until SETUP and then remains silent. A clear from the MSC comand is expected but there seem to be no clear command. This must be investigated because the failure of the test could mean that a call establishment could forever.
#2 Updated by dexter about 1 year ago
I have now analyzed the problem. I think the main issue here is the MNCC, where the Call-Control actually happens. From my understanding the test stops at the setup. Normally one would expect the MNCC to detect that nothing else is happening and the MNCC then would release the call again. However, the test also seems to be silent on the MNCC socket. Since sccp and mncc are silent, nothing happens anymore.
gsm_04_08_cc.c is controlling the MNCC and there are already timeouts implemented. However, in some places timeouts seem to be missing. We should check the calls to mncc_recvmsg() and see if there is a timeout in place that releases the call in case the MNCC remains silent.
As an experiment I added a call to gsm48_start_cc_timer(trans, 0x303, GSM48_T303) in gsm48_cc_rx_setup(), right after mncc_recvmsg(). Attached one finds the trace of the result. The timeout T303 is 30sec. In the trace one can see that after 30sec. the call gets released. I think this looks much better now.
#3 Updated by dexter about 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
I have now added a timeout of 25 sec. When the remote part of the MNCC (osmo-sip-connector) does not respond to the setup. The timout will hard clear the connection, as TC_mo_setup_and_nothing expects it.
To my knowledge the response to a SETUP should be almost immediate, so I think a timeout of 25 sec is ok here. However, I am not quite sure if the response to the setup does not depend on responses of the remote SIP end. As far as I understood its generated or rejected immediately. However I might be wrong and we may have to reconsider the timeout length.
See also: https://gerrit.osmocom.org/#/c/osmo-msc/+/11265 mncc: protect against non responsive MNCC during setup
#4 Updated by dexter about 1 year ago
I did some practical tests. When an MO-Call is placed and the other leg does not pick up, the timer I added indeed terminates the call early. This is not good, I thought there were more timer usage for MO-Calls that would stop/reschedule the timer but there is no timer activity at all when an MO-Call is placed.
I have now stop the timer when the MNCC_ALERT_REQ is received on MNCC. This means we are protected until the other end alerts. I kind of like the idea to have a global guard timer that only stops when the call is established. This would also prevent from subscribers who block the net by letting the phone ringing infinitely. The other way would be to work along the state machine. As I can see MNCC_ALERT_REQ is sent in regular intervals. We could reschedule a timer to check on that as well. However. Using a global guard timer would be way easier.
#5 Updated by dexter about 1 year ago
- % Done changed from 50 to 60
I have added a global guard timer that is also configurable via VTY, the patch is still under review: https://gerrit.osmocom.org/#/c/osmo-msc/+/11307/
Then I extended the guard timer in TTCN3, but as neels said its probably better to shorten the timeout in osmo-bsc artificially via VTY. I hope doing so will not mess up other testcases.
See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11391/
We also have hardcoded timeouts in MGCP FSM. We probably might want to make those configurable as well, however, this is not in scope of this particular task.
#6 Updated by dexter about 1 year ago
- % Done changed from 60 to 90
The patch https://gerrit.osmocom.org/#/c/osmo-msc/+/11307/ is still in review, thats why TC_establish_and_nothing does not pass yet. I have tested everything now with current master of the ttcn3 test, it looks good to me. When 11307 is marged TC_establish_and_nothing should pass.