tree dc0b405c401987182d2fae3df4762a415d0cf183
parent fa393fa1e9bd75047f48eeea42d20f8c61f8866b
author Neels Hofmeyr <nhofmeyr@sysmocom.de> 1713999302 +0200
committer Neels Hofmeyr <nhofmeyr@sysmocom.de> 1718374465 +0200

mgcp-client: always send 'm=audio' line

Re-add the m=audio line to SDP emitted from libosmo-mgcp-client, even if
the audio port is not set yet

Patch a5acaa68db4cc26e342069ad2ef37c1b09e1efc2 introduced a presence
flag for the RTP audio port number. This flag, when unset, also omitted
the 'm=audio...' line completely, dropping the PT number definitions.

Correct:

  m=audio 1234 RTP/AVP 96             <--- anounce 96
  a=rtpmap:96 VND.3GPP.IUFP/16000     <--- further specify 96
  a=fmtp:96 ...                       <--- further specify 96

When m=audio is missing, we only have orphaned rtpmap and fmtp entries.
They are supposed to further specify the 96 listed in 'RTP/AVP 96',
instead they are without context:

  a=rtpmap:96 VND.3GPP.IUFP/16000
  a=fmtp:96 ...

When the presence map indicates no port known, we still need to emit the
list of PT numbers; so we're forced to send a port of 0:

  m=audio 0 RTP/AVP 96
  a=rtpmap:96 VND.3GPP.IUFP/16000
  a=fmtp:96 ...

This is an important fix for osmo-hnbgw, which sends the first CRCX with
an IUFP codec, at a time when the remote port is not yet known. osmo-mgw
requires an m=audio line to accept incoming IuUP Initializaition
requests. When m=audio is missing, osmo-mgw does not parse the IUFP
codec, and 3G voice fails completely. This mgcp-client patch will emit
valid codec config also when port == 0, fixing osmo-hnbgw voice, because
osmo-mgw will know about IUFP from the start.

Related: SYS#6907 SYS#6974
Related: osmo-mgw a5acaa68db4cc26e342069ad2ef37c1b09e1efc2
Change-Id: Id95b629453aec999100b5af821c6a0b9562bb597