September 2023 - gerrit-log - lists.osmocom.org

[M] Change in osmo-msc[osmith/1.11.1]: CC: don't start guard timer on mid-call MNCC messages

by osmith

osmith has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-msc/+/34559?usp=email ) Change subject: CC: don't start guard timer on mid-call MNCC messages ...................................................................... CC: don't start guard timer on mid-call MNCC messages The intent of the guard timer is to clear hung or stuck states during call setup or teardown. However, there are some MNCC messages that will be exchanged between OsmoMSC (passing CC messages to and from the MS) and the external MNCC agent during the active call state, not related to setup or teardown: DTMF start and stop, plus call hold and retrieve operations for call waiting. Unpatched OsmoMSC restarts the guard timer on every received MNCC message, even those that pass through to CC without affecting any state, and the result is breakage for users. Consider the case of an IVR where you have to press some DTMF keys before you can be transferred to a human operator. You press the needed keys, get the human operator, and start talking. Then 3 minutes into your conversion (default guard timer duration) your call unceremoniously disconnects without any warning. Fix: look at the MNCC message type, and skip the call to start the guard timer for known-benign MNCC messages. Change-Id: Ibe2dd53f8e9e06d175b64df67d2a2e3e2d4155aa --- M src/libmsc/gsm_04_08_cc.c 1 file changed, 49 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/59/34559/1 diff --git a/src/libmsc/gsm_04_08_cc.c b/src/libmsc/gsm_04_08_cc.c index 6148bbd..1e2c5af 100644 --- a/src/libmsc/gsm_04_08_cc.c +++ b/src/libmsc/gsm_04_08_cc.c @@ -2383,7 +2383,27 @@ log_mncc_rx_tx(trans, "rx", msg); - gsm48_start_guard_timer(trans); + /* + * The step of gsm48_start_guard_timer() needs to be done for + * major state-impacting MNCC messages, but not for those + * that are a mere pass-through to CC messages to MS. + */ + switch (msg->msg_type) { + case MNCC_PROGRESS_REQ: + case MNCC_NOTIFY_REQ: + case MNCC_FACILITY_REQ: + case MNCC_START_DTMF_RSP: + case MNCC_START_DTMF_REJ: + case MNCC_STOP_DTMF_RSP: + case MNCC_HOLD_CNF: + case MNCC_HOLD_REJ: + case MNCC_RETRIEVE_CNF: + case MNCC_RETRIEVE_REJ: + case MNCC_USERINFO_REQ: + break; + default: + gsm48_start_guard_timer(trans); + } trans->cc.mncc_initiated = true; if (trans->msc_a) -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/34559?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: osmith/1.11.1 Gerrit-Change-Id: Ibe2dd53f8e9e06d175b64df67d2a2e3e2d4155aa Gerrit-Change-Number: 34559 Gerrit-PatchSet: 1 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-CC: falconia <falcon(a)freecalypso.org> Gerrit-MessageType: newchange

1 year, 8 months

1
0
0 0

[M] Change in osmo-msc[osmith/1.11.1]: fix codecs in internal call bridge

by osmith

