doc: Document use of Osmux in IPA Abis against OsmoBTS
Related: SYS#5987 Change-Id: I41788f8d3bc29735cc30516f429311b73ba71910
This commit is contained in:
parent
57c2e68da2
commit
3dca75e1e2
|
@ -14,14 +14,14 @@ 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)`. 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 @@ command presented above:
|
|||
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.
|
||||
|
|
Loading…
Reference in New Issue