Cellular Network Infrastructure » OsmoMGW

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. */