osmith has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-msc/+/34557?usp=email ) Change subject: fix codecs in internal call bridge ...................................................................... fix codecs in internal call bridge This is a fixup for the patch '3G: decapsulate IuUP to AMR at the MGW; allow 3G<-AMR->2G' I386a6a426c318040b019ab5541689c67e94672a1 After above patch, osmo-msc intelligently decides which codecs to run on which legs of the RTP streams. In the meantime, it seems the necessary matching changes to call_leg_local_bridge() had been lost somehow. Testing 3G to 3G voice now, I noticed that call_leg_local_bridge() overwrites the intelligent choices made earlier. The history of an MGW endpoint that should convert from IUFP to plain AMR, extracted from a pcap, looks like this: <- CRCX None None -> CRCX-OK audio 4050 RTP/AVP 112 None <- MDCX audio 4056 RTP/AVP 112 AMR -> MDCX-OK audio 4050 RTP/AVP 112 AMR <- MDCX audio 4056 RTP/AVP 96 VND.3GPP.IUFP -> MDCX-OK audio 4050 RTP/AVP 96 VND.3GPP.IUFP So after call_leg_local_bridge(), there is an extra MDCX + MDCX-OK that switches the codec from 112 AMR back to 96 IUFP. That is because call_leg_local_bridge() copies the *RAN* side's codec to both CN sides, which used to be ok when RAN and CN codecs were always identical. Instead, adjust only the CN sides of the MGW endpoints, and adjust them so that both CN sides are identical. osmo-mgw should then be able to trivially translate the codecs appropriately. Change-Id: I130bcd77ec57e332370c487a11b0b973b6e1089d --- M src/libmsc/call_leg.c 1 file changed, 73 insertions(+), 11 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/57/34557/1 diff --git a/src/libmsc/call_leg.c b/src/libmsc/call_leg.c index d0dc642..b797322 100644 --- a/src/libmsc/call_leg.c +++ b/src/libmsc/call_leg.c @@ -352,25 +352,46 @@ int call_leg_local_bridge(struct call_leg *cl1, uint32_t call_id1, struct gsm_trans *trans1, struct call_leg *cl2, uint32_t call_id2, struct gsm_trans *trans2) { - struct sdp_audio_codecs *codecs; + struct sdp_audio_codecs *cn_codecs = NULL; cl1->local_bridge = cl2; cl2->local_bridge = cl1; - /* We may just copy the codec info we have for the RAN side of the first leg to the CN side of both legs. This - * also means that if both legs use different codecs the MGW must perform transcoding on the second leg. */ - if (!cl1->rtp[RTP_TO_RAN] || !cl1->rtp[RTP_TO_RAN]->codecs_known) { - LOG_CALL_LEG(cl1, LOGL_ERROR, "RAN-side RTP stream codec is not known, not ready for bridging\n"); + /* Marry the two CN sides of the call legs. Call establishment should have made all efforts for these to be + * compatible. However, for local bridging, the codecs and payload type numbers must be exactly identical on + * both sides. Both sides may so far have different payload type numbers or slightly differing codecs, but it + * will only work when the SDP on the RTP_TO_CN sides of the call legs talk the same payload type numbers. + * So, simply take the SDP from one RTP_TO_CN side, and overwrite the other RTP_TO_CN side's SDP with it. + * If all goes to plan, the codecs will be identical, or possibly the MGW will do a conversion like AMR-BE to + * AMR-OA. In the worst case, the other call leg cannot transcode, and the call fails -- because codec + * negotiation did not do a good enough job. + * + * Copy one call leg's CN config to the other: + * + * call leg 1 call leg 2 + * ---MGW-ep------- ---MGW-ep------- + * RAN CN CN RAN + * AMR:112 AMR:112 AMR:96 AMR:96 + * | + * +-------+ + * | + * V + * AMR:112 AMR:112 AMR:112 AMR:96 + * ^MGW-endpoint converts payload type numbers between 112 and 96. + */ + if (cl1->rtp[RTP_TO_CN] && cl1->rtp[RTP_TO_CN]->codecs_known) + cn_codecs = &cl1->rtp[RTP_TO_CN]->codecs; + else if (cl2->rtp[RTP_TO_CN] && cl2->rtp[RTP_TO_CN]->codecs_known) + cn_codecs = &cl2->rtp[RTP_TO_CN]->codecs; + if (!cn_codecs) { + LOG_CALL_LEG(cl1, LOGL_ERROR, "RAN-side CN stream codec is not known, not ready for bridging\n"); + LOG_CALL_LEG(cl2, LOGL_ERROR, "RAN-side CN stream codec is not known, not ready for bridging\n"); return -EINVAL; } - codecs = &cl1->rtp[RTP_TO_RAN]->codecs; - - if (!cl1->rtp[RTP_TO_CN] || !cl2->rtp[RTP_TO_CN]) - return -ENOTCONN; call_leg_ensure_ci(cl1, RTP_TO_CN, call_id1, trans1, - codecs, &cl2->rtp[RTP_TO_CN]->local); + cn_codecs, &cl2->rtp[RTP_TO_CN]->local); call_leg_ensure_ci(cl2, RTP_TO_CN, call_id2, trans2, - codecs, &cl1->rtp[RTP_TO_CN]->local); + cn_codecs, &cl1->rtp[RTP_TO_CN]->local); return 0; } -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/34557?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: osmith/1.11.1 Gerrit-Change-Id: I130bcd77ec57e332370c487a11b0b973b6e1089d Gerrit-Change-Number: 34557 Gerrit-PatchSet: 1 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-MessageType: newchange

