Re: [rtcweb] codec and connection negotiation

[Randell Jesup <[e-mail]>]

On 8/10/2011 8:33 AM, Paul Kyzivat wrote:

> On 8/10/11 3:27 AM, [e-mail] wrote:
>> The API itself is the critical piece. I’m not sure if there is any
>> benefit in tying it to SDP,
>
> Well, at the end of the day, an API must convey the critical data. It
> doesn't necessarily need to encode the data the same way it is encoded
> in SDP, and it doesn't need to convey that data for o/a in the same way
> that SIP does, but it does need to be able to represent the full range
> of SDP and the full semantics of o/a. And it needs to be flexible enough
> to do that as SDP evolves.

So: this theoretical format we're considering must:

a) be a superset of the functionality of SDP + o/a
b) be able to provide equivalent ability to future extensions of SDP + o/a
c) be reasonably straightforwardly convertible to/from SDP+o/a in order to
    make gatewaying feasible (this could involve only allowing a subset to
    be easily converted, at the cost of poorer gateway abilities and experience)
d) be completely vetted in time for the timeline for this spec

I can't see how anything other than either SDP+o/a or
alternate-serialization-of-SDP + o/a could meet those goals.  An alternate
serialization of SDP *might* allow for extended capabilities outside of the
ability for SDP to express (an escape valve, if you will).  I expect a
alternate serialization could be speced out in the timeframe.

Even if we decide to relax the "superset" and allow a subset of current SDP
functionality, defining that and making sure it handles the cases we want
would be tough even in a longer timeframe, unless we devise something very
simple but extensible, and live with reduced functionality in gateway
situations (and more complex gateways probably to cover) until such extensions
are done.




If someone has a real non-SDP proposal, get it on the the floor *NOW*.
Otherwise you're just waving your hands.


>> but certainly it should be possible to
>> implement SDP offer/answer protocol in Javascript on top of it. That
>> could be one requirement for it, and something that could be even proved
>> by a real implementation.
>
> Certainly a real implementation is a useful existence proof. But it is
> not a proof of completeness. Completeness will be accomplished by
> defining a full mapping between the API and SDP + o/a.
>
> *One* way to accomplish a complete mapping between the API and the SDP
> representation is to pass complete SDP in the API. Other ways are
> possible, but will be more work to define.

Exactly.

>
>      Thanks,
>      Paul
>
>> So, in summary: Avoid strict dependency to SDP, but it must be possible
>> to implement SDP offer/answer protocol on top of the standardized API.
>>
>> Markus

-- 
Randell Jesup
[e-mail]