Change in osmo-bsc[master]: doc: Document use of Osmux in IPA Abis against OsmoBTS

pespin has uploaded this change for review. ( 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(-) git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/51/29351/1 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: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newchange