[PATCH] openbsc[master]: dyn TS: OS#1778 workaround: disable TCH/F on dyn TS for nitb

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
Thu Jul 28 15:53:11 UTC 2016


Hello Harald Welte, Jenkins Builder,

I'd like you to reexamine a change.  Please visit

    https://gerrit.osmocom.org/603

to look at the new patch set (#4).

dyn TS: OS#1778 workaround: disable TCH/F on dyn TS for nitb

To avoid two phones picking mismatching TCH pchans, never pick TCH/F on dynamic
TS in osmo-nitb.

Add gsm_network flag dyn_ts_allow_tch_f, set to true by default in
gsm_network_init().

Set this flag to false in osmo-nitb's main().

See http://osmocom.org/issues/1778

Reasoning about ways to solve this:

* a compile time switch doesn't work because libbsc is first compiled and then
  linked to both osmo-nitb and osmo-bsc.

* we could test net->bsc_api == msc_bsc_api(), but I have the so-called MSC
  split waiting on branch sysmocom/cscn, which will result in msc_bsc_api() not
  being linked in the osmo-bsc binary.

* have a function am_i_nitb() with different implementations in osmo-nitb and
  osmo-bsc, but then we'd need to add implementations to all tests and other
  binaries linking lchan_alloc().

* have a flag in struct bsc_api, but so far there are only function pointers
  there.

Having a "global" flag in gsm_network allows to add a VTY command in case we
decide to keep this feature (#1781), has no linking implications and is nicely
explicit.

Tested that osmo-bsc still picks TCH/F on dyn TS indirectly, since I have no
standalone MSC available: when compiling osmo-nitb with the line that sets
dyn_ts_allow_tch_f = false commented out, TCH/F is picked as described in
OS#1778; and by printf-verifying that dyn_ts_allow_tch_f == true in osmo-bsc
main(), only osmo-nitb should have TCH/F disabled.

Related: OS#1778, OS#1781
Change-Id: If7e4797a72815fc6e2bbef27756ea5df69f4bde7
---
M openbsc/include/openbsc/gsm_data.h
M openbsc/src/libbsc/chan_alloc.c
M openbsc/src/libbsc/net_init.c
M openbsc/src/osmo-nitb/bsc_hack.c
4 files changed, 21 insertions(+), 1 deletion(-)


  git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/03/603/4

diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h
index bdcd0e0..b9cb48d 100644
--- a/openbsc/include/openbsc/gsm_data.h
+++ b/openbsc/include/openbsc/gsm_data.h
@@ -296,6 +296,10 @@
 
 	/* control interface */
 	struct ctrl_handle *ctrl;
+
+	/* Allow or disallow TCH/F on dynamic TCH/F_TCH/H_PDCH; OS#1778 */
+	bool dyn_ts_allow_tch_f;
+	/* TODO: vty for this; related: OS#1781 */
 };
 
 struct osmo_esme;
diff --git a/openbsc/src/libbsc/chan_alloc.c b/openbsc/src/libbsc/chan_alloc.c
index 1e5dd74..c3a7e0f 100644
--- a/openbsc/src/libbsc/chan_alloc.c
+++ b/openbsc/src/libbsc/chan_alloc.c
@@ -309,8 +309,9 @@
 			if (lchan)
 				type = GSM_LCHAN_TCH_F;
 		}
+
 		/* Try fully dynamic TCH/F_TCH/H_PDCH as TCH/F... */
-		if (!lchan) {
+		if (!lchan && bts->network->dyn_ts_allow_tch_f) {
 			lchan = _lc_dyn_find_bts(bts,
 						 GSM_PCHAN_TCH_F_TCH_H_PDCH,
 						 GSM_PCHAN_TCH_F);
diff --git a/openbsc/src/libbsc/net_init.c b/openbsc/src/libbsc/net_init.c
index ee0d445..6d03ee4 100644
--- a/openbsc/src/libbsc/net_init.c
+++ b/openbsc/src/libbsc/net_init.c
@@ -116,6 +116,8 @@
 	net->ext_max = GSM_MAX_EXTEN;
 	gsm_net_update_ctype(net);
 
+	net->dyn_ts_allow_tch_f = true;
+
 	return net;
 }
 
diff --git a/openbsc/src/osmo-nitb/bsc_hack.c b/openbsc/src/osmo-nitb/bsc_hack.c
index 0b360dc..e3e8927 100644
--- a/openbsc/src/osmo-nitb/bsc_hack.c
+++ b/openbsc/src/osmo-nitb/bsc_hack.c
@@ -299,6 +299,19 @@
 #endif
 	bsc_api_init(bsc_gsmnet, msc_bsc_api());
 
+	/*
+	 * For osmo-nitb, skip TCH/F for now, because otherwise dyn TS
+	 * always imply the possibility to have a mix of TCH/F and
+	 * TCH/H channels; if two phones request a TCH/F and a TCH/H,
+	 * respectively, they cannot call each other. If we deny TCH/F,
+	 * they will both fall back to TCH/H, and dynamic channels are
+	 * usable. See http://osmocom.org/issues/1778.
+	 *
+	 * A third-party MSC may well be able to handle a TCH/H TCH/F
+	 * mismatch.
+	 */
+	bsc_gsmnet->dyn_ts_allow_tch_f = false;
+
 	/* start control interface after reading config for
 	 * ctrl_vty_get_bind_addr() */
 	LOGP(DNM, LOGL_NOTICE, "CTRL at %s %d\n",

-- 
To view, visit https://gerrit.osmocom.org/603
To unsubscribe, visit https://gerrit.osmocom.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If7e4797a72815fc6e2bbef27756ea5df69f4bde7
Gerrit-PatchSet: 4
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: neels_test_account <neels at hofmeyr.de>



More information about the gerrit-log mailing list