Project

General

Profile

Bug #3263

assignment will fail if chan_mode is already compatible with lchan

Added by neels 7 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/14/2018
Due date:
% Done:

0%

Spec Reference:

Description

I'm not perfectly sure of the practical implications, but in osmo-bsc's code base I see:

http://git.osmocom.org/osmo-bsc/tree/src/libbsc/bsc_subscr_conn_fsm.c#n536

        rc = gsm0808_assign_req(conn, conn->user_plane.chan_mode, conn->user_plane.full_rate);
        if (rc != 0) {
            resp = gsm0808_create_assignment_failure(GSM0808_CAUSE_RQSTED_SPEECH_VERSION_UNAVAILABLE, NULL);

and http://git.osmocom.org/osmo-bsc/tree/src/libbsc/bsc_api.c#n317

int gsm0808_assign_req(struct gsm_subscriber_connection *conn, int chan_mode, int full_rate)
{
[...]
        /* Check if the channel is already in the requested mode, if
         * yes, we skip unnecessary channel mode modify operations. */
        if (conn->lchan->tch_mode == chan_mode)
            return 1;

i.e., if gsm0808_assign_req() returns 1 to signal an already matching tch_mode, then we go on to trigger an assignment failure, which can't be right.

It is likely that this code will get refactored in the current inter-bsc handover effort, but now that I noticed it I'd like to track the bug separately.
I wonder how exactly we could trigger this bug: don't we release all TCH when done, so that they are by definition always in an uninitialized tch_mode?

Also available in: Atom PDF