- gerrit-log - lists.osmocom.org

[XL] Change in libosmo-netif[master]: bring twjit into libosmo-netif
by pespin 19 Aug '25

19 Aug '25

Attention is currently required from: falconia. pespin has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email ) Change subject: bring twjit into libosmo-netif ...................................................................... Patch Set 5: (1 comment) File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/ca883c9f_1e2fa7d… : PS2, Line 504: rtph = osmo_rtp_get_hdr(msg); > this smooth packet flow will be delivered to the fixed timing application perfectly in order, without any disruptions - and I argue that this behavior is the best In here you are assuming that with an M bit set and no gap in the timestamp sequence means the data just be placed in sequence, which doesn't need to be necessarily the case. IMHO it makes more sense to apply handover since the newer flow after the M bit is the current one, which should take precedence over the old one. Otherwise it's like keep playing soft noise or music while there's already talk waiting to be played. > With my current algorithm, the duration of the gap delivered to the fixed timing application will be exactly what the RTP sender indicated in its timestamps No, it won't, because iiuc, due to the M bit, the timestamps before and after it are non-related. The fact that they may have some gap or not may be totally circumstantial. So to me you are treating the case where the new supposedly randomly taken tiemstamp (due to M bit) is in the 160-sequence different than the other 159 cases. -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: Ia3be5834571ca18b68939abbcf1ce3a879156658 Gerrit-Change-Number: 39280 Gerrit-PatchSet: 5 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: jolly <andreas(a)eversberg.eu> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Comment-Date: Tue, 19 Aug 2025 14:17:47 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[XL] Change in libosmo-netif[master]: bring twjit into libosmo-netif
by jolly 19 Aug '25

19 Aug '25

Attention is currently required from: falconia, pespin. jolly has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email ) Change subject: bring twjit into libosmo-netif ...................................................................... Patch Set 5: (1 comment) File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/489ebdbb_3dbbe7b… : PS5, Line 486: msgb_free(new_msg); Is there a twjit instance for every payload type or one for the complete RTP connection? telephone-event payload may (and will) have equal timestamps as the audio payload. There are codecs that split frames over several RTP packets. The sequence number increases, but the timestamp does not. (video codecs) -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: Ia3be5834571ca18b68939abbcf1ce3a879156658 Gerrit-Change-Number: 39280 Gerrit-PatchSet: 5 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: jolly <andreas(a)eversberg.eu> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 19 Aug 2025 13:56:26 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[XS] Change in osmo-pcu[master]: llc_queue_merge_prepend(): constify readonly ptr param
by pespin 19 Aug '25

