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.
#7 Updated by laforge over 1 year ago
- 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.
#8 Updated by laforge over 1 year ago
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.