Some of the shortcoming of offer/answer + SDP based API

Now, since the group decided to proceed with offer/answer + SDP based API
there are couple of issues that I would like to point out:

1. Specification of non-negotiated parameters. Typically you have
non-negotiated (not described in SDP but specified through some sort of
local configuration or API) parameters on both per media stream and per
codec level. Examples of media stream parameters are enable/disable AGC and
AGC related parameters for both inbound and outbound directions,
enable/disable PLC and PLC related parameters, noise suppression and noise
suppression related parameters in both inbound and outbound
direction, using VAD and sending comfort noise, etc. Codec level
non-negotiated parameters include things like complexity for Opus, sending
FEC and estimated FEC error percentages, using in-codec PLC instead of
media stream PLC, etc. To support these parameters we need to provide a
side channel that almost matches in structure (m-lines, individual codec
parameters) SDP, but will not be part of SDP. These would be trivial if we
use a separate offer object that can be serialized into/parsed from SDP,
but will provide these additional parameters.

2. Changing media stream and codec related parameters without going through
offer/answer. It should be possible to choose a different codec to send the
media without going through offer/answer as long as this codec was
supported by the remote party. It should also be possible to enable/disable
VAD and CNG, change bitrate or change any of the non-negotiated parameter
(like enable noise suppression) without going through offer/answer.
_____________
Roman Shpount