SS request results in lingering lchan
SS codes such as *#21# are not handled correctly
Output on the HLR:
Fri Oct 12 14:55:26 2018 DSS <0004> hlr_ussd.c:467 262420312915730/0x20000003: Process SS (BEGIN) Fri Oct 12 14:55:26 2018 DSS <0004> hlr_ussd.c:401 262420312915730/0x20000003: SS CompType=Invoke, OpCode=IngerrogateSS
Fri Oct 12 14:55:56 2018 DSS <0004> hlr_ussd.c:195 262420312915730/0x20000003: SS Session Timeout, destroying
But osmo-bsc still has:
OsmoBSC# show lchan s BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4, Lchan 0, Type SDCCH, State ESTABLISHED - L1 MS Power: 5 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -56 dBm OsmoBSC#
and this persists, with some phones, forever.
#1 Updated by keith over 1 year ago
#2 Updated by fixeria over 1 year ago
- Project changed from Cellular Network Infrastructure to OsmoHLR
- Status changed from New to Feedback
- Assignee set to fixeria
- Priority changed from Normal to High
- % Done changed from 0 to 90
thanks for this report!
I've managed to reproduce the problem in my virtual network,
and implemented a fix for that, please see:
In short, the problem is that 'structured' SS requests are not answered at all.
We should reject such requests by sending returnError message until we start to support them.
#3 Updated by keith over 1 year ago
Nice! Thanks for fixing that!
I wonder if there should be some kind of "failsafe" timer also on the MSC (or maybe it's BSC side) that would shutdown the channel in the case that the HLR became unresponsive.
I should have also included a trace of the call that I mentioned in the email.. Let me try to get that now before I pull your HLR patch....
#4 Updated by keith over 1 year ago
OK, Maybe I'll make a new ticket for this, but as it is possibly not easy to reproduce without the bug mentioned here, I'll put it here for now..
This is what I do and what I observe, using a Nokia 6070.
Dial *#21# + SEND
Phone says Requesting.. and I observe SDCCH activity on the spectrum Uplink.
I press END on the phone.
Phone says Request not Confirmed, appears to go to standby and SDCCH Uplink actvity continues.
I call a number on phone and press SEND
Phone immediately says "Error in connection" and I observe TCH activity on spectrum.
Phone appears to returns to standby and TCH continues.
BSC at this point shows:
OsmoBSC# show lchan s BTS 0, TRX 0, Timeslot 1 TCH/F, Lchan 0, Type TCH_F, State ESTABLISHED - L1 MS Power: 5 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -50 dBm
Some several minutes later, phone TX is still active, TCH is still active.
I issue drop bts from BSC
Phone display shows Request not completed
(in the pcap, I didn't wait so long before dropping the bts)
#7 Updated by keith over 1 year ago
With the HLR patch in place, the KRZR now camps, issues the SS and goes idle. All Good. :)
Subsequently calling the KRZR from the Nokia (with the error provoked in freeswitch by #3650) results in a lingering SDCCH on the KRZR!
(with osmo-sip-connector patched to override the payload_type, call sets up, connects, and completes with success)
Still, It strikes me we are missing something. abis pcap of the above attached.
#10 Updated by fixeria over 1 year ago
I wonder if there should be some kind of "failsafe" timer
also on the MSC (or maybe it's BSC side) that would shutdown
the channel in the case that the HLR became unresponsive.
Yep, definitely. I created an issue, please see: #3655.
With the HLR patch in place, the KRZR now camps,
issues the SS and goes idle. All Good. :)
Should we mark this issue as "resolved" then?
Subsequently calling the KRZR from the Nokia
results in a lingering SDCCH on the KRZR!
If it's still related to the SS/USSD, I am feeling a bit lost :)
#11 Updated by fixeria about 1 year ago
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
The following test case confirms that the problem was actually solved: