Cellular Network Infrastructure » OsmoMGW

OsmoMGW makes decisions for AMR octet-align vs bandwidth-efficient alignment depending on whether a fmtp parameter 'octet-align' is explicitly present or not.

IIUC the situation arises from the fact that until today, osmo-bsc and osmo-msc fail to set 'octet-align=1' in their MGCP.
It seems that osmo-mgw is trying to make amends for this error, that should instead be fixed in osmo-bsc and osmo-mgw.

In SDP, per spec, lack of the octet-align parameter must imply 'octet-align=0'. So if we now fix osmo-mgw to properly handle the 'octet-align' setting, we may suddenly break interworking with osmo-bsc and osmo-msc.

IIUC the intention is to convert between OA and BE only if the 'octet-align' parameter is explicitly present:

• "AMR" <-> "AMR": do not convert alignment
• "AMR:octet-align=0" <-> "AMR:octet-align=1": convert alignment

This seems like a good hack / legacy compat shim, but the effects are potentially catastrophic.
These are the problems:

• By allowing AMR OA on a conn where there is no fmtp configured, we are inviting confusion.
  For example, in the case "AMR" <-> "AMR:octet-align=1": do not convert alignment?
  Current code actually looks like we will only convert alignment in one direction, but not the other.

• the lack of a fmtp for AMR is, per spec, identical to having 'octet-align=0' present.
  By handling the presence or absence of the fmtp as an indicator to change osmo-mgw's behavior, we are not compliant.

• On each MGCP conn, there may be any number of different AMR configurations on either side.
  So depending on the PT number, we may receive / forward AMR OA or AMR BE interchangeably.
  For example, if osmo-msc forwards SDP from SIP that allows both OA and BE in two distinct payload type nrs,
  where OA has 'octet-align=1' and BE has no fmtp according to spec in the SDP from SIP,
  then osmo-mgw might interpret the AMR without fmtp as OA, even though it should be BE,
  and patch the wrong payload type number into outgoing RTP packets.
  (We could explicitly check whether both are featured, but that is another level of nightmare.)

So I think we need to reach a situation where osmo-mgw behaves strictly conforming to spec,
not assuming OA as compat behavior if there is no fmtp with the AMR codec.
We need to teach osmo-bsc and osmo-msc to appropriately send 'octet-align=1' in the MGCP,
and we should switch osmo-mgw to handle these instructions accurately.
Maybe we need switch osmo-mgw to strict AMR behavior with a .cfg VTY option.