diff options
authorNeels Hofmeyr <neels@hofmeyr.de>2018-12-19 13:43:28 +0100
committerNeels Hofmeyr <neels@hofmeyr.de>2019-01-24 17:48:52 +0100
commit376c90184890ee3e257fbcda372654764b854e5f (patch)
parent49428b2f3d888751a6288b49fb8d084f18212b36 (diff)
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 e7dc945af..ded8f0fc3 100644
--- a/src/osmo-bsc/assignment_fsm.c
+++ b/src/osmo-bsc/assignment_fsm.c
@@ -369,6 +369,34 @@ static int check_for_existing_lchan(struct gsm_subscriber_connection *conn)
struct assignment_request *req = &conn->assignment.req;
+ *
+ * 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;
if (!conn->lchan)
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 */
if (check_for_existing_lchan(conn))
+ /* FIXME: discard the assignment.fi allocated above, and hence properly dispatch the
/* Try to allocate a new lchan with the preferred codec/rate choice */