Bug #6297
Updated by neels 5 months ago
In rx_rtp(), we have a check that ensures the right AMR pack mode is arriving in incoming RTP packets.
Currently, the semantics are this:
- when there is no 'octet-align' fmtp at all, then don't check.
- for 'octet-align=[01]' fmtp present, verify correct AMR pack mode.
But RFC 6871 (SDP) specifies that if the 'octet-align' parameter is omitted, that means octet-align=0.
No spec conforming client out there will see a need to send an explicit 'octet-align=0', it will just omit 'octet-align=1'.
So osmo-mgw should not change its validation behavior based on the presence or absence of the fmtp;
It should assume a default of 0 when omitted.
Related: libosmo-mgcp-client currently has a problem that it can only pass the octet-align flag once per entire SDP body; there is a patch pending to fix it [1] and code has been in flux; meaning to say:
It seems that osmo-msc has been omitting the octet-align fmtp for a while now; and things worked out ok because absence of it disabled the AMR pack mode validity checks in osmo-mgw. For 2G-to-2G, both sides sent octet-align=1, and osmo-msc's mgw just forwards without checking. If we now enable this check in osmo-mgw when octet-align is absent, that would break 2G-to-2G calls and needs a fix of osmo-msc's fmtp.
But we can also not just ignore this further: when adding interop with 3G, now it is important to indicate the right pack mode, so IuUP-to-AMR conversion results in the right pack mode. In effect, omitting the octet-align fmtp now results in IuUP converted to AMR-octet-align=0, mismatching 2G. So we should really adopt the specified way of indicating octet-align and not imply anything else.
A solution could be to *not fail* when an unexpected pack mode arrives at osmo-mgw.
We can complain in the log, but then just convert it to whatever we expected.
In summary, I suggest to
* always enable the AMR pack mode checks, also when octet-align fmtp is omitted (mgcp_codec_amr_align_mode_is_indicated() == false).
* but when the checks indicate a mismatch, convert to what is needed implicitly and continue the call.
* a new vty option in osmo-mgw could switch the octet-align checks to be strict and fail instead of converting.
This way we get a concise spec conforming representation of octet-align fmtp in our SDP,
while at the same time not breaking 2G-2G calls for older osmo-msc that omit the "octet-align=1" by accident.
(I see that the current osmo-msc I am testing omits "octet-align=1" in MGCP to its MGW,
but haven't really checked for how long osmo-msc omits that fmtp; forever? since recently?)
[1] https://gerrit.osmocom.org/c/osmo-mgw/+/34900 -- libosmo-mgcp-client patch to fix fmtp
Back
