Re: More efficient RTP transport for CSD

Hi Mychaela. Brief thoughts on both this and your previous email (MGW for E1) I wasn't involved in CSD, haven't used it and probably never will, however, it's interesting you want to tackle this issue you identify. You mention that you want to mainly use the RBS gear for a production scenario. My experience was that the MO bring up procedures need work, as an RBS E1 BTS will; (1) not come up reliably with osmo-bsc (2) sometimes fail during operation, requiring intervention to restart. My apologies for scant description, I haven't looked at it in some time. Ah, there's a three year old ticket: https://osmocom.org/issues/5571 I did start some work on it, first off by implementing some vty commands to reset the BTS, with the intention of simply detecting and doing a full restart when not all the MOs come up, as it is, there's no way to recover without a full osmo-bsc restart, and as osmo-bsc may be (but does not have to be) controlling other BTS, this is not desirable. I had it in mind to have a go at this again, but as I neither own RBS hardware, nor have any work imperative to do it, I'm not sure when I might get around to it. A rather large problem, which currently makes the osmo-bsc + RBS not very usable for production, might want to be dealt with before CSD payloads. RE previous email, I think it's also interesting that you have your own MGW with what sounds like necessary improvements, I can't help feeling in a way that it is a shame this is not integrated into osmo-mgw instead of another program, but then I don't know what else you are dealing with that makes it easier to maintain your own MGW. Anyway, one can run a MGW for each BSC<->BTS combination right, so I suppose osmo and any other MGW can co exists. When I read your email before, I had intended to ask - along the same line of thought - Do you really need to write your own complete MSC, or what is it that has you "stuck" on osmo-msc from february 2023? k/