19 Aug '25

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/40884?usp=email ) Change subject: llc_queue_merge_prepend(): constify readonly ptr param ...................................................................... llc_queue_merge_prepend(): constify readonly ptr param Change-Id: Ib96bc75535fff94f1d953e37d217a6f954de8ada --- M src/llc.c M src/llc.h 2 files changed, 2 insertions(+), 2 deletions(-) Approvals: Jenkins Builder: Verified fixeria: Looks good to me, but someone else must approve laforge: Looks good to me, approved diff --git a/src/llc.c b/src/llc.c index 45b8ac4..633ae49 100644 --- a/src/llc.c +++ b/src/llc.c @@ -234,7 +234,7 @@ } /* Prepend / Put back a previously dequeued LLC frame (llc_queue_dequeue()) */ -void llc_queue_merge_prepend(struct gprs_llc_queue *q, struct gprs_llc *llc) +void llc_queue_merge_prepend(struct gprs_llc_queue *q, const struct gprs_llc *llc) { struct MetaInfo *meta_storage; unsigned int len = llc_frame_length(llc); diff --git a/src/llc.h b/src/llc.h index 594f77f..b9f3180 100644 --- a/src/llc.h +++ b/src/llc.h @@ -138,7 +138,7 @@ void llc_queue_clear(struct gprs_llc_queue *q, struct gprs_rlcmac_bts *bts); void llc_queue_set_codel_interval(struct gprs_llc_queue *q, unsigned int interval); void llc_queue_move_and_merge(struct gprs_llc_queue *q, struct gprs_llc_queue *o); -void llc_queue_merge_prepend(struct gprs_llc_queue *q, struct gprs_llc *llc); +void llc_queue_merge_prepend(struct gprs_llc_queue *q, const struct gprs_llc *llc); void llc_queue_enqueue(struct gprs_llc_queue *q, struct msgb *llc_msg, const struct timespec *expire_time); struct msgb *llc_queue_dequeue(struct gprs_llc_queue *q, enum gprs_llc_queue_prio *out_prio, struct MetaInfo *out_info); -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/40884?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: Ib96bc75535fff94f1d953e37d217a6f954de8ada Gerrit-Change-Number: 40884 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[M] Change in osmo-pcu[master]: llc_queue: Store MetaInfo in msgb headroom instead of cb[]
by pespin 19 Aug '25

19 Aug '25

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/40885?usp=email ) Change subject: llc_queue: Store MetaInfo in msgb headroom instead of cb[] ...................................................................... llc_queue: Store MetaInfo in msgb headroom instead of cb[] "sizeof(*meta_storage) <= sizeof(llc_msg->cb)" assert fails on debian 13 armv7l. Since struct MetaInfo cannot always fit inside msgb->cb, move the struct MetaInfo into the headroom of the msgb. Related: OS#6831 Change-Id: I98d966c257d50d3b2fc326dce85ead5591acf51f --- M src/gprs_ms.c M src/llc.c M src/llc.h M tests/llc/LlcTest.cpp 4 files changed, 35 insertions(+), 42 deletions(-) Approvals: fixeria: Looks good to me, but someone else must approve Jenkins Builder: Verified laforge: Looks good to me, approved diff --git a/src/gprs_ms.c b/src/gprs_ms.c index ff7316b..1577a4a 100644 --- a/src/gprs_ms.c +++ b/src/gprs_ms.c @@ -1369,13 +1369,10 @@ LOGPMS(ms, DTBFDL, LOGL_DEBUG, "appending %u bytes to DL LLC queue\n", len); - struct msgb *llc_msg = msgb_alloc(len, "llc_pdu_queue"); - if (!llc_msg) - return -ENOMEM; - llc_queue_calc_pdu_lifetime(ms->bts, pdu_delay_csec, &expire_time); - memcpy(msgb_put(llc_msg, len), data, len); - llc_queue_enqueue(ms_llc_queue(ms), llc_msg, &expire_time); + rc = llc_queue_enqueue(ms_llc_queue(ms), data, len, &expire_time); + if (rc < 0) + return rc; ms_start_llc_timer(ms); dl_tbf = ms_dl_tbf(ms); diff --git a/src/llc.c b/src/llc.c index 633ae49..478d23d 100644 --- a/src/llc.c +++ b/src/llc.c @@ -141,24 +141,34 @@ } } -void llc_queue_enqueue(struct gprs_llc_queue *q, struct msgb *llc_msg, const struct timespec *expire_time) +int llc_queue_enqueue(struct gprs_llc_queue *q, const uint8_t *data, uint16_t len, const struct timespec *expire_time) { + struct msgb *llc_msg; struct MetaInfo *meta_storage; - struct gprs_llc_hdr *llc_hdr = (struct gprs_llc_hdr *)msgb_data(llc_msg); + struct gprs_llc_hdr *llc_hdr; enum gprs_llc_queue_prio prio; - osmo_static_assert(sizeof(*meta_storage) <= sizeof(llc_msg->cb), info_does_not_fit); + llc_msg = msgb_alloc_headroom(sizeof(*meta_storage) + len, sizeof(*meta_storage), "llc_pdu_queue"); + if (!llc_msg) + return -ENOMEM; - prio = llc_sapi2prio(llc_hdr->sapi); - - q->queue_size += 1; - q->queue_octets += msgb_length(llc_msg); - - meta_storage = (struct MetaInfo *)&llc_msg->cb[0]; + /* Fist set up MetaInfo in the msgb headroom: */ + meta_storage = (struct MetaInfo *)llc_msg->head; osmo_clock_gettime(CLOCK_MONOTONIC, &meta_storage->recv_time); meta_storage->expire_time = *expire_time; + /* Copy PDU to msgb data: */ + llc_hdr = (struct gprs_llc_hdr *)msgb_put(llc_msg, len); + memcpy(llc_hdr, data, len); + + prio = llc_sapi2prio(llc_hdr->sapi); + + /* Append: */ + q->queue_size += 1; + q->queue_octets += msgb_length(llc_msg); msgb_enqueue(&q->pq[prio].queue, llc_msg); + + return 0; } void llc_queue_clear(struct gprs_llc_queue *q, struct gprs_rlcmac_bts *bts) @@ -205,8 +215,8 @@ msg = msg1; msg1 = NULL; } else { - const struct MetaInfo *mi1 = (struct MetaInfo *)&msg1->cb[0]; - const struct MetaInfo *mi2 = (struct MetaInfo *)&msg2->cb[0]; + const struct MetaInfo *mi1 = (struct MetaInfo *)msg1->head; + const struct MetaInfo *mi2 = (struct MetaInfo *)msg2->head; if (timespeccmp(&mi2->recv_time, &mi1->recv_time, >)) { msg = msg1; @@ -236,20 +246,21 @@ /* Prepend / Put back a previously dequeued LLC frame (llc_queue_dequeue()) */ void llc_queue_merge_prepend(struct gprs_llc_queue *q, const struct gprs_llc *llc) { + struct msgb *llc_msg; struct MetaInfo *meta_storage; unsigned int len = llc_frame_length(llc); - struct msgb *llc_msg = msgb_alloc(len, "llc_pdu_queue"); + llc_msg = msgb_alloc_headroom(sizeof(*meta_storage) + len, sizeof(*meta_storage), "llc_pdu_queue"); OSMO_ASSERT(llc_msg); - memcpy(msgb_put(llc_msg, len), llc->frame, len); - q->queue_size += 1; - q->queue_octets += msgb_length(llc_msg); - - meta_storage = (struct MetaInfo *)&llc_msg->cb[0]; + meta_storage = (struct MetaInfo *)llc_msg->head; memcpy(meta_storage, &llc->meta_info, sizeof(struct MetaInfo)); + memcpy(msgb_put(llc_msg, len), llc->frame, len); + /* Prepend: */ + q->queue_size += 1; + q->queue_octets += msgb_length(llc_msg); llist_add(&llc_msg->list, &q->pq[llc->prio].queue); } @@ -272,7 +283,7 @@ if (!msg) return NULL; - meta_storage = (struct MetaInfo *)&msg->cb[0]; + meta_storage = (struct MetaInfo *)msg->head; q->queue_size -= 1; q->queue_octets -= msgb_length(msg); @@ -305,7 +316,7 @@ timespecadd(&tv_now, &hyst_delta, &tv_now2); while ((msg = llc_queue_pick_msg(q, &prio))) { - info = (const struct MetaInfo *)&msg->cb[0]; + info = (const struct MetaInfo *)msg->head; const struct timespec *tv_disc = &info->expire_time; const struct timespec *tv_recv = &info->recv_time; diff --git a/src/llc.h b/src/llc.h index b9f3180..31e427d 100644 --- a/src/llc.h +++ b/src/llc.h @@ -139,7 +139,7 @@ void llc_queue_set_codel_interval(struct gprs_llc_queue *q, unsigned int interval); void llc_queue_move_and_merge(struct gprs_llc_queue *q, struct gprs_llc_queue *o); void llc_queue_merge_prepend(struct gprs_llc_queue *q, const struct gprs_llc *llc); -void llc_queue_enqueue(struct gprs_llc_queue *q, struct msgb *llc_msg, const struct timespec *expire_time); +int llc_queue_enqueue(struct gprs_llc_queue *q, const uint8_t *data, uint16_t len, const struct timespec *expire_time); struct msgb *llc_queue_dequeue(struct gprs_llc_queue *q, enum gprs_llc_queue_prio *out_prio, struct MetaInfo *out_info); static inline size_t llc_queue_size(const struct gprs_llc_queue *q) diff --git a/tests/llc/LlcTest.cpp b/tests/llc/LlcTest.cpp index 9ed6f21..c0101fb 100644 --- a/tests/llc/LlcTest.cpp +++ b/tests/llc/LlcTest.cpp @@ -56,21 +56,6 @@ return ms_llc_queue(ms); } -static void enqueue_data(gprs_llc_queue *queue, const uint8_t *data, size_t len, - const struct timespec *expire_time) -{ - struct timespec *tv; - uint8_t *msg_data; - struct msgb *llc_msg = msgb_alloc(len + sizeof(*tv) * 2, - "llc_pdu_queue"); - - msg_data = (uint8_t *)msgb_put(llc_msg, len); - - memcpy(msg_data, data, len); - - llc_queue_enqueue(queue, llc_msg, expire_time); -} - static void dequeue_and_check(gprs_llc_queue *queue, const uint8_t *exp_data, size_t len, const MetaInfo *exp_info) { @@ -96,7 +81,7 @@ static void enqueue_data(gprs_llc_queue *queue, const char *message, const struct timespec *expire_time) { - enqueue_data(queue, (uint8_t *)(message), strlen(message), expire_time); + llc_queue_enqueue(queue, (uint8_t *)(message), strlen(message), expire_time); } static void dequeue_and_check(gprs_llc_queue *queue, const char *exp_message, -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/40885?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: I98d966c257d50d3b2fc326dce85ead5591acf51f Gerrit-Change-Number: 40885 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>

