pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-bts/+/32221 )
Change subject: Fix octet 2 of NM GPRS Cell
......................................................................
Fix octet 2 of NM GPRS Cell
Octet 2 should contain the address of the GPRS cell in the GPRS NSE
object. Since there's 1 GPRS Cell per BTS and we have only 1 BTS in
osmo-bts, then this address should be 0.
Otherwise, osmo-bts answers sometimes using (0x00, 0xff,0xff) instead of
requested (0x00, 0x00, 0xff), for instance when ACKing an Admin Unlock.
This is kinda still fine since value 0xff has the meaning of "all"
addresses, and that means the only one available.
Still, it's not the proper way to identify the object, so this patch
fixes it.
Change-Id: I2ea05778f5b5ac335c75f3958324664553da7f0d
---
M src/common/bts.c
1 file changed, 20 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/21/32221/1
diff --git a/src/common/bts.c b/src/common/bts.c
index 051f41b..29f0c56 100644
--- a/src/common/bts.c
+++ b/src/common/bts.c
@@ -280,7 +280,7 @@
memcpy(&bts->gprs.cell.timer, bts_cell_timer_default,
sizeof(bts->gprs.cell.timer));
gsm_mo_init(&bts->gprs.cell.mo, bts, NM_OC_GPRS_CELL,
- bts->nr, 0xff, 0xff);
+ bts->nr, 0, 0xff);
memcpy(&bts->gprs.cell.rlc_cfg, &rlc_cfg_default,
sizeof(bts->gprs.cell.rlc_cfg));
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32221
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I2ea05778f5b5ac335c75f3958324664553da7f0d
Gerrit-Change-Number: 32221
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: fixeria.
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-bts/+/32213
to look at the new patch set (#7).
Change subject: Introduce NM FSM for GPRS NSE object
......................................................................
Introduce NM FSM for GPRS NSE object
Related: OS#5994
Change-Id: I01eadc63214a2eb5e1bce455c7e5b62bd41905ea
---
M include/osmo-bts/bts.h
M include/osmo-bts/nm_common_fsm.h
M src/common/Makefile.am
M src/common/bts.c
M src/common/nm_bts_sm_fsm.c
A src/common/nm_gprs_nse_fsm.c
M src/common/oml.c
M src/osmo-bts-lc15/oml.c
M src/osmo-bts-oc2g/oml.c
M src/osmo-bts-octphy/l1_oml.c
M src/osmo-bts-omldummy/bts_model.c
M src/osmo-bts-sysmo/oml.c
M src/osmo-bts-trx/l1_if.c
M src/osmo-bts-virtual/bts_model.c
14 files changed, 378 insertions(+), 56 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/13/32213/7
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32213
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I01eadc63214a2eb5e1bce455c7e5b62bd41905ea
Gerrit-Change-Number: 32213
Gerrit-PatchSet: 7
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: newpatchset
Jenkins Builder has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32220 )
Change subject: MGCP_Test: add new testcases for oa/bwe conversion
......................................................................
Patch Set 1:
(2 comments)
File mgw/MGCP_Test.ttcn:
Robot Comment from checkpatch (run ID jenkins-gerrit-lint-5757):
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32220/comment/b753d3d5_bb42…
PS1, Line 2455: "octet-align=0", ''O); /* We expect to see NO bandwith efficient packets! */
'bandwith' may be misspelled - perhaps 'bandwidth'?
Robot Comment from checkpatch (run ID jenkins-gerrit-lint-5757):
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32220/comment/ee312482_615e…
PS1, Line 2460: "octet-align=0", ''O, /* We expect to see NO bandwith efficient packets! */
'bandwith' may be misspelled - perhaps 'bandwidth'?
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32220
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I2b2d7ef7fb4fe31111aa8665c4d4295425502451
Gerrit-Change-Number: 32220
Gerrit-PatchSet: 1
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-CC: Jenkins Builder
Gerrit-Comment-Date: Wed, 05 Apr 2023 12:28:41 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: pespin.
dexter has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32153 )
Change subject: MGCP_Test: support multiple codecs
......................................................................
Patch Set 5:
(3 comments)
File library/RTP_Emulation.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32153/comment/f8c85b0a_26f2…
PS4, Line 364: private function f_check_fixed_rx_payloads(octetstring rtp_data, INT7b rtp_payload_type) runs on RTP_Emulation_CT {
> it feels a bit strange having the rtp_Data before the rtp_payload_type, but not criticial.
Done
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32153/comment/b57944c0_fdcf…
PS4, Line 376: if (rtp_data == g_cfg.rx_payloads[i].fixed_payload and rtp_payload_type == g_cfg.rx_payloads[i].payload_type) {
> split into 2 lines?
Done
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32153/comment/d085a2fe_0ba1…
PS4, Line 388: if (payload_present and payload_error) {
> This function implementation seem overcmplex with all those bool vars. […]
Since we now have to match multiple payload type numbers with multiple optional defined payloads the matching got more complicated. I have now revisited this function and added comments so now it is hopefully better to understand.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32153
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I8422313fccad1bfcee52c933f643068bebdaf2d5
Gerrit-Change-Number: 32153
Gerrit-PatchSet: 5
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 05 Apr 2023 12:28:06 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
dexter has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32220 )
Change subject: MGCP_Test: add new testcases for oa/bwe conversion
......................................................................
MGCP_Test: add new testcases for oa/bwe conversion
The octet aligned to bandwith efficient conversion is currently only
tested in scenarios where only one codec is assigned on both sides.
However, there may be call agents that will assign bandwith efficient
and octet aligned on one side for compatibility reasons. If this is the
case, then OsmoMGW should always chose the format that requires no
conversation.
Related: OS#5461
Change-Id: I2b2d7ef7fb4fe31111aa8665c4d4295425502451
---
M mgw/MGCP_Test.ttcn
1 file changed, 71 insertions(+), 11 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/20/32220/1
diff --git a/mgw/MGCP_Test.ttcn b/mgw/MGCP_Test.ttcn
index 73d7be2..01945bf 100644
--- a/mgw/MGCP_Test.ttcn
+++ b/mgw/MGCP_Test.ttcn
@@ -2351,7 +2351,9 @@
/* create two local RTP emulations; create two connections on MGW EP, see if
* exchanged data is converted between AMR octet-aligned and bandwith
* efficient-mode */
- function f_TC_amr_x_x_rtp_conversion(octetstring pl0, octetstring pl1, charstring fmtp0, charstring fmtp1) runs on dummy_CT {
+ function f_TC_amr_x_x_rtp_conversion(charstring fmtp0, octetstring pl0,
+ charstring fmtp1a, octetstring pl1a,
+ charstring fmtp1b, octetstring pl1b) runs on dummy_CT {
var RtpFlowData flow[2];
var RtpemStats stats[2];
var MgcpResponse resp;
@@ -2372,13 +2374,25 @@
f_flow_create(RTPEM[0], ep, call_id, "sendrecv", flow[0]);
/* Connection #1 (Bidirectional) */
- flow[1] := valueof(t_RtpFlow(mp_local_ipv4, mp_remote_ipv4, 112, "AMR/8000", fmtp1));
+ flow[1] := valueof(t_RtpFlow(mp_local_ipv4, mp_remote_ipv4, 112, "AMR/8000", fmtp1a));
flow[1].em.portnr := 20000;
flow[1].rtp_cfg := c_RtpemDefaultCfg;
- flow[1].rtp_cfg.rx_payloads[0].payload_type := flow[1].codec_descr[0].pt;
- flow[1].rtp_cfg.tx_payloads[0].payload_type := flow[1].codec_descr[0].pt;
- flow[1].rtp_cfg.rx_payloads[0].fixed_payload := pl1;
- flow[1].rtp_cfg.tx_payloads[0].fixed_payload := pl1;
+ flow[1].rtp_cfg.rx_payloads := {};
+ flow[1].rtp_cfg.tx_payloads := {};
+ if (pl1a != ''O) {
+ flow[1].rtp_cfg.rx_payloads := flow[1].rtp_cfg.rx_payloads & {{112, pl1a}};
+ flow[1].rtp_cfg.tx_payloads := flow[1].rtp_cfg.tx_payloads & {{112, pl1a}};
+ }
+
+ /* The second fmtp parameter is to simulate a call agent that offers the transmission both modes. */
+ if (fmtp1b != "") {
+ flow[1].codec_descr := flow[1].codec_descr & {{113, "AMR/8000", fmtp1b}};
+ if (pl1b != ''O) {
+ flow[1].rtp_cfg.rx_payloads := flow[1].rtp_cfg.rx_payloads & {{113, pl1b}};
+ flow[1].rtp_cfg.tx_payloads := flow[1].rtp_cfg.tx_payloads & {{113, pl1b}};
+ }
+ }
+
f_flow_create(RTPEM[1], ep, call_id, "sendrecv", flow[1]);
/* Send RTP packets to connection #0, receive on connection #1 */
@@ -2421,16 +2435,41 @@
const octetstring rtp_amr_5_15k_oa := '100c4e9ba850e30d5d53d04de41e7c'O;
const octetstring rtp_amr_5_15k_bwe := '10d3a6ea1438c35754f41379079f'O;
+ /* Only one codec on each side */
testcase TC_amr_oa_bwe_rtp_conversion() runs on dummy_CT {
- f_TC_amr_x_x_rtp_conversion(rtp_amr_5_90k_oa, rtp_amr_5_90k_bwe, "octet-align=1", "octet-align=0");
+ f_TC_amr_x_x_rtp_conversion("octet-align=1", rtp_amr_5_90k_oa, "octet-align=0", rtp_amr_5_90k_bwe, "", ''O);
}
-
testcase TC_amr_oa_oa_rtp_conversion() runs on dummy_CT {
- f_TC_amr_x_x_rtp_conversion(rtp_amr_5_15k_oa, rtp_amr_5_15k_oa, "octet-align=1", "octet-align=1");
+ f_TC_amr_x_x_rtp_conversion("octet-align=1", rtp_amr_5_15k_oa, "octet-align=1", rtp_amr_5_15k_oa, "", ''O);
+ }
+ testcase TC_amr_bwe_bwe_rtp_conversion() runs on dummy_CT {
+ f_TC_amr_x_x_rtp_conversion("octet-align=0", rtp_amr_5_15k_bwe, "octet-align=0", rtp_amr_5_15k_bwe, "", ''O);
}
- testcase TC_amr_bwe_bwe_rtp_conversion() runs on dummy_CT {
- f_TC_amr_x_x_rtp_conversion(rtp_amr_5_15k_bwe, rtp_amr_5_15k_bwe, "octet-align=0", "octet-align=0");
+ /* Only one codec on one side, two codecs (compatibility) on other side. The payloads are the same on both
+ * sides, so the expectation is that conversion must not be performed. Each test is done with both formats in
+ * two different configurations.*/
+ testcase TC_amr_oa_oa_no_bwe_rtp_conversion() runs on dummy_CT {
+ f_TC_amr_x_x_rtp_conversion("octet-align=1", rtp_amr_5_15k_oa,
+ "octet-align=1", rtp_amr_5_15k_oa,
+ "octet-align=0", ''O); /* We expect to see NO bandwith efficient packets! */
+ }
+ testcase TC_amr_oa_no_bwe_oa_rtp_conversion() runs on dummy_CT {
+ /* (Same as above but flipped on the opposite side) */
+ f_TC_amr_x_x_rtp_conversion("octet-align=1", rtp_amr_5_15k_oa,
+ "octet-align=0", ''O, /* We expect to see NO bandwith efficient packets! */
+ "octet-align=1", rtp_amr_5_15k_oa);
+ }
+ testcase TC_amr_bwe_bwe_no_oa_rtp_conversion() runs on dummy_CT {
+ f_TC_amr_x_x_rtp_conversion("octet-align=0", rtp_amr_5_15k_bwe,
+ "octet-align=0", rtp_amr_5_15k_bwe,
+ "octet-align=1", ''O); /* We expect to see NO octet aligned packets! */
+ }
+ testcase TC_amr_bwe_no_oa_bwe_rtp_conversion() runs on dummy_CT {
+ /* (Same as above but flipped on the opposite side) */
+ f_TC_amr_x_x_rtp_conversion("octet-align=0", rtp_amr_5_15k_bwe,
+ "octet-align=1", ''O, /* We expect to see NO octet aligned packets! */
+ "octet-align=0", rtp_amr_5_15k_bwe);
}
/* TODO: Double-DLCX (no retransmission) */
@@ -3028,6 +3067,10 @@
execute(TC_amr_oa_bwe_rtp_conversion());
execute(TC_amr_oa_oa_rtp_conversion());
execute(TC_amr_bwe_bwe_rtp_conversion());
+ execute(TC_amr_oa_oa_no_bwe_rtp_conversion());
+ execute(TC_amr_oa_no_bwe_oa_rtp_conversion());
+ execute(TC_amr_bwe_bwe_no_oa_rtp_conversion());
+ execute(TC_amr_bwe_no_oa_bwe_rtp_conversion());
execute(TC_conn_timeout());
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32220
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I2b2d7ef7fb4fe31111aa8665c4d4295425502451
Gerrit-Change-Number: 32220
Gerrit-PatchSet: 1
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: pespin.
Hello Jenkins Builder, laforge, pespin,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32153
to look at the new patch set (#5).
Change subject: MGCP_Test: support multiple codecs
......................................................................
MGCP_Test: support multiple codecs
At the moment The RTP emulation and MGCP_Test only allow to specify one
codec and one set of RX/TX fixed payload octet strings to verify against.
This is quite limiting since it might be necessary to test against
different types and formats of payloads simultaneously in order to see
if osmo-mgw converts or forwards them correctly.
Let's extend this to support multiple codecs on MGCP/SDP level plus
support for multiple RTP payloads on RTP emulation level.
Related: OS#5461
Change-Id: I8422313fccad1bfcee52c933f643068bebdaf2d5
---
M bts/BTS_Tests.ttcn
M hnodeb/HNBGW_ConnectionHandler.ttcn
M library/RTP_Emulation.ttcn
M mgw/MGCP_Test.ttcn
4 files changed, 216 insertions(+), 98 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/53/32153/5
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32153
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I8422313fccad1bfcee52c933f643068bebdaf2d5
Gerrit-Change-Number: 32153
Gerrit-PatchSet: 5
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newpatchset
Attention is currently required from: dexter.
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-mgw/+/32218
to look at the new patch set (#2).
Change subject: mgcp_codec: fix codec decision
......................................................................
mgcp_codec: fix codec decision
Unfortunately OsmoMGW was never really tested with multiple different
codecs on either side of the connection. While OsmoMSC and OsmoBSC only
assign exactly one codec on each side this has never been a problem,
however it might become a problem when a call againt assigns multiple
codecs on one side. This has been observed in a setup where OsmoMGW had
one leg towards an external call agent. Also due to recent upgrades to
the TTCN3 tests we are now able to simulate different codecs on both
sides to pinpoint issues.
Testing has shown that OsmoMGW has difficulties with multiple codecs.
The reason for this is that the function that makes the codec decision
was not fully finished. So let's finish the codec decision function and
let's also use that decision when patching the payload type of outgoing
RTP packets.
Related: OS#5461
Change-Id: I6c3291f825488e5d8ce136aeb18450156794aeb5
---
M include/osmocom/mgcp/mgcp_codec.h
M include/osmocom/mgcp/mgcp_trunk.h
M src/libosmo-mgcp/mgcp_codec.c
M src/libosmo-mgcp/mgcp_network.c
M src/libosmo-mgcp/mgcp_protocol.c
M src/libosmo-mgcp/mgcp_vty.c
M tests/mgcp/mgcp_test.c
M tests/mgcp/mgcp_test.ok
8 files changed, 277 insertions(+), 237 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-mgw refs/changes/18/32218/2
--
To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/32218
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-Change-Id: I6c3291f825488e5d8ce136aeb18450156794aeb5
Gerrit-Change-Number: 32218
Gerrit-PatchSet: 2
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: newpatchset
Attention is currently required from: neels, fixeria.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32217 )
Change subject: bsc: add TC_mscpool_sccp_n_pcstate_attaches_msc
......................................................................
Patch Set 1:
(1 comment)
File bsc/BSC_Tests.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32217/comment/17a88740_f531…
PS1, Line 9190: pars1.mscpool.l3_info := valueof(ts_LU_REQ(LU_Type_IMSI_Attach, valueof(ts_MI_IMSI_LV('001010420000001'H)), '00F110'O));
> Gerrit used to highlight only specific parts being changed, but now this appears to be broken. […]
ok, so why is the IMSI being changed in this commit?
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32217
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Ib4a5330df30a73e744c316898817b2fa3271d75e
Gerrit-Change-Number: 32217
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 05 Apr 2023 12:12:34 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment