include::{commondir}/chapters/osmux/osmux.adoc[]

=== Osmux Support in {program-name}

==== {program-name} in a A/IP with IPA/SCCPlite network setup

In this kind of setup, Osmux is transparent to {program-name} and no specific
configuration is required here, since the CN-side of the BSC-attached MGW is
managed directly by the MSC.

So, in this case, only MSC and MGW (both for MSC-attached one and BSC-attached
one) need to be configured explicitly.

==== {program-name} in a 3GPP AoIP network setup

Osmux usage in {program-name} in managed through the VTY command `osmux
(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:

* `off`: If _BSSMAP Assign Request_ from MSC contains _Osmux CID_ IE, meaning
  MSC wants to use Osmux for this call, then {program-name} will reject the
  assignment and the call set up will fail.
* `on`: BSC will support and accept both Osmux and non-Osmux (RTP) upon call set
  up. If _BSSMAP Assign Request_ from MSC contains _Osmux CID_ IE,
  {program-name} will instruct its MGW to set up an Osmux connection on the
  CN-side of the MGCP endpoint, and will provide the MSC with its _recvCID_
  through the extension IE _Osmux CID_ appended to the _BSSMAP Assign Complete_
  message. On the other hand, if _BSSMAP Assign Request_ doesn't contain an
  _Osmux CID_ IE, {program-name} will instruct its MGW to set up a regular RTP
  connection on the CN-side of the MGCP endpoint.
* `only`: Same as per `on`, except that {program-name} will accept only Osmux
  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.