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/osmocom-commitlog@lists.osmocom.org/.
gitosis at osmocom.org gitosis at osmocom.orgThis is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)". The branch, sysmocom/iu has been updated discards 20e97facea65eb9b25662a1f43de256940176134 (commit) via 4f9989048a5763ddb736730db9b4b3e3ddd4ffb9 (commit) via 293ca96757daa25be078af013cae4a37734a8bc5 (commit) This update added new revisions after undoing existing revisions. That is to say, the old revision is not a strict subset of the new revision. This situation occurs when you --force push a change and generate a repository containing something like this: * -- * -- B -- O -- O -- O (20e97facea65eb9b25662a1f43de256940176134) \ N -- N -- N (4f9989048a5763ddb736730db9b4b3e3ddd4ffb9) When this happens we assume that you've already had alert emails for all of the O revisions, and so we here report only the revisions in the N branch from the common base, B. Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://cgit.osmocom.org/openbsc/commit/?id=4f9989048a5763ddb736730db9b4b3e3ddd4ffb9 commit 4f9989048a5763ddb736730db9b4b3e3ddd4ffb9 Author: Neels Hofmeyr <nhofmeyr at sysmocom.de> Date: Tue Oct 11 02:24:53 2016 +0200 IuCS: rapidly release connections Do the same as we do in 2G: release the connection as soon as nothing else is pending for a given subscriber. Before, osmo-cscn would wait for the UE "to get bored" and send an Iu release. But the CN should stay lean on connections. Also, 25.413[1] in section 7, 6th point states: "While the Iu release is managed from the CN, the RNC has the capability to request the release of all Iu connection resources from the corresponding Iu connection." So far we did not manage Iu release from osmo-cscn at all. Use the same mechanism we use in 2G: from msc_release_connection(), just before freeing the gsm_subscriber_conn, invoke a CN initiated Iu Release command to the UE. This works around OS#1816 ("USSD only works when IuCS is released", on nano3G), because the Iu conn is now released right after every signalling, so that typically no two requests will use the same conn. In iu.h/iu.c, add iu_tx_release(), absorbing almost all of the code from ranap_handle_co_iu_rel_req(). Add stub to db_test.c, necessary to build it without linking libiu. [1] 3GPP TS 25.413 v12.4.0 Release 12 / ETSI TS 125 413 V12.4.0 (2015-04) Related: OS#1816 Change-Id: Ic12bd6f3666f6fd42bd6d9fdae1c93abee3b6786 http://cgit.osmocom.org/openbsc/commit/?id=293ca96757daa25be078af013cae4a37734a8bc5 commit 293ca96757daa25be078af013cae4a37734a8bc5 Author: Neels Hofmeyr <nhofmeyr at sysmocom.de> Date: Tue Oct 11 00:50:05 2016 +0200 IuCS: don't remove Iu conn until release Don't remove the gsm_subscriber_connection without an Iu Release. From the 2G paradigm to close a subscriber connection as soon as nothing else is pending, osmo-cscn frequently calls msc_release_connection() to see whether a conn has anything pending, or discards it. In 3G however, we so far don't actively release IuCS connections from the MSC side, but wait until the IuCS is released from the UE side. So the conn is often discarded even though the IuCS stays open and valid, which confuses the situation: before the UE releases a bit later, we would try to page the subscriber unsuccessfully, because the UE expects to already be connected. To first fix the discrepancy of Iu vs. subscr release, never discard gsm_subscriber_connections when msc_release_connection() is called. This creates a "lazy" CN that keeps connections open as long as the UE will tolerate. It is really fast in sending many SMS in close succession, but is certainly a bad CN design choice: we should rather stay lean on connections. A subsequent commit will change this, but I decided to keep this commit as a reference, for when we'd like to test situations that should re-use an established connection. Change-Id: I012378cfa432d791146db387554ec1909de05297 ----------------------------------------------------------------------- Summary of changes: openbsc/include/openbsc/iu.h | 2 ++ openbsc/src/libiu/iu.c | 23 +++++++++++++++++++---- openbsc/src/libmsc/osmo_msc.c | 12 ++++++++---- openbsc/tests/db/db_test.c | 3 +++ 4 files changed, 32 insertions(+), 8 deletions(-) hooks/post-receive -- The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)