pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/29351 )
Change subject: doc: Document use of Osmux in IPA Abis against OsmoBTS
......................................................................
doc: Document use of Osmux in IPA Abis against OsmoBTS
Related: SYS#5987
Change-Id: I41788f8d3bc29735cc30516f429311b73ba71910
---
M doc/manuals/chapters/osmux_bsc.adoc
1 file changed, 47 insertions(+), 8 deletions(-)
Approvals:
laforge: Looks good to me, but someone else must approve
fixeria: Looks good to me, approved
Jenkins Builder: Verified
diff --git a/doc/manuals/chapters/osmux_bsc.adoc b/doc/manuals/chapters/osmux_bsc.adoc
index 0a11d17..268ffdf 100644
--- a/doc/manuals/chapters/osmux_bsc.adoc
+++ b/doc/manuals/chapters/osmux_bsc.adoc
@@ -14,14 +14,14 @@
==== {program-name} in a 3GPP AoIP network setup
Osmux usage in {program-name} in managed through the VTY command `osmux
-(on|off|only)`. Once enabled (`on` or `only`), {program-name} will start
-appending the vendor specific _Osmux Support_ IE in _BSSMAP RESET_ and _BSSMAP
-RESET-ACK_ message towards the MSC in order to announce it supports Osmux. This
-way, the MSC can decide whether to use Osmux or not based on this information
-when setting up a call (this time using _Osmux CID_ IE). It should be noted that
-this option should not be enabled unless MSC managing {program-name} supports
-handling this extension IE (like OsmoMSC), a 3rd-party MSC might otherwise
-refuse the related _RESET_/_RESET-ACK_ messages.
+(on|off|only)` under the `msc` node. Once enabled (`on` or `only`),
+{program-name} will start appending the vendor specific _Osmux Support_ IE in
+_BSSMAP RESET_ and _BSSMAP RESET-ACK_ message towards the MSC in order to
+announce it supports Osmux. This way, the MSC can decide whether to use Osmux or
+not based on this information when setting up a call (this time using _Osmux
+CID_ IE). It should be noted that this option should not be enabled unless MSC
+managing {program-name} supports handling this extension IE (like OsmoMSC), a
+3rd-party MSC might otherwise refuse the related _RESET_/_RESET-ACK_ messages.
{program-name} will behave differently during call set up based on the VTY
command presented above:
@@ -41,3 +41,42 @@
calls on the CN-side, this is, if _BSSMAP Assign Request_ from MSC doesn't
contain an _Osmux CID_ IE, it will reject the assignment and the call set up
will fail.
+
+==== Osmux in the ip.access Abis interface
+
+{program-name} can also talk Osmux instead of RTP to an OsmoBTS which supports
+the feature. Osmux usage agains the BTS in {program-name} in managed through the
+VTY command `osmux (on|off|only)` under the `bts` node.
+
+If a BTS supports Osmux, it may announce the _OSMUX_ BTS feature towards the BSC
+over OML. This way, the {program-name} becomes aware that this BTS supports
+using Osmux to transfer voice call user data when the AMR codec is selected.
+
+It is then up to {program-name} to decide whether to use Osmux or not when
+establishing a new call. If {program-name} decides to use Osmux for a given
+call, it will instruct its co-located MGW to set up an Osmux connection in the
+endpoint (using the `X-Osmux extension`) and then it will forward the received
+Osmux CID to the BTS in the the _IPACC CRCX/MDCX_ messages by means of an extra _Osmux
+CID_ IE appended to it.
+The IP address and port provided in the same messages refer to the
+address and port where Osmux frames with the provided CID are expected to be
+received. Similarly, the BTS appends an _Osmux CID_ IE to the _IPACC
+CRCX/MDCX ACK_ message it generates, this time with its own local Osmux CID,
+which {program-name} will in turn forward back to the co-located MGW.
+Same goes for the BTS' local IP address and port where Osmux frames are expected
+to be received.
+
+{program-name} will behave differently during call set up based on the VTY
+command `use (on|off|only)` under each `bts` node presented above:
+
+* `off`: {program-name} will never attempt use of Osmux against this BTS (default).
+* `on`: {program-name} will use Osmux against the BTS if the BTS announced Osmux
+ support during OML bringup, and if MGW provided a valid Osmux CID during _MGCP
+ CRCX_. Otherwise BSC will simply automatically fall back to using RTP for each
+ call. For non-AMR calls, RTP will always be used.
+* `only`: Same as per `on`, except that {program-name} will accept only Osmux
+ calls on the BTS-side. This is, if _MGCP CRCX ACK_ from MGW doesn't
+ contain an _Osmux CID_ IE or _IPACC CRCX ACK_ from BSC doesn't
+ contain an _Osmux CID_ IE, it will reject the assignment and the call set up
+ will fail. This means also that only AMR calls (`Channel Mode GSM3`) are
+ allowed.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/29351
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: I41788f8d3bc29735cc30516f429311b73ba71910
Gerrit-Change-Number: 29351
Gerrit-PatchSet: 2
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: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: merged
osmith has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ci/+/29359 )
Change subject: lint: ignore MACRO_WITH_FLOW_CONTROL
......................................................................
lint: ignore MACRO_WITH_FLOW_CONTROL
It seems that we don't care about this one, e.g. here:
https://gerrit.osmocom.org/c/osmo-msc/+/28848
Change-Id: I79da5a426db59031e3b16aecedeaa1498c91e847
---
M lint/checkpatch/checkpatch_osmo.sh
1 file changed, 2 insertions(+), 0 deletions(-)
Approvals:
Jenkins Builder: Verified
pespin: Looks good to me, but someone else must approve
fixeria: Looks good to me, but someone else must approve
osmith: Looks good to me, approved
diff --git a/lint/checkpatch/checkpatch_osmo.sh b/lint/checkpatch/checkpatch_osmo.sh
index b0c3985..7a60ad6 100755
--- a/lint/checkpatch/checkpatch_osmo.sh
+++ b/lint/checkpatch/checkpatch_osmo.sh
@@ -68,6 +68,7 @@
# * LINE_CONTINUATIONS: false positives
# * LINE_SPACING: we don't always put a blank line after declarations
# * LONG_LINE*: should be 120 chars, but exceptions are done often so don't fail here
+# * MACRO_WITH_FLOW_CONTROL: not followed
# * MISSING_SPACE: warns about breaking strings at space characters, not useful for long strings of hex chars
# * PREFER_DEFINED_ATTRIBUTE_MACRO: macros like __packed not defined in libosmocore
# * PREFER_FALLTHROUGH: pseudo keyword macro "fallthrough" is not defined in libosmocore
@@ -108,6 +109,7 @@
--ignore LONG_LINE \
--ignore LONG_LINE_COMMENT \
--ignore LONG_LINE_STRING \
+ --ignore MACRO_WITH_FLOW_CONTROL \
--ignore MISSING_SPACE \
--ignore PREFER_DEFINED_ATTRIBUTE_MACRO \
--ignore PREFER_FALLTHROUGH \
--
To view, visit https://gerrit.osmocom.org/c/osmo-ci/+/29359
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ci
Gerrit-Branch: master
Gerrit-Change-Id: I79da5a426db59031e3b16aecedeaa1498c91e847
Gerrit-Change-Number: 29359
Gerrit-PatchSet: 1
Gerrit-Owner: osmith <osmith(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>
Gerrit-CC: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: merged
Attention is currently required from: neels, laforge.
osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ci/+/29359 )
Change subject: lint: ignore MACRO_WITH_FLOW_CONTROL
......................................................................
Patch Set 1: Code-Review+2
(1 comment)
Patchset:
PS1:
> i have made one too, OSMO_NAME_C_IMPL(), but still i think it's ok to let the linter complain about […]
I think the linter is most useful if it only complains in clear cases of something done wrong, otherwise it becomes annoying for users IMHO. I see it complain about this and then getting overridden a lot, so therefore I think it makes sense to just ignore this check. Similar to how in theory we have a line limit of 120 characters in our coding guidelines, but also break that so often that automatically checking for it would be annoying.
--
To view, visit https://gerrit.osmocom.org/c/osmo-ci/+/29359
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ci
Gerrit-Branch: master
Gerrit-Change-Id: I79da5a426db59031e3b16aecedeaa1498c91e847
Gerrit-Change-Number: 29359
Gerrit-PatchSet: 1
Gerrit-Owner: osmith <osmith(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>
Gerrit-CC: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Mon, 19 Sep 2022 08:36:51 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: wbokslag.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-tetra/+/29387 )
Change subject: added support for fill bits and basic link defragmentation (also thanks to SQ5BPF)
......................................................................
Patch Set 3: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/osmo-tetra/+/29387
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-tetra
Gerrit-Branch: master
Gerrit-Change-Id: I41c9438b0b12c2fac9dff1b226eec5b33f30fbb4
Gerrit-Change-Number: 29387
Gerrit-PatchSet: 3
Gerrit-Owner: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: wbokslag <w.bokslag(a)midnightblue.nl>
Gerrit-Comment-Date: Sun, 18 Sep 2022 16:11:32 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment