aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNeels Hofmeyr <neels@hofmeyr.de>2018-12-19 13:43:28 +0100
committerNeels Hofmeyr <neels@hofmeyr.de>2018-12-21 01:29:43 +0100
commitea6008e4cdca649ca224d4c57f77ac21da42642e (patch)
tree819bdfdaffb416cbbab919d2bbb3ea416495c730
parent43c403af566b0f5d91bd375245fc7349252b37e8 (diff)
fix call-during-call: switch off re-using lchan during assignment
Disable lchan re-use on repeated Assignment Requests from the MSC, in order to enable switching over to a new call that is coming in during an ongoing call. This disables a rare and untested scenario for the benefit of a very common one: call during call. It adds a feature by disabling code :) The long-term 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. But that is a task for another day. A more detailed explanation is given in the '#if 0' section added by this patch. 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
-rw-r--r--src/osmo-bsc/assignment_fsm.c37
1 files changed, 37 insertions, 0 deletions
diff --git a/src/osmo-bsc/assignment_fsm.c b/src/osmo-bsc/assignment_fsm.c
index 93362f85b..8f236d10c 100644
--- a/src/osmo-bsc/assignment_fsm.c
+++ b/src/osmo-bsc/assignment_fsm.c
@@ -251,6 +251,9 @@ static void assignment_fsm_update_id(struct gsm_subscriber_connection *conn)
new_lchan->nr);
}
+#if 0
+Code using this is currently disabled, search for lchan_type_compat_with_mode below.
+
static bool lchan_type_compat_with_mode(enum gsm_chan_t type,
enum gsm48_chan_mode chan_mode, int full_rate)
{
@@ -290,6 +293,7 @@ static bool lchan_type_compat_with_mode(enum gsm_chan_t type,
return false;
}
}
+#endif
void assignment_fsm_init()
{
@@ -337,6 +341,38 @@ void assignment_fsm_start(struct gsm_subscriber_connection *conn, struct gsm_bts
return;
}
+#if 0
+ -------
+ This bit of code would re-use an existing lchan if it already satisfies the
+ mode and rate requested by the MSC.
+
+ That is a nice idea per se, but the only practical benefit is when we were out
+ of SDCCH channels and assigned a TCH channel for signalling, and now that TCH
+ should take on the voice stream. This scenario has not been tested.
+
+ A much more common scenario, though, is that 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.
+ The proper way now would be to bump the lchan_fsm so that it re-uses everything
+ that is in place, only MDCXes the result to a different remote RTP port. This
+ is currently not implemented and would require more states in the FSM. With
+ this code enabled, we try to re-use the existing lchan but do not re-route the
+ RTP: the old call is hung up and the new call gets no audio.
+
+ However, if we simply drop the old lchan and create a new one, we can trivially
+ set up a new lchan the same way we always do, and switching over to the new
+ caller works, without a single line of code added here.
+
+ Hence, disable this lchan re-use until we can re-use an lchan properly.
+
+ Test scenario:
+
+ - 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.
+ -------
+
if (conn->lchan
&& lchan_type_compat_with_mode(conn->lchan->type, req->chan_mode, req->full_rate)) {
@@ -359,6 +395,7 @@ void assignment_fsm_start(struct gsm_subscriber_connection *conn, struct gsm_bts
"NOT IMPLEMENTED:"
" Current lchan would be compatible, we should send Channel Mode Modify\n");
}
+#endif
conn->assignment.new_lchan = lchan_select_by_chan_mode(bts, req->chan_mode, req->full_rate);