On Thu, Dec 07, 2023 at 01:49:20PM +0100, Harald Welte wrote: > IMHO, the BSC and its colocated MGW should "hide" all the RAN-internal > details from the MSC. A MSC should never have to know anything specific > about each and every BTS, or even how many BTS there are.
so AMR oa/be mode should be: BTS <--whatever-bts-needs--> MGW@BSC <--fixed-as-in-3GPP-spec--> MGW@MSC > The AoIP interface is the only where the RTP format / codec types / > payload types are specified. We should always use what's specified in > TS 48.103. 3GPP TS 48.103 references TS 26.102, which says 10.2 AMR The bandwidth efficient mode of RFC 4867 [21] shall be used. CRC and robust sorting shall not be applied. So 3GPP says use octet-align=0 on the A-interface: BTS <--whatever-bts-needs--> MGW@BSC <--octet-align=0--> MGW@MSC In osmo-bsc, I read that all our BTS currently use octet-align=1. I also see osmo-bsc indicating octet-align=1 to the MGW, unconditionally. https://gitea.osmocom.org/cellular-infrastructure/osmo-bsc/src/commit/71f96f1b573639dacea3de744fc06e5988d324d6/src/osmo-bsc/lchan_rtp_fsm.c#L947 Then we want this: BTS <--octet-align=1--> MGW@BSC <--octet-align=0--> MGW@MSC Which means our 2G BTS use a different align than specified to be used on the A-interface in 3GPP. For AMR, we'd *always* convert each RTP packet between OA (BTS) and BE (CN) at osmo-bsc's MGW, once per call leg. So far, osmo-bsc indicates octet-align=1 to both sides, also the CN. Are you sure we should change that? In our osmocom world, it seems practical to instead agree on OA=1 from RAN up to osmo-msc, even though it does not match 3GPP TS 26.102: - OA=1 is the status quo of what osmo-bsc tells its MGW to pass to the CN. - We can do IuUP->AMR conversion directly as OA=1 (for 2G and 3G alike). - To PBX, there's no problem with flexible OA: if the PBX asks for octet-align=0, osmo-msc can forward that to osmo-mgw. osmo-mgw will then transcode to BE. I think, best to add VTY options in osmo-bsc and osmo-msc for which fixed AMR mode to use on the A-interface; Default would be current behavior: OA=1 on the A-interface. A user can then configure conform to 3GPP instead, if desired. Makes sense? ~N
