Actions
Bug #6081
closedosmo-mgw fails to parse the semicolon separator in MGCP header like "L: a: GSM-EFR;GSM"
Start date:
06/30/2023
Due date:
% Done:
100%
Spec Reference:
Description
Since recently, osmo-msc may send multiple codecs in an MGCP CRCX request, instead of just one.
osmo-mgw fails to handle that correctly.
e.g. if osmo-msc has both "GSM-EFR" and "GSM" available for CRCX, then:
- mgcp_client sends an MGCP CRCX with "L: a: GSM-EFR;GSM" according to spec.
It was always able to do so, just we never put more than one codec in it before.
- osmo-mgw receives it and fails to parse the ';' separation.
The result is a single entry in the codec map indicating "GSM-EFR;GSM".
osmo-mgw has the hubris to send this gibberish back in the CRCX OK message, in the SDP part.
- osmo-msc receives the CRCX OK with an unknown codec entry "GSM-EFR;GSM" (instead of two entries "GSM-EFR" and "GSM").
mgcp_client fails to parse it with errors like this:
20230629220457698 DLMGCP ERROR Failed to parse SDP parameter, can't parse codec in rtpmap: "a=rtpmap:96 AMR;AMR-WB" (mgcp_client.c:397) 20230629220457698 DLMGCP ERROR MGCP_CONN(RTP_TO_CN)[0x559e944dde10]{ST_CRCX_RESP}: MGW/CRCX: Cannot parse CRCX response (mgcp_client_fsm.c:291) 20230629220457698 DLMGCP ERROR MGW(mgw) Empty endpoint name, can not generate MGCP message (mgcp_client.c:1444)
Two points:
- libosmo-mgcp-client should probably rather be resilient against unknown codec types.
If one ptmap entry is unknown, we should just ignore it instead of aborting everything.
- osmo-mgw should properly parse the "L: a: ..." header according to RFC-2705, separating at semicolon.
Because we don't care much about that header, osmo-mgw could just stop at the semicolon and ignore any but the first codec.
See mgcp_protocol.c
case 'a': /* FIXME: LCO also supports the negotiation of more than one codec. * (e.g. a:PCMU;G726-32) But this implementation only supports a single * codec only. */
Files
Related issues
Actions