Attention is currently required from: dexter.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/pysim/+/33347 )
Change subject: Add support for encoding/decoding SMS in TPDU and SMPP format
......................................................................
Patch Set 3: Code-Review+2
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/33347
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I0d95e62c1e7183a7851d1fe38df0f5133830cb1f
Gerrit-Change-Number: 33347
Gerrit-PatchSet: 3
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Sun, 25 Jun 2023 06:23:38 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: laforge.
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/pysim/+/33420
to look at the new patch set (#2).
Change subject: Fix run-editor bug with cmd2 >= 2.0.0 compatibility
......................................................................
Fix run-editor bug with cmd2 >= 2.0.0 compatibility
In cmd2, the upstream authors decided to rename a method in 2.0.0
without providing a backwards compatibility wrapper. Let's add that
locally.
Change-Id: Iaa17b93db13ba330551799cce5f0388c78217224
Closes: OS#6071
---
M pySim-shell.py
M pySim/filesystem.py
2 files changed, 29 insertions(+), 4 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/pysim refs/changes/20/33420/2
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/33420
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: Iaa17b93db13ba330551799cce5f0388c78217224
Gerrit-Change-Number: 33420
Gerrit-PatchSet: 2
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: newpatchset
laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/pysim/+/33420 )
Change subject: Fix run-editor bug with cmd2 >= 2.0.0 compatibility
......................................................................
Fix run-editor bug with cmd2 >= 2.0.0 compatibility
In cmd2, the upstream authors decided to rename a method in 2.0.0
without providing a backwards compatibility wrapper. Let's add that
locally.
Change-Id: Iaa17b93db13ba330551799cce5f0388c78217224
Closes: OS#6071
---
M pySim-shell.py
M pySim/filesystem.py
2 files changed, 27 insertions(+), 4 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/pysim refs/changes/20/33420/1
diff --git a/pySim-shell.py b/pySim-shell.py
index f6cd75d..b018102 100755
--- a/pySim-shell.py
+++ b/pySim-shell.py
@@ -17,7 +17,7 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-from typing import List
+from typing import List, Optional
import json
import traceback
@@ -144,7 +144,16 @@
return rs, card
-class PysimApp(cmd2.Cmd):
+class Cmd2Compat(cmd2.Cmd):
+ """Backwards-compatibility wrapper around cmd2.Cmd to support older and newer
+ releases. See https://github.com/python-cmd2/cmd2/blob/master/CHANGELOG.md"""
+ def run_editor(self, file_path: Optional[str] = None) -> None:
+ if version.parse(cmd2.__version__) < version.parse("2.0.0"):
+ return self._run_editor(file_path)
+ else:
+ return super().run_editor(file_path)
+
+class PysimApp(Cmd2Compat):
CUSTOM_CATEGORY = 'pySim Commands'
def __init__(self, card, rs, sl, ch, script=None):
diff --git a/pySim/filesystem.py b/pySim/filesystem.py
index b5d0ccd..04e849b 100644
--- a/pySim/filesystem.py
+++ b/pySim/filesystem.py
@@ -649,7 +649,7 @@
with open(filename, 'w') as text_file:
json.dump(orig_json, text_file, indent=4)
# run a text editor
- self._cmd._run_editor(filename)
+ self._cmd.run_editor(filename)
with open(filename, 'r') as text_file:
edited_json = json.load(text_file)
if edited_json == orig_json:
@@ -917,7 +917,7 @@
with open(filename, 'w') as text_file:
json.dump(orig_json, text_file, indent=4)
# run a text editor
- self._cmd._run_editor(filename)
+ self._cmd.run_editor(filename)
with open(filename, 'r') as text_file:
edited_json = json.load(text_file)
if edited_json == orig_json:
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/33420
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: Iaa17b93db13ba330551799cce5f0388c78217224
Gerrit-Change-Number: 33420
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: newchange
falconia has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmocore/+/33419 )
Change subject: ecu: add is_dtx_pause() method
......................................................................
ecu: add is_dtx_pause() method
The ECU API of libosmocodec is unfortunately a peculiar non-3GPP
entity: an ECU by itself, severed from Rx DTX handler functions,
which is a logical/conceptual function with no place in the standard
3GPP architecture. The closest thing that exists in the standard
architecture is the TFO spec (TS 28.062 section C.3.2.1.1) calling
for an ECU application, but not comfort noise generation, in the case
of destination leg doing DTXd - but even then it is not a totally
"pure" ECU like libosmocodec API, it is an ECU plus a SID preener,
and the SID preening transform is not possible within the constraints
of existing libosmocodec ECU API. Hence truly correct handling of
corner cases, particularly invalid SID, is sadly impossible in the
current libosmocodec ECU framework.
The only current user of this API is the UL path in osmo-bts-trx;
however, as described in OS#6040, we would like to move that ECU call
from osmo-bts-trx model-specific code to the common layer of osmo-bts.
The current osmo-bts-trx incarnation avoids the SID handling problem
by suppressing the call to ECU frame_out() after any SID (valid or
invalid) was received on the air, thus pausing the RTP stream instead
of emitting ECU output during DTXu pauses. We would like to retain
the same behavior when we move this ECU call to the common layer,
into its proper place _after_ the link quality check in l1sap - but
the current method of flagging post-SID state in osmo-bts-trx will
no longer work on the other side of that link quality check.
As a workaround, have the ECU remember via a separate Boolean flag
whether it is in post-SID state or not (was the most recent frame_in()
any kind of SID or not), and provide is_dtx_pause() method to
retrieve this flag - the relocated ECU call in osmo-bts UL path
will use this new is_dtx_pause() method call to decide if it should
call frame_out() or switch to pausing RTP output.
Related: OS#6040
Change-Id: I3857be84bba12aaca0c2cca91458b7e13c5a642a
---
M include/osmocom/codec/ecu.h
M src/codec/ecu.c
M src/codec/ecu_fr.c
3 files changed, 72 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/19/33419/1
diff --git a/include/osmocom/codec/ecu.h b/include/osmocom/codec/ecu.h
index 9307ea1..6492860 100644
--- a/include/osmocom/codec/ecu.h
+++ b/include/osmocom/codec/ecu.h
@@ -62,12 +62,16 @@
/* generate output data for a substitute/erroneous frame */
int osmo_ecu_frame_out(struct osmo_ecu_state *st, uint8_t *frame_out);
+/* is the stream handled by this ECU currently in a DTX pause? */
+bool osmo_ecu_is_dtx_pause(struct osmo_ecu_state *st);
+
struct osmo_ecu_ops {
struct osmo_ecu_state * (*init)(void *ctx, enum osmo_ecu_codec codec);
void (*destroy)(struct osmo_ecu_state *);
int (*frame_in)(struct osmo_ecu_state *st, bool bfi,
const uint8_t *frame, unsigned int frame_bytes);
int (*frame_out)(struct osmo_ecu_state *st, uint8_t *frame_out);
+ bool (*is_dtx_pause)(struct osmo_ecu_state *st);
};
int osmo_ecu_register(const struct osmo_ecu_ops *ops, enum osmo_ecu_codec codec);
diff --git a/src/codec/ecu.c b/src/codec/ecu.c
index def72e6..cdb3e62 100644
--- a/src/codec/ecu.c
+++ b/src/codec/ecu.c
@@ -96,6 +96,20 @@
return g_ecu_ops[st->codec]->frame_out(st, frame_out);
}
+/*! check if the current state of this ECU is a DTX pause.
+ * \param[in] st ECU state/instance on which to operate
+ * \return true if DTX pause, false otherwise */
+bool osmo_ecu_is_dtx_pause(struct osmo_ecu_state *st)
+{
+ if (st->codec >= ARRAY_SIZE(g_ecu_ops))
+ return false;
+ if (!g_ecu_ops[st->codec])
+ return false;
+ if (!g_ecu_ops[st->codec]->is_dtx_pause)
+ return false;
+ return g_ecu_ops[st->codec]->is_dtx_pause(st);
+}
+
/***********************************************************************
* low-level API for ECU implementations
***********************************************************************/
diff --git a/src/codec/ecu_fr.c b/src/codec/ecu_fr.c
index 561ad60..adde03e 100644
--- a/src/codec/ecu_fr.c
+++ b/src/codec/ecu_fr.c
@@ -95,6 +95,7 @@
uint8_t sid_xmaxc;
uint8_t sid_reemit_count;
struct osmo_prbs_state prng;
+ bool last_input_was_sid;
};
/* This function is the frame input to the ECU - all inputs to this
@@ -110,6 +111,7 @@
case OSMO_GSM631_SID_CLASS_SPEECH:
memcpy(fr->speech_frame, frame, GSM_FR_BYTES);
fr->pr_state = STATE_SPEECH;
+ fr->last_input_was_sid = false;
return;
case OSMO_GSM631_SID_CLASS_INVALID:
/* GSM 06.31 section 6.1.2 says: "an invalid SID frame
@@ -136,6 +138,7 @@
* GSM 06.31 an invalid SID is still an accepted SID frame
* for the purpose of "lost SID" logic. */
fr->sid_reemit_count = 0;
+ fr->last_input_was_sid = true;
return;
case OSMO_GSM631_SID_CLASS_VALID:
/* save LARc part */
@@ -144,6 +147,7 @@
fr->sid_xmaxc = ((frame[27] & 0x1F) << 1) | (frame[28] >> 7);
fr->pr_state = STATE_SID;
fr->sid_reemit_count = 0;
+ fr->last_input_was_sid = true;
return;
default:
/* There are only 3 possible SID classifications per GSM 06.31
@@ -320,10 +324,18 @@
return GSM_FR_BYTES;
}
+static bool ecu_fr_is_dtx_pause(struct osmo_ecu_state *st)
+{
+ struct fr_ecu_state *fr = (struct fr_ecu_state *) &st->data;
+
+ return fr->last_input_was_sid;
+}
+
static const struct osmo_ecu_ops osmo_ecu_ops_fr = {
.init = ecu_fr_init,
.frame_in = ecu_fr_frame_in,
.frame_out = ecu_fr_frame_out,
+ .is_dtx_pause = ecu_fr_is_dtx_pause,
};
static __attribute__((constructor)) void on_dso_load_ecu_fr(void)
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/33419
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I3857be84bba12aaca0c2cca91458b7e13c5a642a
Gerrit-Change-Number: 33419
Gerrit-PatchSet: 1
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-MessageType: newchange
Attention is currently required from: fixeria, pespin.
arehbein has posted comments on this change. ( https://gerrit.osmocom.org/c/python/osmo-python-tests/+/30980 )
Change subject: scripts/osmotestconfig.py: Fix tests failing due to attempted copy on socket files
......................................................................
Patch Set 5:
(1 comment)
File scripts/osmotestconfig.py:
https://gerrit.osmocom.org/c/python/osmo-python-tests/+/30980/comment/77e51…
PS5, Line 80: ign = shutil.ignore_patterns('*.cfg', '*tmp_dummy_sock')
> I also don't like the proposed approach, agreeing with @pespin that putting project specific filenam […]
`shutil` (see [here](https://docs.python.org/3/library/shutil.html) for documentation) itself includes filename-pattern exclusion only it seems. I've just taken a look at the documentation and found this:
```
Changed in version 3.2: Added the copy_function argument to be able to provide a custom copy function. Added the ignore_dangling_symlinks argument to silence dangling symlinks errors when symlinks is false.
```
which I suppose would via (some library of) Python3 enable us to pass something like (pseudo-code...)
```
if src_file is a special file
return
else
copy src_file to destination
```
as a custom copy function.
Did a short online research and it appears that Python3 does not provide file type detection (feel free to correct me if I'm wrong), so a system call to System V `file` command could be used.
Iirc the exception thrown from `shutil.copytree()` was all but specific about what was going on. Maybe some enhanced exception handling using the auditing event triggered would also do the trick, I don't know enough about this though.
I still feel like the current change is a simple fix for now that won't break anything and can still be followed up upon easily with some more sophisticated solution if need be.
--
To view, visit https://gerrit.osmocom.org/c/python/osmo-python-tests/+/30980
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: python/osmo-python-tests
Gerrit-Branch: master
Gerrit-Change-Id: I3a3cc7ed135b60b97eb901cfc20fdcb924e4f664
Gerrit-Change-Number: 30980
Gerrit-PatchSet: 5
Gerrit-Owner: arehbein <arehbein(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 23 Jun 2023 18:05:17 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: arehbein <arehbein(a)sysmocom.de>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: neels.
falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/29973 )
Change subject: msc_a: send MNCC_RTP_CONNECT in call waiting scenarios
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
> i mean "a call waiting scenario" seems to say it all, but when i think about it i'm not so sure afte […]
Alice and Bob are in a call, and then Charlie dials Alice's number. The network delivers a new MT call SETUP message for call 2 to Alice's MS, and her phone does what all standard phones do: it starts playing an in-band call waiting tone (GSM 02.40 Table 1 Tone 7) into her ear, and shows Charlie's calling number (from the new SETUP message) on the display. But while this call 2 is pending and the CW tone is playing, the call between Alice and Bob is still active, and they can keep talking! While this CW in-band audio notification is ongoing, to the network it's the same as if Call 2 was ringing normally, and the MS replies with ALERTING CC message on this call 2.
If Alice presses the "Accept" button in her phone's call waiting UI (meaning "accept new call"), her MS implementation will execute a Hold operation on call 1 - Bob will NOT be disconnected, but the call will go silent for him as the voice traffic from Alice cuts off. Then Alice's MS replies to the network with a CONNECT on call 2, and expects the network to switch call 2 audio to the existing voice TCH.
For as long as Bob stays on his phone, patiently waiting for Alice to come back, she can press a "switch calls" button in her phone UI - and every time she does so, the mobile-side protocol stack in her MS will execute a Hold operation on the currently active call, and then a Retrieve operation on the previously held one.
Now enter Osmocom. For a self-contained Osmocom network with internal MNCC, my little patch does not help: with or without this patch, call waiting has no chance of working as there is no support for more basic call hold and retrieve operations. But enter external MNCC, either themwi-system-sw (what I actually run) or osmo-sip-connector (should work the same in this regard, but untested) - that's when my patch makes CW work at least in basic testing, without considering any corner cases.
For the purpose of analyzing CW with external MNCC and my patch, assume that Alice is a local GSM user, while Bob and Charlie are parties in the outside world. When Alice and Bob establish their initial call, in either MO (Alice calls Bob) or MT (Bob calls Alice) direction, the external MNCC software will handle that call under a certain callref on the MNCC socket. The audio connection is established by OsmoMSC giving its RTP info to the external MNCC via MNCC_RTP_CREATE and the external MNCC giving its RTP info to OsmoMSC via MNCC_RTP_CONNECT.
When Charlie dials Alice's number from the outside world, the PSTN-to-Osmocom gateway will handle this MT call as a separate logical entity having no relation to call 1: it will assign a new MT callref for call 2 and send MNCC_SETUP_REQ to OsmoMSC. From that point onward, everything works correctly except one detail: in the new MNCC message exchange for callref 2, no MNCC_RTP_CREATE is ever sent from OsmoMSC to the external MNCC. And with RTP info missing, call 2 audio can never be connected. My patch is a band-aid that makes this flow work successfully in the simplest scenario, ignoring all sorts of corner cases such as what happens if call 2 comes in while TCH assignment for call 1 hasn't been completed yet, Bearer cap and codec issues and probably myriad others.
My next OsmoDevCall presentation (tentatively scheduled for August, though I won't mind waiting till September if someone else wishes to present in Aug) will be on the subject of external MNCC and Osmocom to PSTN interfacing, and I will be discussing the present issue then.
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/29973
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Ibb62cb3c154b99769b2dfe708f73c20e8b632f5d
Gerrit-Change-Number: 29973
Gerrit-PatchSet: 1
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 23 Jun 2023 17:21:08 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: comment