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

On 09/10/2012 07:22 PM, 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.
For each of these, I see three possible situations:

- The other side does not need to know. No need to represent them in 
SDP. For instance, I haven't seen a requirement to signal Opus 
complexity - at least not as far as I've followed the Codec WG.
- There is already a SDP mechanism to represent them. For instance, 
negotiating FEC parameters seems to be old hat; while I don't know what 
the recipient needs to know the estimated FEC error parameter for, if 
there is a need, it seems likely there is an SDP for it.
- The other side needs to know, and there is no SDP representation for it.

Which ones are in the last category?
>
> 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.
The SDP model is that you can send whatever you have negotiated. If you 
want different sets of parameters available all the time, you can 
negotiate different payload types for them.
What was the other use cases where you need to change parameters where 
the other side needs to know?
> _____________
> Roman Shpount
>

Received on Monday, 10 September 2012 18:11:24 UTC