1 0

[XL] Change in libosmo-netif[master]: bring twjit into libosmo-netif
by falconia 18 Aug '25

18 Aug '25

Attention is currently required from: pespin. falconia has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email ) Change subject: bring twjit into libosmo-netif ...................................................................... Patch Set 5: (1 comment) File src/twjit.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39280/comment/62e74621_c69d26c… : PS2, Line 504: rtph = osmo_rtp_get_hdr(msg); > Thanks. After having read your document: […] I still disagree. To see why, let us consider a scenario in which you (presumably) believe checking M bit would make a difference. This purported scenario would have to have these two properties: * SSRC stays the same, or else twjit would consider it a handover; * All timestamp increments are integral multiples of 160, for the same reason; * Sequence number does not matter at all, as twjit does not look at it except for staff-oriented counters and RTCP-mandated analytics - it does not affect any of twjit's actual decisions. With the above prerequisites established, the next question is: gap or no gap? Consider the no-gap case first: there is a perfectly smooth, uninterrupted flow of RTP packets, but one of them has M bit set. With current code, this smooth packet flow will be delivered to the fixed timing application perfectly in order, without any disruptions - and I argue that this behavior is the best. Your proposal of treating M bit as handover would cause twjit state transition to HANDOVER, which would result either in some packets before the handover event being dropped if the new flow becomes ready (flow start criteria) soon enough, or in a gap (not present in the incoming stream) being fed to the output if the old flow underruns before the new one is ready. How would such behavior be any better than what I have currently? Now consider M bit preceded by a gap: some packets omitted, then an RTP packet with M bit set. Here the question becomes: underrun or no underrun? If the gap is long enough for twjit to experience an underrun before the flow resumes, then it makes no difference whether the flow-resuming packet has M bit set or not: twjit is starting from EMPTY state in this case. Now consider the no-underrun case: the configured buffer depth is high enough, and the gap short enough, to where the flow-resuming packet arrives before the buffer underruns. With my current algorithm, the duration of the gap delivered to the fixed timing application will be exactly what the RTP sender indicated in its timestamps; with your proposed modification, the gap would be unpredictably lengthened or shortened based on how long it takes for the post-handover flow to reach ready state. How is your way any better? In summary, I still fail to see *even one* scenario in which your proposed modification to my core algorithm would make an improvement. -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39280?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: Ia3be5834571ca18b68939abbcf1ce3a879156658 Gerrit-Change-Number: 39280 Gerrit-PatchSet: 5 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 18 Aug 2025 17:58:50 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[XS] Change in osmo-pcu[master]: llc_queue_merge_prepend(): constify readonly ptr param
by laforge 18 Aug '25

