osmo-msc: Support instructing MSC_MGW to use Osmux between 2 endp/call-leg of same voice call
osmo-msc still doesn't support linking 2 internal leg calls through Osmux if both calls are using Osmux BSC<->MSC. Currently, RTP is always used between the 2 endpoints of the MGW.
So the complete path for the call is:
MS(a) --> BTS(a) --RTP--> BSC_MGW(a) --OSMUX--> MSC_MGW_ENDP(a) --RTP--> MSC_MGW_ENDP(b) --OSMUX--> BSC_MGW(b) --RTP--> BTS(b) --> MS(a)
Let's say we use an Osmux batch_factor=6.
Upon conversion RTP->OSMUX with 20ms per rtp packet, we have a 20*6=120ms delay added in BSC_MGW(a).
Later, upon conversion from OSMUX->RTP in MSC_MGW_ENDP(a), we unpack the first AMR apyload (1st RTP pkt) and send it immediatelly, then schedule the rest every 20ms each.
Then, RTP->OSMUX happens when 6th packet arrives at MSC_MGW_ENDP(b), we can finally re-construct the Osmux frame and forward it again (which means we add a 120ms delay again).
Finally, OSMUX->RTP happens in BSC_MGW(b) and schedules RTP packets accordingly.
So, as a summary, it means that if both call legs use Osmux, we add the delay twice, which we should really avoid.We need to do several things here:
- MSC: to instruct MGW to use Osmux on the uplink call leg if it detects that the other side of the call is local and the BSC it comes from announced it uses Osmux.
- MGW: Write code to do better at forwarding data if both conns in an endpoint are osmux-enabled. Currently we always convert osmux->rtp and then use the regular rtp-bridge code to forward packets. We should instead forward osmux frames, or simply forward extracted rtp packets but without scheduling them over time and simply push them all immediatelly.