Bug #6297
openoctet-align=0 is the RFC 6871 specified default to use when omitted; but osmo-mgw assumes don't-care when omitted
0%
Description
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.
- 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
Related issues
Updated by neels 5 months ago
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 thought a bit more, and two "autodetections" are needed to support legacy osmo-msc:
I was explaining that current osmo-msc omits the octet-align=X fmtp.
If we implement autodetection of the packing format and convert, a fixed osmo-mgw would convert to octet-align=0 when fmtp is omitted.
So we also need to autodetect what packing format we should send to the peer.
- From the first AMR/RTP packet received from a peer, autodetect the AMR packing mode that we will then later send to that peer with that PT nr.
- Autodetect packing of each incoming AMR/RTP and convert to the packing format that the peer expects, per PT nr.
The 'octet-align=' fmtp would still be relevant towards SIP, to negotiate interop with call agents.
But within osmocom, we could still save the call even if fmtp for AMR were completely wrong in the SDP.
and assume that users upgrading osmo-mgw will also be ready to upgrade their osmo-msc at the same time.
- Before the change, osmo-mgw had a blind eye on omitted 'octet-align', and osmo-msc was free to omit 'octet-align'.
- After the change, osmo-msc sends the correct 'octet-align', and osmo-mgw is strict about it.
(related osmo-msc fix: https://gerrit.osmocom.org/c/osmo-msc/+/35307 )
Updated by neels 5 months ago
also related: https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/XRP6RYE4BUOF52DCMF7BWDQR32F2UQWN/
discussion about what octet-align to use on the A-interface: specs say octet-align=0, while our de-facto standard in 2G is octet-align=1.
Quoting:
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.Agreed, thanks.
