Change in ...osmo-msc[master]: doc: Add Osmux documentation to User Manual

pespin gerrit-no-reply at
Fri Jul 19 16:03:22 UTC 2019

pespin has uploaded this change for review. (

Change subject: doc: Add Osmux documentation to User Manual

doc: Add Osmux documentation to User Manual

Depends: osmo-gsm-manuals.git f3a734e6777a902abfb03257277454c7a879aeb7
Change-Id: I70c488c3d9b05599b834a8608e6361c8aa43ef31
A doc/manuals/chapters/osmux_msc.adoc
M doc/manuals/osmomsc-usermanual.adoc
2 files changed, 64 insertions(+), 1 deletion(-)

  git pull ssh:// refs/changes/41/14841/1

diff --git a/doc/manuals/chapters/osmux_msc.adoc b/doc/manuals/chapters/osmux_msc.adoc
new file mode 100644
index 0000000..1d22bba
--- /dev/null
+++ b/doc/manuals/chapters/osmux_msc.adoc
@@ -0,0 +1,62 @@
+=== Osmux Support in OsmoMSC
+==== OsmoMSC in a A/IP with IPA/SCCPlite network setup
+In this kind of setup, the CN side of BSC co-located MGW is managed by the MSC,
+meaning the use of Osmux is transparent to BSC since MSC takes care of both peer
+MGW connections. Moreover, in this case the MSC has no dynamic information on
+Osmux support in the BSC co-located MGW until `CRCX` time, which means
+configuration on both nodes need to be carefully set up so they can work
+Osmux usage in {program-name} in managed through the VTY command `osmux
+(on|off|only)`. Since there's no dynamic information on Osmux support, it may be
+required in the future to have an extra VTY command which can be set per BSC to
+fine-tune which ones should use Osmux and which shouldn't.
+{program-name} will behave differently during call set up based on the VTY
+command presented above:
+* `off`: {program-name} won't include an `X-Osmux` extension to `CRCX` sent to
+  the BSC co-located MGW when configuring the CN side of the MGW endpoint. If
+  the MGW answers with a `CRCX ACK` containing an `X-Osmux`, {program-name} will
+  cancel the call establishment.
+* `on`: {program-name} will initially configure its co-located MGW to use Osmux, then
+  similarly send a `CRCX` with an `X-Osmux` extension towrds the BSC co-located
+  MGW. Under this configuration, if the BSC co-located MGW didn't support Osmux,
+  it could send a `CRCX ACK` without `X-Osmux` extension or fail (depending on
+  its own configuration), and {program-name} could choose to re-create its local
+  connection as non-Osmux (RTP) (and possibly try again against BSC co-located
+  MGW), but this behavior is currently not implemented. As a result, currently
+  `on` behaves the same as `only`.
+* `only`: {program-name} will configure its co-located MGW as well as the BSC
+  co-located MGW to use Osmux by including the `X-Osmux` MGCP extension. If MGW
+  rejects to use Osmux, {program-name} will reject the call and the call
+  establishment will fail.
+==== OsmoMSC 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 _Osmux Support_ IE in _BSSMAP RESET_ and _BSSMAP RESET ACK_
+message towards the BSC in order to announce it supports Osmux, and BSC will do
+the same. 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).
+{program-name} will behave differently during call set up based on the VTY
+command presented above:
+* `off`: {program-name} won't use Osmux. That is, it will send a _BSSMAP Assign
+  Request_ without the _Osmux CID_ IE, and will send a `CRCX` without `X-Osmux`
+  extension towards its co-located MGW.
+* `on`: If BSC announced Osmux support to {program-name} during _BSSMAP RESET_
+  time, then {program-name} will set up the call to use Osmux (by adding
+  `X-Osmux` to MGCP `CRCX` and _Osmux CID_ IE to _BSSMAP Assign Request_). If
+  the BSC didn't announce Osmux support to {program-name}, then {program-name}
+  will use RTP to set up the call (by avoiding addition of previously described
+  bits).
+* `only`: Same as per `on`, except that {program-name} will allow to set up only
+  Osmux calls on the CN-side, this is, it will reject to set up voice calls for
+  BSC which didn't announce Osmux support.
diff --git a/doc/manuals/osmomsc-usermanual.adoc b/doc/manuals/osmomsc-usermanual.adoc
index 3c69d7b..d680a51 100644
--- a/doc/manuals/osmomsc-usermanual.adoc
+++ b/doc/manuals/osmomsc-usermanual.adoc
@@ -28,6 +28,8 @@
@@ -39,4 +41,3 @@

To view, visit
To unsubscribe, or for help writing mail filters, visit

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I70c488c3d9b05599b834a8608e6361c8aa43ef31
Gerrit-Change-Number: 14841
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin at>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gerrit-log mailing list