Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

[Harald Alvestrand <[e-mail]>]

On 10/15/2011 02:08 PM, Neil Stratford wrote:
> On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>     Remember that:
>     a) codecs are (currently) part of the platform, not of the
>     application.
>     b) one of our aims for negotiation is that if application X is
>     deployed in browsers A and B, and both browser A and B support a
>     "best codec" W that was created *after* X was last updated, then
>     the codec W should be used.
>
>     Given the last point - the app *cannot* "implicitly" what codec
>     will be used. And given that it doesn't know the codec, it can't
>     know the parameters either.
>
>     (that said... I'm all in favour of fewer parameters. The RTP
>     format for VP8 that we're in the process of finishing has zero
>     parameters. I hope it will remain that way.
>
>
> Can we work around this issue by delegating parameter negotiation to 
> the codec itself? Each codec in the codec capability list could 
> present (at a minimum) it's name, priority and a codec specific 
> parameter negotiation function. We can then delegate the complicated 
> codec specific details (when necessary) without needing any advance 
> knowledge in the javascript application. We would need to standardise 
> the parameter lists such that different codec implementations can 
> interop, but that is the same with SDP.
Yes, maybe we could do that. But would it make a difference?

SDP is (among other things) exactly such a parameter list 
standardisation, each and every codec deployed with RTP tends to publish 
a specification on how to encode those parameter lists in SDP, and each 
and every video engine implementing those codecs tends to have code in 
it that parses that SDP and does the negotiation on that basis.

Are we reinventing another encoding format for SDP again?