Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

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.

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

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.

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.

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.

The test TC_establish_and_nothing now passes, so we can close this now.