|author||Neels Hofmeyr <firstname.lastname@example.org>||2018-12-19 13:43:28 +0100|
|committer||Neels Hofmeyr <email@example.com>||2019-01-24 17:48:52 +0100|
fix lchan modifications: switch off re-using lchan during assignmentneels/call_during_call
Always set up a fresh lchan for both SDCCH->TCH/* as well as call-during-call, which allows these scenarios to properly set up an RTP stream. Disable lchan re-use on repeated Assignment Requests: so far the lchan FSM does RTP handling properly *only* when it 'requires_voice_stream' from the start. The nicer way to support call-during-call, as well as Channel Mode Modify, would be to rather re-use the old lchan and implement FSM states to re-route the audio. This is currently not implemented (properly) nor tested. To really get call-during-call working, osmo-msc also needs a fix, see the change-id in 'Related' below. Related: OS#3735, osmo-msc I0ba216b737909e92080a722db26e3577726c63cb Change-Id: I0c00ec2c120e5008281755adcd4944a3ce4d8355
1 files changed, 30 insertions, 0 deletions
diff --git a/src/osmo-bsc/assignment_fsm.c b/src/osmo-bsc/assignment_fsm.c
index e7dc945..ded8f0f 100644
@@ -369,6 +369,34 @@ static int check_for_existing_lchan(struct gsm_subscriber_connection *conn)
struct assignment_request *req = &conn->assignment.req;
+ /* CHANNEL RE-USE CURRENTLY DISABLED.
+ * This code path would re-use an existing lchan if it already satisfies the mode and rate requested by
+ * the MSC.
+ * Practical situations where this might arise:
+ * (a) We were out of SDCCH channels and assigned a TCH channel for signalling, and now that TCH should
+ * take on the voice stream.
+ * (b) A call is coming in while another call is ongoing. Then, the user may choose to hang up the
+ * current call, and continue on the new call instead. In that scenario, the MSC will send us
+ * another Assignment Command with a different remote RTP address to route RTP to.
+ * In both cases, an existing lchan FSM already in the ACTIVE state needs to set up a voice stream after
+ * the fact. This is actually not implemented. Hence both scenarios above will end in a voice stream
+ * failure, aborting the call.
+ * By not re-using the current lchan, we set up a new lchan the same way we always do, and (a) enabling
+ * voice and (b) switching over to the new caller works.
+ * Hence, disable this lchan re-use until we can re-use an lchan properly.
+ * Test scenario for (b):
+ * - from A, call B.
+ * - from C, call B; B rings during ongoing call.
+ * - in B, pick up the call, choose to drop the old call.
+ return 0;
@@ -493,6 +521,8 @@ void assignment_fsm_start(struct gsm_subscriber_connection *conn, struct gsm_bts
/* There may be an already existing lchan, if yes, try to work with
* the existing lchan */
+ /* FIXME: discard the assignment.fi allocated above, and hence properly dispatch the
+ * GSCON_EV_ASSIGNMENT_END event */
/* Try to allocate a new lchan with the preferred codec/rate choice */