Bug #5726
openAMR octet-align in SDP: lack of 'octet-align' fmtp should imply octet-align=0, and the presence or absence of this fmtp should not have an effect
0%
Description
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.
Related issues
Updated by laforge over 1 year ago
While I'm not arguing your rationale, we really need to consider backwards compatibility. For us, the standard has historically always been octet-aligned, and we only added bandwidth-efficient later on. We can not expect that every user always runs all osmocom software from the same build/release, particularly RAN (BSC) and CN (MSC) often run on different platforms and follow different upgrade cycles.
Updated by keith over 1 year ago
I can think of quite some cases where it has happened that there is incompatibility between one component and another, and upgrading one requires upgrade of another1 I think it's even the case where we have a current incompatibilty between osmo-bsc/msc that requires a revert on master to make it work. See #5529
So It's hard to see how "all osmocom components must work with each other, regardless of versions" trumps fixing non compliant behaviour.
Now, interoperability with non-osmocom componets is a different story, but I guess that can be dealt with by some config flags for manufacturer or version, mgw-is-osmo, msc-is-releaseX, etc. Isn't GSM spec full of release indicators?
[1] This has mostly been MNCC or Pcu IF version bumps, and RSL bring-up sequence compatibilities, Not so much on the A i/f although the ticket I link to is actually A related.
