Project

General

Profile

Actions

Feature #6136

open

libosmo-mgcp-client should ignore unknown codecs in SDP

Added by neels 4 months ago. Updated 3 days ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
08/08/2023
Due date:
% Done:

0%

Spec Reference:

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

Related to OsmoMGW - Bug #6081: osmo-mgw fails to parse the semicolon separator in MGCP header like "L: a: GSM-EFR;GSM"Resolvedneels06/30/2023

Actions
Blocked by OsmoMGW - Bug #6293: osmo-mgw "decides" for a codec during MGCP handling; instead it should handle all configured payload type numbers as they arrive in RTPNew12/07/2023

Actions
Actions #1

Updated by neels 4 months ago

  • Related to Bug #6081: osmo-mgw fails to parse the semicolon separator in MGCP header like "L: a: GSM-EFR;GSM" added
Actions #2

Updated by laforge about 2 months ago

  • Assignee set to jolly
Actions #3

Updated by jolly 6 days 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.

Actions #4

Updated by neels 5 days 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.

Actions #5

Updated by neels 3 days ago

  • Blocked by Bug #6293: osmo-mgw "decides" for a codec during MGCP handling; instead it should handle all configured payload type numbers as they arrive in RTP added
Actions #6

Updated by neels 3 days ago

  • Status changed from In Progress to Stalled

we should resolve #6293 before working on this

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)