November 2025 - gerrit-log - lists.osmocom.org

[XS] Change in ...osmo-s1gw[master]: [REST] OpenAPI: fix regexp to permit IPv6 addr in EnbId
by pespin 05 Nov '25

05 Nov '25

Attention is currently required from: fixeria. pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/41298?usp=email ) Change subject: [REST] OpenAPI: fix regexp to permit IPv6 addr in EnbId ...................................................................... Patch Set 1: Code-Review+1 (1 comment) File contrib/openapi.yaml: https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/41298/comment/ba6903cf_b028… : PS1, Line 195: pattern: '^enb-conn:[0-9a-f:.]+-[0-9]+$' I'm not a regexp by any means, but apparently matching a n IP address is a bit more complex? https://www.ditig.com/validating-ipv4-and-ipv6-addresses-with-regexp#combin… https://regex101.com/r/tF7zQ1/1 -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/41298?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: erlang/osmo-s1gw Gerrit-Branch: master Gerrit-Change-Id: I112283b140a070924d59935a3bdd6fd63fc8c7ea Gerrit-Change-Number: 41298 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Wed, 05 Nov 2025 09:17:33 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes

1 0

[XS] Change in libosmocore[master]: osmo-release: debian_patch_apply: handle empty dir
by osmith 05 Nov '25

05 Nov '25

