Assertion or garbled audio in call using G.722.1

[nanang]

Scenario:

1. SDP offer G.722.1 multiple bitrates, e.g:

   a=rtpmap:118 G7221/16000
   a=fmtp:118 bitrate=24000
   a=rtpmap:119 G7221/16000
   a=fmtp:119 bitrate=32000
   

2. SDP answer specifies the second bitrate (from the offer), e.g:

   a=rtpmap:119 G7221/16000
   a=fmtp:119 bitrate=32000
   

The SDP negotiator seems to handle this already, i.e: it negotiates the bitrate in SDP fmtp too (instead of only matching the encoding name and the clock rate). But there are two problems:

1. as SDP answerer: as stream only matches encoding name, clock rate, and channel count, it may get wrong remote payload type so the remote will complain with wrong payload type in its received RTP packets.
2. as SDP offerer & answerer: as codec manager cannot differentiate G.722.1 based on the bitrate, the stream gets wrong G.722.1 codec parameters and open the codec using that wrong param, this leads to assertion or garbled audio.

Thanks to Brian Walker for the report.

[nanang]

In 4930:

Fix #1794: Fixed assertion or garbled audio in call using G.722.1:

• Updated stream info to use pjmedia_sdp_neg_fmt_match() for matching formats in SDP, so it will call codec specific match function, e.g: for G.722.1 it will match the bitrate too.
• Workaround for 'stream uses wrong codec param for opening G.722.1' issue, it is the G.722.1 codec that check the SDP fmtp for fetching bitrate setting (instead of using avg_bps/max_bps fields in codec param).

[nanang]

In 4931:

Re #1794: Also fixed pjmedia_codec_g7221_set_mode() not updating endpoint codec list after enabling/disabling a mode.

[nanang]

In 5058:

Re #1794:

• Updated G7221, the bitrate can also be set via param.info.avg_bps, this is applicable only when param.setting.dec_fmtp doesn't contain bitrate info.
• Fixed failing codec vector test in pjmedia-test due to wrong G7221 bitrate setting.