osmo-mgw accepts CRCX without LocalConnectionOptions or with LCO without "a:" but fails to return media information
If a call agent sends a CRCX without LocalConnectionOptions (which is legal), or with LCO that contain no "a:" audio codec information, osmo-mgw will accept the CRCX, but the response will lack any audio information: There's no "m=" line in the SDP specifying the port.
If the call agent doesn't specify the codec, I think the MGW gets to pick and we should pick some sane default like PCM/8000/1 in that case and respond accordingly.
- Status changed from New to In Progress
- % Done changed from 0 to 10
The lack for port information is linked to the fact that the parser could not assign any codec. Since I am currently restructuring the codec handling in osmo-mgw I am on this as well. When no sdp and no LCO are included in a CRCX the MGW should pick a sane default, this makes sense.
I have now added the test case that sends a Non-LCO CRCX. With the current master we expect the test to fail.
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9479 MGCP_Test: Test non LCO crcx
- % Done changed from 80 to 90
osmo-mgw now can handle missing LCO. When there is an CRCX without a: option in LCO, PCMU is picked as default. However. I have to revisit the TTCN3 test for non lco. The problem here is that osmo-mgw now supresses IANA assigned codecs in rtpmap (unnecessary because already fully defined) this makes the test fail while the osmo-mgw response is completely legal.
The testcase for non-lco CRCX turned out to be to restrictive. The MGW now supresses unnecessary listing of media attributes, so our default "PCMU/8000/1" will not appear in the media attributes. We must change the check and see if the payload type number (0) appears in the media description.
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9691 MGCP_Test: ts_CRCX_no_lco: check media description instead of media attribute