osmith has submitted this change. ( https://gerrit.osmocom.org/c/libosmocore/+/41296?usp=email ) Change subject: osmo-release: debian_patch_apply: handle empty dir ...................................................................... osmo-release: debian_patch_apply: handle empty dir Don't fail with the following bogus error message if the debian/patches directory exists but is empty: error: can't open patch '…/git/libosmocore/debian/patches/*.patch': No such file or directory Fixes: OS#6873 Change-Id: I6656602c58fd221c8bb933890712d1392a1dfdab --- M osmo-release.sh 1 file changed, 3 insertions(+), 3 deletions(-) Approvals: pespin: Looks good to me, approved Jenkins Builder: Verified fixeria: Looks good to me, but someone else must approve diff --git a/osmo-release.sh b/osmo-release.sh index 14790da..5a9584c 100755 --- a/osmo-release.sh +++ b/osmo-release.sh @@ -151,10 +151,10 @@ # Make sure that patches under debian/patches/ apply: check_debian_patch_apply() { - if [ ! -d "${GIT_TOPDIR}/debian/patches" ]; then - return - fi for patch in ${GIT_TOPDIR}/debian/patches/*.patch; do + if ! [ -e "$patch" ]; then + continue + fi git apply --check $patch if [ $? -ne 0 ]; then error "patch no longer applies! $patch" -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41296?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I6656602c58fd221c8bb933890712d1392a1dfdab Gerrit-Change-Number: 41296 Gerrit-PatchSet: 3 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[XS] Change in libosmocore[master]: osmo-release: debian_patch_apply: handle empty dir
by pespin 05 Nov '25

05 Nov '25

Attention is currently required from: osmith. pespin has posted comments on this change by osmith. ( https://gerrit.osmocom.org/c/libosmocore/+/41296?usp=email ) Change subject: osmo-release: debian_patch_apply: handle empty dir ...................................................................... Patch Set 2: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41296?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I6656602c58fd221c8bb933890712d1392a1dfdab Gerrit-Change-Number: 41296 Gerrit-PatchSet: 2 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Comment-Date: Wed, 05 Nov 2025 09:12:19 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[M] Change in osmo-msc[master]: SMS UX optimisation: Deliver rx'd SMS right away
by keith 04 Nov '25

04 Nov '25

Attention is currently required from: pespin. keith has posted comments on this change by keith. ( https://gerrit.osmocom.org/c/osmo-msc/+/28342?usp=email ) Change subject: SMS UX optimisation: Deliver rx'd SMS right away ...................................................................... Patch Set 4: (1 comment) Patchset: PS4: > I'm not sure I'm fully following you tbh, because from your previous (full) comment afaict you seem […] My dear Pau, The comparison with UDP ordering is somewhat absurd. 😊 About the ordering/disordering.. have you ever really, actually, you know, as a human being, noticed that one SMS arrived (what are we talking here.. max 1 second, 2?) before another? I would imagine more likely you got some notification of SMS and by the time you looked at the SMS, you see them in order of timestamp. I'm looking at this from a humanitarian, and you're looking at it from a somewhat staunch technical POV. In the real world, one might expect that a message I just sent is more relevant than the one I sent two weeks (or months) ago. But look - I don't CARE! We can do what you suggest, for sure. The chances of running into the situation where a just sent SMS provokes the sending of an older, and only that older SMS is highly unlikely, well I outlined a remote possibility for it above, but whatever... It is very unlikely to negatively affect the human experience of it. Anyway, I'm expending energy here now that is limited, so I may or may not get around to doing...what I suggested above - RX of SMS triggers queue to THAT recipient, and that recipient only, in order, by date, id, whatever (actually number of failed retries, IIRC is the current criteria) In my real world experience of the real world problem of real world people who send real world SMS, your solution will also suffice, as I have not actually observed a situation where the situation you described occurred, because; with this patch in place, the first message was ALREADY DELIVERED, damn it. And if it wasn't, then this new message isn't going to be either. I've been running this patch for a long time now, and it works.. you know.. in the real world 😊 I thought it might be an idea to have it in for congress... but yeah.. limited motivation.. -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/28342?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: I9af51ef0d9c2e6c5acc5128efd6195df881b680c Gerrit-Change-Number: 28342 Gerrit-PatchSet: 4 Gerrit-Owner: keith <keith(a)rhizomatica.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: neels <nhofmeyr(a)sysmocom.de> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 04 Nov 2025 19:20:25 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: keith <keith(a)rhizomatica.org>

1 0

[XS] Change in ...osmo-s1gw[master]: [REST] OpenAPI: fix regexp to permit IPv6 addr in EnbId
by fixeria 04 Nov '25

04 Nov '25

fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/41298?usp=email ) Change subject: [REST] OpenAPI: fix regexp to permit IPv6 addr in EnbId ...................................................................... [REST] OpenAPI: fix regexp to permit IPv6 addr in EnbId Change-Id: I112283b140a070924d59935a3bdd6fd63fc8c7ea Fixes: 15067454 ("[REST] Implement EnbList and EnbInfo") --- M contrib/openapi.yaml M priv/openapi.json 2 files changed, 2 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/erlang/osmo-s1gw refs/changes/98/41298/1 diff --git a/contrib/openapi.yaml b/contrib/openapi.yaml index a56f876..307ae1c 100644 --- a/contrib/openapi.yaml +++ b/contrib/openapi.yaml @@ -192,7 +192,7 @@ description: eNB/MME SCTP association identifier example: enb-aid:42 - type: string - pattern: '^enb-conn:[0-9:.]+-[0-9]+$' + pattern: '^enb-conn:[0-9a-f:.]+-[0-9]+$' description: eNB connection address/port example: enb-conn:192.168.1.1-34650 diff --git a/priv/openapi.json b/priv/openapi.json index 5422c03..c13d20c 100644 --- a/priv/openapi.json +++ b/priv/openapi.json @@ -296,7 +296,7 @@ }, { "type": "string", - "pattern": "^enb-conn:[0-9:.]+-[0-9]+$", + "pattern": "^enb-conn:[0-9a-f:.]+-[0-9]+$", "description": "eNB connection address/port", "example": "enb-conn:192.168.1.1-34650" } -- To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/41298?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: erlang/osmo-s1gw Gerrit-Branch: master Gerrit-Change-Id: I112283b140a070924d59935a3bdd6fd63fc8c7ea Gerrit-Change-Number: 41298 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>

1 0

[XS] Change in libosmocore[master]: osmo-release: debian_patch_apply: handle empty dir
by fixeria 04 Nov '25

04 Nov '25

Attention is currently required from: osmith, pespin. fixeria has posted comments on this change by osmith. ( https://gerrit.osmocom.org/c/libosmocore/+/41296?usp=email ) Change subject: osmo-release: debian_patch_apply: handle empty dir ...................................................................... Patch Set 2: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41296?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I6656602c58fd221c8bb933890712d1392a1dfdab Gerrit-Change-Number: 41296 Gerrit-PatchSet: 2 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 04 Nov 2025 17:47:15 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[M] Change in osmo-msc[master]: SMS UX optimisation: Deliver rx'd SMS right away
by pespin 04 Nov '25

04 Nov '25

Attention is currently required from: keith. pespin has posted comments on this change by keith. ( https://gerrit.osmocom.org/c/osmo-msc/+/28342?usp=email ) Change subject: SMS UX optimisation: Deliver rx'd SMS right away ...................................................................... Patch Set 4: (1 comment) Patchset: PS4: I'm not sure I'm fully following you tbh, because from your previous (full) comment afaict you seem to state both that you are reordering and also that you are not reordering them? > I'm not "reordering" the SMS ... > WE just got an SMS for Alice. we dropped it in the database, the id is 5467, send SMS number 5467, now also look for other SMS for Alice and send them too. ^ This looks like on-purpose reordering to me (better called disordering?). Also, as mentioned I'm not currently aware of the existing codeset regarding SMS, just wanted to raise the topic, share my concern regarding possible reordering happening on purpose due to the new algorithm. > We just got an SMS for Alice, we dropped it in the database, we don't care about the id, but we will now look in the database for all SMS for Alice and send them? > Sounds like the latter will keep you more happy Yes that'd be the behavior I'd expect. I guess when select()ing SMS for Alice they'll probably come sorted by sms id since it's probably an increasing key, so we get them ordered in inserted order by free (or we could order them explicitly in the SQL query). > Is it not the MOST RECENT information that should have priority? Yes, on reflection, I think so. I disagree here. Following this approach eg. in UDP, RTP, etc. you'd end up with tons of reordered packets. The fact that reordering may happen doesn't mean we should not be trying to send stuff in order imho. > As an aside, SMS is simply NOT time sensitive. not even on commercial networks. There is ZERO guarantee of chronological delivery ACK, but as mentioned above the fact that there's no guarantee doesn't mean we should be trying our best to do so when we know how to do it. -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/28342?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: I9af51ef0d9c2e6c5acc5128efd6195df881b680c Gerrit-Change-Number: 28342 Gerrit-PatchSet: 4 Gerrit-Owner: keith <keith(a)rhizomatica.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: neels <nhofmeyr(a)sysmocom.de> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: keith <keith(a)rhizomatica.org> Gerrit-Comment-Date: Tue, 04 Nov 2025 16:41:17 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: keith <keith(a)rhizomatica.org>

1 0

[M] Change in libosmocore[master]: Revert "osmo_io: Add unit test to verify segmentation process"
by pespin 04 Nov '25

04 Nov '25

pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmocore/+/41297?usp=email ) Change subject: Revert "osmo_io: Add unit test to verify segmentation process" ...................................................................... Revert "osmo_io: Add unit test to verify segmentation process" This reverts commit 086ee51de416ae5276b4b185c055831e16c0ef85. This commit makes "LIBOSMO_IO_BACKEND=IO_URING libosmocore/tests/osmo_io/osmo_io_test" end up running in an infinite loop using 100% CPU on my system: kernel: 6.17.6-arch1-1 liburing: 2.12-1 Change-Id: I47b5fff04c601cd08ab2d46b88336247b2193808 --- M tests/osmo_io/osmo_io_test.c M tests/osmo_io/osmo_io_test.ok 2 files changed, 0 insertions(+), 126 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/97/41297/1 diff --git a/tests/osmo_io/osmo_io_test.c b/tests/osmo_io/osmo_io_test.c index d3e22aa..553368c 100644 --- a/tests/osmo_io/osmo_io_test.c +++ b/tests/osmo_io/osmo_io_test.c @@ -247,112 +247,6 @@ for (int i = 0; i < 128; i++) osmo_select_main(1); } - -int segmentation_cb(struct osmo_io_fd *iofd, struct msgb *msg) -{ - printf("%s: segmentation_cb() returning %d\n", osmo_iofd_get_name(iofd), 4); - return 4; -} - -static void segment_read_cb(struct osmo_io_fd *iofd, int rc, struct msgb *msg) -{ - static int seg_number = 0; - - printf("%s: read() msg with rc=%d\n", osmo_iofd_get_name(iofd), rc); - if (rc < 0) { - printf("%s: error: %s\n", osmo_iofd_get_name(iofd), strerror(-rc)); - OSMO_ASSERT(0); - } - OSMO_ASSERT(msg); - if (seg_number < 3) { - printf("%s\n", osmo_hexdump(msgb_data(msg), msgb_length(msg))); - printf("tailroom = %d\n", msgb_tailroom(msg)); - /* Our read buffer is 6 bytes, Our segment is 4 bytes, this results in tailroom of 2 bytes. - * When the pending 2 bytes are combined with subsequent read of 6 bytes, an extra buffer - * with 8 bytes is allocated. Our segment is 4 byte, then this results in a tailroom of 4 - * bytes. */ - if (seg_number == 1) - OSMO_ASSERT(msgb_tailroom(msg) == 4) - else - OSMO_ASSERT(msgb_tailroom(msg) == 2) - OSMO_ASSERT(msgb_length(msg) == sizeof(TESTDATA) / 4); - seg_number++; - } else { - OSMO_ASSERT(rc == 0); - file_eof_read = true; - } - talloc_free(msg); -} - -static void test_segmentation(void) -{ - struct osmo_io_fd *iofd; - struct msgb *msg; - uint8_t *buf; - int fd[2] = { 0, 0 }; - int rc; - struct osmo_io_ops ioops; - - TEST_START(); - - /* Create pipe */ - rc = pipe(fd); - OSMO_ASSERT(rc == 0); - OSMO_ASSERT(fd[0]); - OSMO_ASSERT(fd[1]); - - /* First test writing to the pipe: */ - printf("Enable write\n"); - ioops = (struct osmo_io_ops){ .write_cb = file_write_cb }; - iofd = osmo_iofd_setup(ctx, fd[1], "seg_iofd", OSMO_IO_FD_MODE_READ_WRITE, &ioops, NULL); - osmo_iofd_register(iofd, fd[1]); - - msg = msgb_alloc(12, "Test data"); - buf = msgb_put(msg, 12); - memcpy(buf, TESTDATA, 12); - osmo_iofd_write_msgb(iofd, msg); - /* Allow enough cycles to handle the messages */ - file_bytes_write_compl = 0; - for (int i = 0; i < 128; i++) { - OSMO_ASSERT(file_bytes_write_compl <= 12); - if (file_bytes_write_compl == 12) - break; - osmo_select_main(1); - usleep(100 * 1000); - } - fflush(stdout); - OSMO_ASSERT(file_bytes_write_compl == 12); - - osmo_iofd_unregister(iofd); - close(fd[1]); - - /* Now, re-configure iofd to only read from the pipe. - * Reduce the read buffer size, to verify correct segmentation operation: */ - printf("Enable read\n"); - osmo_iofd_set_alloc_info(iofd, 6, 0); - osmo_iofd_register(iofd, fd[0]); - ioops = (struct osmo_io_ops){ .read_cb = segment_read_cb, .segmentation_cb2 = segmentation_cb }; - rc = osmo_iofd_set_ioops(iofd, &ioops); - OSMO_ASSERT(rc == 0); - /* Allow enough cycles to handle the message. We expect 3 reads, 4th read will return 0. */ - file_bytes_read = 0; - file_eof_read = false; - for (int i = 0; i < 128; i++) { - if (file_eof_read) - break; - osmo_select_main(1); - usleep(100 * 1000); - } - fflush(stdout); - OSMO_ASSERT(file_eof_read); - - osmo_iofd_free(iofd); - - for (int i = 0; i < 128; i++) - osmo_select_main(1); -} - - static const struct log_info_cat default_categories[] = { }; @@ -373,7 +267,6 @@ test_file(); test_connected(); test_unconnected(); - test_segmentation(); return EXIT_SUCCESS; } diff --git a/tests/osmo_io/osmo_io_test.ok b/tests/osmo_io/osmo_io_test.ok index b24bfd2..6b9e591 100644 --- a/tests/osmo_io/osmo_io_test.ok +++ b/tests/osmo_io/osmo_io_test.ok @@ -16,22 +16,3 @@ ep1: sendto() returned rc=16 ep2: recvfrom() msg with len=16 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 -Running test_segmentation -Enable write -seg_iofd: write() returned rc=12 -01 02 03 04 05 06 07 08 09 0a 0b 0c -Enable read -seg_iofd: segmentation_cb() returning 4 -seg_iofd: read() msg with rc=6 -01 02 03 04 -tailroom = 2 -seg_iofd: segmentation_cb() returning 4 -seg_iofd: segmentation_cb() returning 4 -seg_iofd: read() msg with rc=6 -05 06 07 08 -tailroom = 4 -seg_iofd: segmentation_cb() returning 4 -seg_iofd: read() msg with rc=6 -09 0a 0b 0c -tailroom = 2 -seg_iofd: read() msg with rc=0 -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41297?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I47b5fff04c601cd08ab2d46b88336247b2193808 Gerrit-Change-Number: 41297 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de>

