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

right - and at one of the face to face meetings we agreed to add these to the API - I'm sure we can find my slides on this somewhere.

On Sep 10, 2012, at 11:22 , Roman Shpount wrote:

> 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
>

Received on Monday, 17 September 2012 22:26:03 UTC