18 Aug '25

Attention is currently required from: pespin. laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-pcu/+/40884?usp=email ) Change subject: llc_queue_merge_prepend(): constify readonly ptr param ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/40884?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: Ib96bc75535fff94f1d953e37d217a6f954de8ada Gerrit-Change-Number: 40884 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 18 Aug 2025 17:38:11 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[M] Change in osmo-pcu[master]: llc_queue: Store MetaInfo in msgb headroom instead of cb[]
by laforge 18 Aug '25

18 Aug '25

Attention is currently required from: osmith, pespin. laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-pcu/+/40885?usp=email ) Change subject: llc_queue: Store MetaInfo in msgb headroom instead of cb[] ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/40885?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: I98d966c257d50d3b2fc326dce85ead5591acf51f Gerrit-Change-Number: 40885 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 18 Aug 2025 17:37:59 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

[XL] Change in libosmo-netif[master]: bring twrtp into libosmo-netif
by pespin 18 Aug '25

18 Aug '25

Attention is currently required from: falconia. pespin has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39281?usp=email ) Change subject: bring twrtp into libosmo-netif ...................................................................... Patch Set 5: (1 comment) File src/twrtp_base.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39281/comment/0915c024_0707acd… : PS1, Line 132: * another variant of this API with that alternative behavior. > I see what you are asking for now. […] ack, I think we are aligned with what I mean now :) -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39281?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: Ib63215aaf13ef8ab8f2e0c8d310164cd5c8824eb Gerrit-Change-Number: 39281 Gerrit-PatchSet: 5 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Comment-Date: Mon, 18 Aug 2025 16:55:56 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[XL] Change in libosmo-netif[master]: bring twrtp into libosmo-netif
by falconia 18 Aug '25

