Bug #2882
closedOsmoMSC doesn't release call if BSS-side CRCX fails
100%
Description
If the CRCX on the RAN side fails, we are issuing a DLCX on that endpoint and I get some related log messages, but the call remains in its state. The call should of course be terminated as without the MGW endpoint in operation we will never have a user plane working.
<0007> fsm.c:243 MGW(MGW_8)[0x9de2210]{ST_CRCX_RAN}: Allocated
<0007> msc_mgcp.c:913 MGW(MGW_8)[0x9de2210]{ST_CRCX_RAN}: Received Event 0
<0007> msc_mgcp.c:236 MGW(MGW_8)[0x9de2210]{ST_CRCX_RAN}: CRCX/RAN: creating connection for the RAN side on MGW endpoint:0x1...
<0020> mgcp_client.c:641 Queued 65 bytes for MGCP GW
<0007> msc_mgcp.c:261 MGW(MGW_8)[0x9de2210]{ST_CRCX_RAN}: state_chg to ST_CRCX_CN
<0007> msc_mgcp.c:918 (subscriber:IMSI:262420000000028) call assignment initiated
<0020> mgcp_client.c:470 Tx MGCP msg to MGCP GW: 'CRCX 5 1@mgw MGCP 1.0'
<0020> mgcp_client.c:472 Sending msg to MGCP GW size: 65
<0007> msc_mgcp.c:280 MGW(MGW_8)[0x9de2210]{ST_CRCX_CN}: CRCX/RAN: response yields error: 542 FORCED_FAIL
<0007> msc_mgcp.c:281 MGW(MGW_8)[0x9de2210]{ST_CRCX_CN}: operation failed on MGW -- graceful shutdown...
<0007> msc_mgcp.c:157 MGW(MGW_8)[0x9de2210]{ST_CRCX_CN}: state_chg to ST_CALL
<0007> msc_mgcp.c:161 MGW(MGW_8)[0x9de2210]{ST_CALL}: Received Event 4
<0007> msc_mgcp.c:690 MGW(MGW_8)[0x9de2210]{ST_CALL}: DLCX: removing connection for the RAN and CN side on MGW endpoint:0x1...
<0020> mgcp_client.c:641 Queued 29 bytes for MGCP GW
<0007> msc_mgcp.c:718 MGW(MGW_8)[0x9de2210]{ST_CALL}: state_chg to ST_HALT
<0020> mgcp_client.c:470 Tx MGCP msg to MGCP GW: 'DLCX 6 1@mgw MGCP 1.0'
<0020> mgcp_client.c:472 Sending msg to MGCP GW size: 29
<0007> msc_mgcp.c:730 MGW(MGW_8)[0x9de2210]{ST_HALT}: DLCX: response yields error: 250 OK
<0007> msc_mgcp.c:731 MGW(MGW_8)[0x9de2210]{ST_HALT}: operation failed on MGW -- graceful shutdown...
<0007> msc_mgcp.c:157 MGW(MGW_8)[0x9de2210]{ST_HALT}: transition to state ST_CALL not permitted!
<0007> msc_mgcp.c:161 MGW(MGW_8)[0x9de2210]{ST_HALT}: Received Event 4
<0007> msc_mgcp.c:759 MGW(MGW_8)[0x9de2210]{ST_HALT}: state_chg to ST_HALT
<0012> input/ipa.c:67 connection closed with server
As an oddity, the client code seems to have the opinion that 250 is an error response to DLCX.
MSC_Tests.TC_mo_crcx_ran_reject
Files
Updated by laforge about 6 years ago
- File 20180127-osmomsc-mtcall-ran-crcx-reject.pcap 20180127-osmomsc-mtcall-ran-crcx-reject.pcap added
This also appears to be true in MT calls. See attachment from MSC_Tests.TC_mt_crcx_ran_reject
Updated by dexter about 6 years ago
- % Done changed from 0 to 100
The cause of the problem here is the same as in #2881. The problem is now fixed and the TTCN3 tests pass
#MSC_Tests.TC_mo_crcx_ran_reject #pass #MSC_Tests.TC_mt_crcx_ran_reject #pass
Updated by dexter about 6 years ago
- % Done changed from 100 to 90
Unfortunately we seem to have a regression here, this needs to be checked.
#MSC_Tests.TC_mo_crcx_ran_reject #pass #MSC_Tests.TC_mt_crcx_ran_reject #fail
Updated by dexter about 6 years ago
- % Done changed from 90 to 100
I have checked why MSC_Tests.TC_mt_crcx_ran_reject failes. The reason for this was a bug in the testcase and also a bug in the error handling of msc_mgcp.c
https://gerrit.osmocom.org/7767 MSC_Tests: fix TC_mo_crcx_ran_reject
https://gerrit.osmocom.org/7763 msc_mgcp: do not send wildcarded DLCX messages
I did not verify the TTCN3 part of this change in docker. Since I did not change any config files here I am confident that this is not causing a large fallout. If I should check it anyway, please let me know.
Updated by dexter about 6 years ago
- Status changed from In Progress to Resolved
The patches are now merged and he test TC_mo_crcx_ran_reject now passes again in jenkins. I think we can set this to resolved now.
