Re: [rtcweb] Alternative Proposal for Dynamic Codec Parameter Change (Was: Re: Resolution negotiation - a contribution)

[Harald Alvestrand <[e-mail]>]

On 04/24/2012 08:13 PM, Bernard Aboba wrote:
> Magnus' proposal for only using SDP to set the limits of behavior makes
> sense to me.  Clearly SDP is not potentially viable for rapid adjustment.
I would make that "potentially not viable" - if the RTT between clients 
and server is very low, and the server processing time is very short, 
there can be scenarios where sub-500-ms renegotiates are reasonable to 
expect even with server-mediated renegotiation, and there's always the 
potential of SDP exchange over a data channel, once that's commonly 
implemented. But it will be trivially easy for something to get 
implemented in a nonoptimal fashion, and for this to take quite a bit 
longer.
>
> The question is really about what information it is useful
> for a receiver or sender to provide.  For example, I would question
> whether an SVC sender necessarily needs to send a message saying
> it is adjusting its sending rate, assuming that the new rate is within
> the range negotiated.
>
> In any case, this really is not an RTCWEB-specific problem, and comimg
> up with different solutions in different IETF WGs seems highly 
> undesirable.
I would love to not invent mechanisms. All the mechanisms so far 
suggested have been previously proposed elsewhere, but only the 
m-line-level a=imageattr spec (RFC 6236) has been published as a 
standars-track RFC.