Re: Dealing with isolation state mismatches

On 2014-05-15 11:01, Harald Alvestrand wrote:
> On 05/15/2014 07:21 AM, Martin Thomson wrote:
>> This is probably best handled in a room, but here goes.
>>
>> A has isolated streams because it thinks it's making a "private" call.
>>    (Scare quotes intentional.)
>>
>> B has regular streams.
>>
>> A and B try to establish a call.  Nothing in the signaling they are
>> using (SDP, woo!) indicates that they are screwed.  The browser runs
>> the O/A exchange and it seems OK, until the DTLS session blows up.
>>
>> Do we want a signal in SDP for this state?  I think that it would be
>> nice.  We can put a wee attributey thing on the a=identity line.
>>
>> Sorry, scratch that, we can request that the RTCWEB working group
>> consider this as a new requirement on their signaling work.
>>
>
> I'm not sure I quite get the "isolated" property's properties here.
>
> When it was initially proposed, I thought it was intended for:
>
> A runs a Javascript app X
> A wants his media to end up only with B, not anyone else X wants to send
> it to
> X marks the streams as "isolated", A checks that this is true (oops, UI
> needed), and is happy

This is the key point to me. The only UI we have is the gUM one. That is 
the opportunity when the UA can tell the user ("A") that "media can't be 
recorded, and only be sent to B".

So the logic for me becomes that B's app cannot record, or forward the 
media (of course this can only work if B is using a conforming UA) - so 
we would need to carry those properties over in some way.

This is a "I trust the UA, I trust myself, I trust B, but I distrust the 
app (my app and B's app)" case.

Received on Thursday, 15 May 2014 09:52:50 UTC