Feature #6136
openlibosmo-mgcp-client should ignore unknown codecs in SDP
0%
Description
When mgcp_client receives an MGCP response that has an unknown codec in the SDP part, it aborts with an error.
Instead, it should simply ignore entries that are unknown, and carry on with other, known, codecs.
An error should occur only when none of the SDP codec entries is valid.
Related issues
Updated by jolly 5 months ago
- Status changed from New to In Progress
The test with MT call shows this on the SIP connector:
INVITE:
v=0 o=- 3910667610 3910667610 IN IP4 10.0.0.112 s=- c=IN IP4 10.0.0.112 t=0 0 m=audio 32768 RTP/AVP 96 3 a=rtpmap:96 FOO/8000 a=rtpmap:3 GSM/8000
200 OK:
v=0 o=Osmocom 0 0 IN IP4 10.0.0.16 s=GSM Call c=IN IP4 10.0.0.16 t=0 0 m=audio 4530 RTP/AVP 3 a=rtpmap:3 GSM/8000 a=sendrecv
The MGCP only transfers the GSM codec, so I guess that the MSC already filters the FOO codec.
Updated by neels 5 months ago
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.
