[[mgcp-extension-osmux]] === Osmux and MGCP `X-Osmux` indicates to OsmoMGW that a given connection of an `rtpbridge` endpoint has to be configured in order to handle Osmux frames instead of RTP messages on the data plane. ==== `X-Osmux` Format The value part of `X-Osmux` must be one integer in range [0..255], or alternatively only on request messages, an asterisk (*) if the value is not yet known. `X-Osmux` must be issued in the MGCP header section (typically as its last item), before the SDP section starts. `X-Osmux` can be included inside `CRCX` and `MDCX` request messages, as well as their respective response messages. In request messages, the value part of `X-Osmux` specifies the CID to be used by OsmoMGW to _send_ Osmux frames to the remote peer for that connection, also known as the MGW's _remote CID_ or the peer's _local CID_. In response messages, the value part of `X-Osmux` specifies the CID where OsmoMGW expect to _receive_ Osmux frames from the remote peer for that connection, also known as the MGW's _local CID_ or the peer's _remote CID_. .Example: `X-Osmux` format with a known CID 3. ---- X-Osmux: 3 ---- .Example: `X-Osmux` format with a wildcard (not yet known) CID. ---- X-Osmux: * ---- ==== `X-Osmux` Considerations If the MGCP client is willing to use Osmux for a given connection, it shall specify so during `CRCX` time, and not later. If at `CRCX` time the MGCP client doesn't yet know the MGW's _remote CID_, it can use an astersik (*) and provide _remote CID_ later within `MDCX` messages. All subsequent `MDCX` messages sent towards an Osmux connection must contain the original MGW's _remote CID_ sent during `CRCX`. The same way, all `MDCX` response shall contain the _local CID_ sent during `CRCX`. The other required connection address parameters, such as IP address, port, and codecs, are negotiated through MGCP and SDP as usual, but in this case the IP address and port specific the Osmux socket IP address and port to use, that together with the Osmux CID conform the entire tuple identifying a Osmux stream. Since Osmux only supports AMR codec payloads, the SDP must specify use of AMR codec. .Example: `CRCX` message that instructs OsmoMGW to create an Osmux connection ---- CRCX 189 rtpbridge/1@mgw MGCP 1.0 C: 36 M: sendrecv X-Osmux: 2 v=0 o=- 36 23 IN IP4 172.18.2.20 s=- c=IN IP4 1.2.3.4 t=0 0 m=audio 2342 RTP/AVP 112 a=fmtp:112 a=rtpmap:112 AMR/8000/1 a=ptime:20 ---- .Example: response to `CRCX` containing the MGW's _local CID_ ---- 200 189 OK I: 07E41584 X-Osmux: 2 Z: rtpbridge/1@mgw v=0 o=- foo 21 IN IP4 172.18.1.20 s=- c=IN IP4 172.18.1.20 t=0 0 m=audio 11002 RTP/AVP 112 a=rtpmap:112 AMR/8000 a=ptime:20 ---- ==== `X-Osmux` Support `X-Osmux` is known to be supported by OsmoMGW on the MGCP server side, and by OsmoBSC as well as OsmoMSC on the MGCP client side (through libosmo-mgcp-cli). No other programs supporting this feature are known or envisioned at the time of writing this document. In OmoMGW, Osmux support is managed through VTY. .Example: Sample config file section with Osmux configuration ---- mgcp ... osmux on <1> osmux bind-ip 172.18.1.20 <2> osmux port 1984 <3> osmux batch-factor 4 <4> osmux dummy on <5> ---- <1> Allow clients to set allocate Osmux connections in `rtpbridge` endpoints, while still allowing RTP connections <2> Bind the Osmux socket to the provided IP address <3> Bind the Osmux socket to the provided UDP port <4> Batch up to 4 RTP payloads of the same stream on each Osmux frame <5> Periodically send Osmux dummy frames, useful to punch a hole in NATs and maintain connections opened.