1 year, 8 months

1
0
0 0

[S] Change in osmo-msc[osmith/1.11.1]: make two functions static

by osmith

osmith has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-msc/+/34558?usp=email ) Change subject: make two functions static ...................................................................... make two functions static Change-Id: I1de0f35f1606c997777f34bbf4033e069aadbc64 --- M include/osmocom/msc/mncc.h M src/libmsc/gsm_04_08_cc.c M src/osmo-msc/msc_main.c 3 files changed, 12 insertions(+), 4 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/58/34558/1 diff --git a/include/osmocom/msc/mncc.h b/include/osmocom/msc/mncc.h index 8a1e4ad..c8f3bfd 100644 --- a/include/osmocom/msc/mncc.h +++ b/include/osmocom/msc/mncc.h @@ -219,7 +219,6 @@ const char *get_mncc_name(int value); void mncc_set_cause(struct gsm_mncc *data, int loc, int val); -void cc_tx_to_mncc(struct gsm_network *net, struct msgb *msg); /* input from CC code into mncc_builtin */ int int_mncc_recv(struct gsm_network *net, struct msgb *msg); diff --git a/src/libmsc/gsm_04_08_cc.c b/src/libmsc/gsm_04_08_cc.c index 5908db9..6148bbd 100644 --- a/src/libmsc/gsm_04_08_cc.c +++ b/src/libmsc/gsm_04_08_cc.c @@ -129,7 +129,7 @@ /* Call Control */ -void cc_tx_to_mncc(struct gsm_network *net, struct msgb *msg) +static void cc_tx_to_mncc(struct gsm_network *net, struct msgb *msg) { net->mncc_recv(net, msg); } diff --git a/src/osmo-msc/msc_main.c b/src/osmo-msc/msc_main.c index 9808e86..913bd21 100644 --- a/src/osmo-msc/msc_main.c +++ b/src/osmo-msc/msc_main.c @@ -242,8 +242,8 @@ } } -struct gsm_network *msc_network_alloc(void *ctx, - mncc_recv_cb_t mncc_recv) +static struct gsm_network *msc_network_alloc(void *ctx, + mncc_recv_cb_t mncc_recv) { struct gsm_network *net = gsm_network_init(ctx, mncc_recv); if (!net) -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/34558?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: osmith/1.11.1 Gerrit-Change-Id: I1de0f35f1606c997777f34bbf4033e069aadbc64 Gerrit-Change-Number: 34558 Gerrit-PatchSet: 1 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-MessageType: newchange

1 year, 8 months

1
0
0 0

[S] Change in osmo-msc[osmith/1.11.1]: ASCI: Remove duplicated CLEAR COMMAND from VGCS/VBS channel handling

by osmith

osmith has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-msc/+/34560?usp=email ) Change subject: ASCI: Remove duplicated CLEAR COMMAND from VGCS/VBS channel handling ...................................................................... ASCI: Remove duplicated CLEAR COMMAND from VGCS/VBS channel handling Change-Id: I5e4891091c2ce56d4fd4a7f5f67156a94ade852d Related: OS#4854 --- M src/libmsc/msc_vgcs.c 1 file changed, 10 insertions(+), 8 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/60/34560/1 diff --git a/src/libmsc/msc_vgcs.c b/src/libmsc/msc_vgcs.c index f3867fe..772a9e3 100644 --- a/src/libmsc/msc_vgcs.c +++ b/src/libmsc/msc_vgcs.c @@ -2508,14 +2508,6 @@ LOG_CELL(cell, LOGL_NOTICE, "Received VGCS/VBS ASSIGNMENT FAILURE from BSS.\n"); channel_fail: bss = cell->bss; - /* Remove cell. */ - tx_ran_msg = (struct ran_msg){ - .msg_type = RAN_MSG_CLEAR_COMMAND, - .clear_command = { - .gsm0808_cause = GSM0808_CAUSE_PROTOCOL_ERROR_BETWEEN_BSS_AND_MSC, - }, - }; - ran_encode_and_send(fi, &tx_ran_msg, cell->conn, false); cell_clear(cell, GSM0808_CAUSE_PROTOCOL_ERROR_BETWEEN_BSS_AND_MSC); /* Notify BSS FSM about channel failure. */ if (bss) -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/34560?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: osmith/1.11.1 Gerrit-Change-Id: I5e4891091c2ce56d4fd4a7f5f67156a94ade852d Gerrit-Change-Number: 34560 Gerrit-PatchSet: 1 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-CC: jolly <andreas(a)eversberg.eu> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-MessageType: newchange

