Bug #4976
closed
network with no emergency calls - Is BSC still performing pre-emption?
Added by laforge over 3 years ago.
Updated over 3 years ago.
Description
It is suspected by a user that the following events may take place:
- netwokr does not permit/enable emergency calls
- sometimes, due to the bad RACH correlation properties, fals positive RACHs are detected
- some of those fall within the "emergency" category
- osmo-bsc is still pre-empting/kickning out some other channel
Based on a quick look of the code, this might be possible.
In fact, I don't understand why we even bother to enqueue a RACH request in this situation. IMHO, the check should be done before enqueueing the RACH request to bts->chan_rqd_queue if it is for RACH and we don't support RACH to begin with? But I'm not an expert on the related code.
Please investigate.
- Status changed from New to In Progress
- % Done changed from 0 to 80
I have checked this now back and its indeed the case that the preemption takes place even though emergency calls are disabled. I have fixed that now to check earlier if emergency calls are disabled. If an emergency call is detected even though emergency calling is disabled we must reject that call.
See also: https://gerrit.osmocom.org/c/osmo-bsc/+/22455 abis_rsl: check if emergency calling is disabled before preemption
I have moved up the check further up before the enqueuing of the request. This shouldn't make much of a difference, but it makes more sense.
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
dexter wrote:
I have moved up the check further up before the enqueuing of the request.
thanks, patch merged.
This shouldn't make much of a difference, ...
tell that to the callers whose calls get interrupted for no reason :/
On a busy network without emergency calls I would expect this to happen relatively often.
Also available in: Atom
PDF
