Change in osmo-bsc[master]: fix call-during-call: switch off re-using lchan during assignment

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

Neels Hofmeyr gerrit-no-reply at lists.osmocom.org
Fri Dec 21 00:51:48 UTC 2018


Neels Hofmeyr has uploaded this change for review. ( https://gerrit.osmocom.org/12401


Change subject: fix call-during-call: switch off re-using lchan during assignment
......................................................................

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
---
M src/osmo-bsc/assignment_fsm.c
1 file changed, 37 insertions(+), 0 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/01/12401/1

diff --git a/src/osmo-bsc/assignment_fsm.c b/src/osmo-bsc/assignment_fsm.c
index 93362f8..8f236d1 100644
--- a/src/osmo-bsc/assignment_fsm.c
+++ b/src/osmo-bsc/assignment_fsm.c
@@ -251,6 +251,9 @@
 				  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 @@
 		return false;
 	}
 }
+#endif
 
 void assignment_fsm_init()
 {
@@ -337,6 +341,38 @@
 		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 @@
 			       "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);
 

-- 
To view, visit https://gerrit.osmocom.org/12401
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I0c00ec2c120e5008281755adcd4944a3ce4d8355
Gerrit-Change-Number: 12401
Gerrit-PatchSet: 1
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20181221/a2688129/attachment.htm>


More information about the gerrit-log mailing list