1 year, 8 months

1
0
0 0

[S] Change in osmo-mgw[master]: mgw: Configure IuUP if codec set during MDCX

by pespin

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-mgw/+/34548?usp=email ) Change subject: mgw: Configure IuUP if codec set during MDCX ...................................................................... mgw: Configure IuUP if codec set during MDCX The mgcp client may first configure the connection to use RTP-AMR, but after setting up another call leg may find out that both legs are IuUP and hence want to forward the IuUP between the 2 connections instead. In that case, an MDCX with codec VND.3GPP.IUFP would be set. Until now, osmo-mgw didn't take that scenario into account, and it was only upgrading the rtp conn to iuup internally during CRCX. As a result, in the mentioned scenario osmo-mgw would continue to output RTP instead of IuUP after the MDCX with VND.3GPP.IUFP, which is wrong. Related: SYS#6578 Change-Id: Ic94bf90f54d8ba3e65a2cd52734867847f3a60c2 --- M src/libosmo-mgcp/mgcp_protocol.c 1 file changed, 25 insertions(+), 0 deletions(-) Approvals: osmith: Looks good to me, but someone else must approve; Verified Jenkins Builder: Verified pespin: Looks good to me, approved diff --git a/src/libosmo-mgcp/mgcp_protocol.c b/src/libosmo-mgcp/mgcp_protocol.c index 7795734..809622b 100644 --- a/src/libosmo-mgcp/mgcp_protocol.c +++ b/src/libosmo-mgcp/mgcp_protocol.c @@ -1293,6 +1293,10 @@ error_code = rc; goto error3; } + /* Upgrade the conn type RTP_DEFAULT->RTP_IUUP if needed based on requested codec: */ + /* TODO: "codec" probably needs to be moved from endp to conn */ + if (conn->type == MGCP_RTP_DEFAULT && strcmp(conn->end.codec->subtype_name, "VND.3GPP.IUFP") == 0) + rc = mgcp_conn_iuup_init(conn); /* check connection mode setting */ if (conn->conn->mode != MGCP_CONN_LOOPBACK -- To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/34548?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-mgw Gerrit-Branch: master Gerrit-Change-Id: Ic94bf90f54d8ba3e65a2cd52734867847f3a60c2 Gerrit-Change-Number: 34548 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

1 year, 8 months

1
0
0 0

[S] Change in osmo-mgw[master]: mgw: Configure IuUP if codec set during MDCX

by pespin

Attention is currently required from: dexter, neels. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-mgw/+/34548?usp=email ) Change subject: mgw: Configure IuUP if codec set during MDCX ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/34548?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-mgw Gerrit-Branch: master Gerrit-Change-Id: Ic94bf90f54d8ba3e65a2cd52734867847f3a60c2 Gerrit-Change-Number: 34548 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 Sep 2023 10:59:44 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 year, 8 months

1
0
0 0

[S] Change in osmocom-bb[master]: fixup ASCI: Add group receive and transmit mode support to MM laye

by pespin