18 Aug '25

Attention is currently required from: pespin. falconia has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39281?usp=email ) Change subject: bring twrtp into libosmo-netif ...................................................................... Patch Set 5: (1 comment) File src/twrtp_base.c: https://gerrit.osmocom.org/c/libosmo-netif/+/39281/comment/4d6e95a1_8c237d4… : PS1, Line 132: * another variant of this API with that alternative behavior. > See 3GPP TS 25.414 clause 5.1.3.4. RTCP is optional in IuUP. […] I see what you are asking for now. In order to make it consistent, we would need to not only allow absent `rtcp_fd` in the low-level API `osmo_twrtp_supply_fds()`, but also add a Boolean argument to the higher-level API `osmo_twrtp_bind_local()`, enabling or disabling creation and binding of RTCP socket. Before I implement it in the next patch iteration, please confirm that this is what you want. -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39281?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: Ib63215aaf13ef8ab8f2e0c8d310164cd5c8824eb Gerrit-Change-Number: 39281 Gerrit-PatchSet: 5 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 18 Aug 2025 16:44:56 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>

1 0

[M] Change in osmo-pcu[master]: llc_queue: Store MetaInfo in msgb headroom instead of cb[]
by fixeria 18 Aug '25

18 Aug '25

Attention is currently required from: laforge, osmith, pespin. fixeria has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-pcu/+/40885?usp=email ) Change subject: llc_queue: Store MetaInfo in msgb headroom instead of cb[] ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/40885?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: I98d966c257d50d3b2fc326dce85ead5591acf51f Gerrit-Change-Number: 40885 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 18 Aug 2025 16:37:53 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

2026

2025

2024

2023

2022

gerrit-log