The point of this issue is not OsmoMSC, but OsmoMGW itself.
To test for this problem, then send the 'FOO' codec to osmo-mgw in an MGCP CRCX or MDCX.
You will see that osmo-mgw refuses the entire message (if I am right).
Instead, osmo-mgw should one of
- ignore the 'FOO' codec and set up all the others.
- drag along unknown codecs and also transport them back in the response (but
this is very hard with current osmo-mgw and also not practically useful
really)
So I concur that osmo-mgw should ignore unknown codec entries in the MGCP that osmo-mgw receives.
To put this in perspective, our current osmo-mgw clients are osmo-msc, osmo-bsc
and osmo-hnbgw. None of them will currently forward unknown codecs to osmo-mgw.
But osmo-mgw is an independent entity, and refusing all codecs because one of
them is unknown is bad code quality. That is the single reason why this issue
exists, and this is not at all about any practical osmocom CNI scenario.
Hence the issue remains open, but the priority of working on this is in fact low.
