Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

[Eric Rescorla <[e-mail]>]

On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <[e-mail]> wrote:

> On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla <[e-mail]> wrote:
>
>> On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <[e-mail]>wrote:
>>
>>> Camp #0:  I've used SDP for years and I'm very comfortable with it.
>>>  Using SDP as the control surface really helps my use case, which is legacy
>>> interop.  Defining an API without SDP would be too much work, and probably
>>> fail.  Look at what happened with SDPng!  Supporting all these advanced use
>>> cases doesn't seem worth it.   If developers are doing that much advanced
>>> stuff, they can learn to munge SDP.  It isn't that bad.
>>>
>>
>> Hmm... That's not my understanding of the situation at all.
>>
>> Rather, I believe the expectation is that you shouldn't have to modify the
>> SDP but rather there should be API points to cover most of the use cases
>> that people want. This isn't to say that all those API points exist or
>> that
>> they work or whatever.
>>
>> -Ekr
>>
>>
> I'm glad to be wrong here.  Is the phrase "you shouldn't have to modify
> the SDP but rather there should be API points to cover most of the use
> cases"  the consensus of the working group?
>

I thought it was, but I'm not the chair, so maybe you could ask Harald or
Stefan.


 Along with that, is "use Jingle for signalling" included in your set of
> "most of the use cases"?
>

No, I don't think it is, since it's not SDP.

Maybe I could phrase this differently: It was my understanding that you
should have
API points to get the PC to emit SDP that would express the policies,
preferences,
actions, etc. that the application wants. If you want something that's not
SDP you would
need to gateway.

This may or may not be a satisfactory state of affairs, but it was the rule
I was using
(based on what I thought the WG expected) for when use cases needed new API
points.

-Ekr