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

I think you missed my point. What I am trying to say is that there are a
number of parameters that needs to be specified which are not a part of
offer/answer exchange, and that there are a number of parameters that can
be changed without an offer/answer exchange. Current API is constraint in
such a way that you cannot specify first at all and cannot change second
without doing a complete offer/answer exchange with remote side that is not
needed.
_____________
Roman Shpount


On Mon, Sep 10, 2012 at 2:10 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

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


All of the parameters or situation I have described fall into category when
another side does not need to know. This is why there is no SDP
representation for it.

For things like FEC, all that SDP describes is that FEC content will be
supported when received. It does not specify if FEC content should be sent
and what level of redundancy is required. This is something that sending
side needs to decide for itself and typically is not negotiated. Same
applies to bandwidth, remote side can specify the range but it is up to the
sender to decide what bandwidth to actually use.


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

Once again, these for the cases where another side does not need to know.
For instance application decides that it needs to transmit higher quality
audio, so it decides to turn of VAD, increase audio bitrate, and/or select
different codec. Right now, the only way to do this is to generate new
offer, collect ICE candidates, send it to the remote side and select a
different codec from the remote side response list. I would prefer just do
it through API without going through offer/answer exchange. If remote side
indicated in the answer that codecs and bitrates are supported I should be
able to use any of them and switch from using one to another without going
through offer/answer.
_____________
Roman Shpount