Pau Espin Pedrol | 637fc02 | 2019-07-19 18:02:33 +0200 | [diff] [blame] | 1 | include::{commondir}/chapters/osmux/osmux.adoc[] |
| 2 | |
| 3 | === Osmux Support in {program-name} |
| 4 | |
| 5 | ==== {program-name} in a A/IP with IPA/SCCPlite network setup |
| 6 | |
| 7 | In this kind of setup, the CN side of BSC co-located MGW is managed by the MSC, |
| 8 | meaning the use of Osmux is transparent to BSC since MSC takes care of both peer |
| 9 | MGW connections. Moreover, in this case the MSC has no dynamic information on |
| 10 | Osmux support in the BSC co-located MGW until `CRCX` time, which means |
| 11 | configuration on both nodes need to be carefully set up so they can work |
| 12 | together. |
| 13 | |
| 14 | Osmux usage in {program-name} in managed through the VTY command `osmux |
| 15 | (on|off|only)`. Since there's no dynamic information on Osmux support, it may be |
| 16 | required in the future to have an extra VTY command which can be set per BSC to |
| 17 | fine-tune which ones should use Osmux and which shouldn't. |
| 18 | |
| 19 | {program-name} will behave differently during call set up based on the VTY |
| 20 | command presented above: |
| 21 | |
| 22 | * `off`: {program-name} won't include an `X-Osmux` extension to `CRCX` sent to |
| 23 | the BSC co-located MGW when configuring the CN side of the MGW endpoint. If |
| 24 | the MGW answers with a `CRCX ACK` containing an `X-Osmux`, {program-name} will |
| 25 | cancel the call establishment. |
| 26 | * `on`: {program-name} will initially configure its co-located MGW to use Osmux, then |
| 27 | similarly send a `CRCX` with an `X-Osmux` extension towards the BSC co-located |
| 28 | MGW. Under this configuration, if the BSC co-located MGW didn't support Osmux, |
| 29 | it could send a `CRCX ACK` without `X-Osmux` extension or fail (depending on |
| 30 | its own configuration), and {program-name} could choose to re-create its local |
| 31 | connection as non-Osmux (RTP) (and possibly try again against BSC co-located |
| 32 | MGW), but this behavior is currently not implemented. As a result, currently |
| 33 | `on` behaves the same as `only`. |
| 34 | * `only`: {program-name} will configure its co-located MGW as well as the BSC |
| 35 | co-located MGW to use Osmux by including the `X-Osmux` MGCP extension. If MGW |
| 36 | rejects to use Osmux, {program-name} will reject the call and the call |
| 37 | establishment will fail. |
| 38 | |
| 39 | ==== {program-name} in a 3GPP AoIP network setup |
| 40 | |
| 41 | Osmux usage in {program-name} in managed through the VTY command `osmux |
| 42 | (on|off|only)`. Once enabled (`on` or `only`), {program-name} will start |
| 43 | appending the vendor specific _Osmux Support_ IE in _BSSMAP RESET_ and _BSSMAP |
| 44 | RESET-ACK_ message towards the BSC in order to announce it supports Osmux, and |
| 45 | BSC will do the same. This way, {program-name} can decide whether to use Osmux |
| 46 | or not based on this information when setting up a call (this time using _Osmux |
| 47 | CID_ IE). It should be noted that this option should not be enabled unless BSCs |
| 48 | managed by {program-name} support handling this extension IE (like OsmoBSC), |
| 49 | 3rd-party BSCs might otherwise refuse the related _RESET_/_RESET-ACK_ messages. |
| 50 | |
| 51 | {program-name} will behave differently during call set up based on the VTY |
| 52 | command presented above: |
| 53 | |
| 54 | * `off`: {program-name} won't use Osmux. That is, it will send a _BSSMAP Assign |
| 55 | Request_ without the _Osmux CID_ IE, and will send a `CRCX` without `X-Osmux` |
| 56 | extension towards its co-located MGW. |
| 57 | * `on`: If BSC announced Osmux support to {program-name} during _BSSMAP RESET_ |
| 58 | time, then {program-name} will set up the call to use Osmux (by adding |
| 59 | `X-Osmux` to MGCP `CRCX` and _Osmux CID_ IE to _BSSMAP Assign Request_). If |
| 60 | the BSC didn't announce Osmux support to {program-name}, then {program-name} |
| 61 | will use RTP to set up the call (by avoiding addition of previously described |
| 62 | bits). |
| 63 | * `only`: Same as per `on`, except that {program-name} will allow to set up only |
| 64 | Osmux calls on the CN-side, this is, it will reject to set up voice calls for |
| 65 | BSC which didn't announce Osmux support. |