1 0

[M] Change in osmo-msc[master]: SMS UX optimisation: Deliver rx'd SMS right away
by keith 04 Nov '25

04 Nov '25

Attention is currently required from: pespin. keith has posted comments on this change by keith. ( https://gerrit.osmocom.org/c/osmo-msc/+/28342?usp=email ) Change subject: SMS UX optimisation: Deliver rx'd SMS right away ...................................................................... Patch Set 4: (1 comment) Patchset: PS4: > I'm not really involved into the big picture/roadmap regarding SMS, but I'd argue it makes more sens […] From my experience in production and intensive testing of the smsqueue, I never have seen the scenario you describe and I believe it is extremely unlikely. Anyway, if Bob is available when Alice sends "I'm late", but somehow or other "I'm on time" was not delivered, the latter will be queued and sent along with the former, (because the code I wrote will ensure to do that). I'm not "reordering" the SMS, I've explained at length in above comments where the delay comes from. What do you mean by "the specific subscriber"? Do you not mean precisely what I propose with this patch? Do you want me to change it from: WE just got an SMS for Alice. we dropped it in the database, the id is 5467, send SMS number 5467, now also look for other SMS for Alice and send them too. We just got an SMS for Alice, we dropped it in the database, we don't care about the id, but we will now look in the database for all SMS for Alice and send them? Sounds like the latter will keep you more happy, but it does essentially come to the same thing. OK, maybe, just maybe if Bob's SMS storage is full, but then he deletes one SMS, (and meanwhile, other relevant mechanisms fail, like notifying the network of storage availability) and then Alice sends "I'm late", then "I'm late" will be received first (and only) because Bobs SMS storage is now full again, so "I'm on time" remains queued. In your suggestion it actually works the other way round. Bob will receive "I'm on time" and never find out that Alice in late. So maybe the argument actually works the other way round. Is it not the MOST RECENT information that should have priority? Yes, on reflection, I think so. Hmm. it becomes somewhat philosophical. BTW, just to state it again, the delay problem is that Alice sends Bob "I'm late" and we drop it in the database and return to select(). we then go through this horribly complicated process of taking SMS from the database and putting them into the in-memory queue, and if there's enough SMS in there (for subs that are in the VLR) that cannot for whatever reason be delivered, then we simply WILL NOT get to Alice's message at all. And Bob get's nothing. He sits and waits at the cafe anyway, regardless of whether or not Alice is late... and well life somehow goes on and the world does not end, just like it was in 1980. As an aside, SMS is simply NOT time sensitive. not even on commercial networks. There is ZERO guarantee of chronological delivery. It is up to the receiving UE to order the display of messages based on timestamps. I often have problems with 2FA not arriving before the sender has expired it. Or yes, indeed, as you say. requesting a 2FA, and not getting it, trying again, and getting the first 2FA which is now invalid and even getting to that point of 3 strikes. It's incredibly frustrating. Anyway 2FA SMS should.. what's that hacker expression, "die in fire"? -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/28342?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: I9af51ef0d9c2e6c5acc5128efd6195df881b680c Gerrit-Change-Number: 28342 Gerrit-PatchSet: 4 Gerrit-Owner: keith <keith(a)rhizomatica.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: neels <nhofmeyr(a)sysmocom.de> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 04 Nov 2025 15:40:06 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[M] Change in osmo-mgw[master]: mgw: rtp-patch rfc5993hr: convert to each end's respective format
by pespin 04 Nov '25

04 Nov '25

Attention is currently required from: falconia, laforge, neels. pespin has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/osmo-mgw/+/39869?usp=email ) Change subject: mgw: rtp-patch rfc5993hr: convert to each end's respective format ...................................................................... Patch Set 3: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/39869?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-mgw Gerrit-Branch: master Gerrit-Change-Id: I6b446ad83c540fb8b7e1aae24b78c27010212d64 Gerrit-Change-Number: 39869 Gerrit-PatchSet: 3 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Tue, 04 Nov 2025 11:13:21 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

2025

2024

2023

2022

gerrit-log November 2025