Attention is currently required from: jolly. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/34556?usp=email ) Change subject: fixup ASCI: Add group receive and transmit mode support to MM laye ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/34556?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: Ia6d0ac341b4b80199b344e04068ac152d7cc2ee7 Gerrit-Change-Number: 34556 Gerrit-PatchSet: 1 Gerrit-Owner: jolly <andreas(a)eversberg.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Comment-Date: Thu, 28 Sep 2023 10:34:04 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 year, 8 months

1
0
0 0

[S] Change in osmocom-bb[master]: Add header length check to received CCCH messages

by pespin

Attention is currently required from: jolly. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/34555?usp=email ) Change subject: Add header length check to received CCCH messages ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/34555?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I3bc6b0b997e6ea1048c3357d276adfcc1638b02b Gerrit-Change-Number: 34555 Gerrit-PatchSet: 1 Gerrit-Owner: jolly <andreas(a)eversberg.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Comment-Date: Thu, 28 Sep 2023 10:33:39 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 year, 8 months

1
0
0 0

[M] Change in osmo-e1d[master]: Automatically reset RIFO on underrun/overflow

by pespin

Attention is currently required from: jolly, laforge. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-e1d/+/34554?usp=email ) Change subject: Automatically reset RIFO on underrun/overflow ...................................................................... Patch Set 1: (3 comments) Commit Message: https://gerrit.osmocom.org/c/osmo-e1d/+/34554/comment/545e43dd_8de573c1 PS1, Line 18: twice the value of max_frame_count. It specifies when the RIFO will max_frame_count is set to twice the value of max_frame_count? Sounds wrong. File src/octoi/e1oip.c: https://gerrit.osmocom.org/c/osmo-e1d/+/34554/comment/3bde4046_34241e5f PS1, Line 272: if (rc < 0) { did you think about returning a specific error code to signal this exact error? like -ERANGE. File src/octoi/frame_rifo.c: https://gerrit.osmocom.org/c/osmo-e1d/+/34554/comment/d375c806_1eb31ddd PS1, Line 106: int frame_rifo_in(struct frame_rifo *rifo, const uint8_t *frame, uint32_t fn, int max_frame_count) can max_frame_count be negative? unsigned? -- To view, visit https://gerrit.osmocom.org/c/osmo-e1d/+/34554?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-e1d Gerrit-Branch: master Gerrit-Change-Id: Id7ccbfbdb288990c01f185dec79a1022a68b4748 Gerrit-Change-Number: 34554 Gerrit-PatchSet: 1 Gerrit-Owner: jolly <andreas(a)eversberg.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: jolly <andreas(a)eversberg.eu> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Thu, 28 Sep 2023 10:31:47 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 year, 8 months

1
0
0 0

[M] Change in osmo-bsc[master]: vty: make NCC Permitted (SI2) configurable

by osmith

Attention is currently required from: fixeria, pespin. osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/34543?usp=email ) Change subject: vty: make NCC Permitted (SI2) configurable ...................................................................... Patch Set 1: (1 comment) File src/osmo-bsc/bts_vty.c: https://gerrit.osmocom.org/c/osmo-bsc/+/34543/comment/177916e8_98a21a27 PS1, Line 1447: no ncc-permitted > ACK, I also found it a bit confusing and I was expecting some "all" value. I see how "no ncc-permitted" meaning all is confusing. I'll add "ncc-permitted all" instead. Regarding "no ncc-permitted 2" syntax: I think this will also be confusing when used in combination with ncc-permitted without "no" or when used multiple times, e.g.: ``` ncc-permitted 2 3 4 5 no ncc-permitted 2 no ncc-permitted 3 ``` It's not clear for users reading the config what will happen here, it could be implemented as resulting in "ncc-permitted 1 2 4 5 6 7 8" or resulting in "ncc-permitted 4 5". Therefore I think it's best to not add "no ncc-permitted" for disabling specific NCC values. -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/34543?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: I71bb855c35378f8f0598bc11a42bd274b7232a5e Gerrit-Change-Number: 34543 Gerrit-PatchSet: 1 Gerrit-Owner: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 Sep 2023 10:10:16 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: comment

1 year, 8 months

1
0
0 0

2025

2024

2023

2022

gerrit-log September 2023