83 lines
4.5 KiB
Plaintext
83 lines
4.5 KiB
Plaintext
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.
|