Re: Moving forward with SDP control

On Fri, Jul 19, 2013 at 2:48 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>
>     That doesn't matter. Think of OOP "encapsulation". The API defines a
> contract. It is well within its right to declare SDP as an undefined/opaque
> token outside the scope of the API. Anyone who relies upon its contents is
> relying on implementation details that will change over time and break
> their application. They have no one to blame but themselves.
>
>
Perhaps that could be true if this were purely WebRTC browser-to-browser,
but it's not.  The SDP put into the setRemoteDescription can come from
anywhere, not just another WebRTC browser.  For example, it could come from
a legacy device, a mobile app, a gateway server, or an application server
written by the same developer writing the JS.  And at that point, how much
does it matter if the SDP came from a server written by the developer or JS
written by the developer?


>     A lower-level API can then step in to manipulate the SDP, but this
> remains an implementation detail for Application Developers.
>
> Gili
>
>
> On 19/07/2013 5:28 PM, Peter Thatcher wrote:
>
> You're right that you don't have to choose the key, and you don't have
> look at it if don't want to.  But, it's still given to you, and you still
> have to transport it to the remote side.  No matter how buried it is in an
> opaque blog, it's still in there.
> On Jul 19, 2013 2:02 PM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:
>
>>  Hi Peter,
>>
>>     It sounds like I'm missing something. As a web developer, I have
>> haven't had to choose a SDES crypto key in order to initiate video chat.
>> The underlying WebRTC implementation might have done so and I passed this
>> opaque blob (SDP) over the wire, but I never had to touch it myself.
>>
>>     So what am I missing here?
>>
>> Thanks,
>> Gili
>>
>> On 19/07/2013 3:45 PM, Peter Thatcher wrote:
>>
>> On Fri, Jul 19, 2013 at 10:55 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>
>>>  Hi Peter,
>>>
>>>     That's not necessarily true.
>>>
>>>    - The only reason the user is exposed to this information in the
>>>    first place is because the specification declared the bootstrap process out
>>>    the scope.
>>>     - Assuming we accept this design decision, we still don't have to
>>>    give users access to the internals. The specification can declare this blob
>>>    as an off-limits opaque token that MUST NOT be modified by the user.
>>>
>>>     The only reason the user is currently exposed to implementation
>>> details is that the Signaling layer and Application API have been packed
>>> into a single structure: SDP. If we separate these two, there would be no
>>> need to expose internals to the end-user.
>>>
>>
>>  Then how does the SDES crypto key chosen by one side get to the other
>> side?  You can say it's not modifyable, but it's still readable, unless the
>> signalling is done over a channel that the JS has no access to or control
>> over.
>>
>>>   Gili
>>>
>>>
>>> On 19/07/2013 1:31 PM, Peter Thatcher wrote:
>>>
>>> Everything that needs to be signalled needs to be available to the JS
>>> because it's up the JS to signal it.  For example, if SDES is used, crypto
>>> keys must be available to the JS because its up to the JS to send it to the
>>> remote side.  There's no way for you to signal it without having access to
>>> it.
>>>
>>>
>>> On Fri, Jul 19, 2013 at 9:49 AM, piranna@gmail.com <piranna@gmail.com>wrote:
>>>
>>>> >     That is not strictly true. Any immutable low-level property
>>>> should be hidden from the application developer. Meaning, as an application
>>>> developer I don't care that the signaling layer is using encryption key
>>>> "9823cuj980ru890e" and yet (I think) this shows up in the SDP. If I don't
>>>> ever need to know about it, I shouldn't have access to it.
>>>> >
>>>>  +1
>>>
>>>
>>>
>>>
>>
>>
>