Document user plane handling with BSC+MSC co-located OsmoMGW, Osmux, and outlook
We need some kind of documentation on how the new, OsmoMGW-enabled user plane domain looks like. This includes the BSC-colocated OsmoMGW as well as the MSC-colocated OsmoMGW, as well as details on the use of MGCP between the respective call agents and MGW instances.Non-exhaustive list of topics to include:
- message sequence charts
- diagrams showing netwokr elemetns and control + user plane relationships
- dynamic endpoint allocation
- outlook on re-integrated support for E1 BTS
- name MGCP/MGW related config parameters in BSC and MSC config
- outlook on Osmux re-integration
- interaction between MNCC signaling and user plane at MSC
- outlook on IuUP
This is not really a user manual of a given single network element, but a document that describes the relation between the respective elements. Individual sections/chapters could possibly be reused/included into the BSC/MGW/MSC user manuals, but let's have a look at this after having a draft of that document.
Let's also make sure we use any existing bits and pieces from the osmo-mgw manuals (and the ladder diagrams I created there), as well as the wiki and possibly any not-yet-public ladder diagrams dexter might have created in recent months.
- treat each osmux connection (udp flows between two ip/port tuples) as a "trunk" like a classic TDM trunk, with up to 256 lines/slots/CIDs
- this means that such trunks have to be explicitly create e.g. by config file records (and not on the fly)
- this means that we basically have one MGCP endpoint per Osmux-trunk, and there's only one RTP connection on it (like E1)
- schema would be something like "osmux/1/23" for a trunk called "osmux/1" with endpoint(CID) "23"
- stay with dynamic endpoints without any fixed trunk (like current rtpbridge EP) and automatically create osmux_handles on the fly whenever the same src+dst ip/port tuples appear. Dynamically allocate CIDs within that Osmux connection
- this means there is no static configuration
- but it also means we somehow need to signal the CID as part of MGCP CRCX/MDCX
The first approach is of course much simpler to implement from a developer point of view. However, it puts the burden of static configuration to the sysadmin, and it is not able to dynamically/automatically establish osmux anywhere, similar to RTP.
Therefore I'm almost certain we want to go for option "2". We need to figure out how to map this to MGCP cleanly.
Approach "2" also seems to be more in-line with how Osmux was used so far in legacy osmo-bsc_mgcp and osmo-bsc_nat (which I'm not particualrly familiar with myself). An "X-Osmux: CID" MGCP extension appears to be used. I'm not convinced if this doesn't actually belong into the SDP, where also the port numbers are located. Let's brainstorm some more about this.