Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

[Randell Jesup <[e-mail]>]

On 10/13/2011 12:48 AM, Roman Shpount wrote:
>
> On Thu, Oct 13, 2011 at 12:29 AM, Randell Jesup <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     It did cover that case - it was up to the app what to do when the
>     first ACCEPT was processed.  I didn't go into the JS-level
>     mechanisms used.
>
>
> I guess I might be missing something, but how, using ACCEPT, RTC can
> generate a single offer, get two answers back, and create two media
> streams? Creating a second media stream does not mean that this is a
> last answer for this stream (corresponds to new SIP dialog created by
> provisional response) and accepting a stream does not mean it cannot be
> cloned (corresponds to new SIP dialog created by new final response). So
> essentially we need four operations: create offer, create media stream
> based on an answer, update existing stream based on a new answer for the
> same dialog, and finalize the media stream. Or alternatively we can
> achieve the same with create offer and stream together, process answer,
> accept (finalize the stream) and clone the stream. Either way we need
> four methods and we achieve the same functionality.

I'm not sure we're actually disagreeing here - I'll dig out my original 
message.

>     Do not assume that remote IP == source - this is easily provably
>     false, though if you used remote IP+port AND local IP+port I think
>     it would be ok.  However, for each remote connection we should have
>     a DTLS connection instance, so that's probably simplest.
>
>
> Yes, I do agree we should disambiguate on local/remote IP+port pair. I
> did not realize we are requiring DTLS/SRTP in RTC. I don't think I've
> seen a single implementation of this in the wild, and I do not see any
> harm in supporting SRTP and (with user confirmation) of plain RTP.

Yes, allowing any non-encrypted connection is controversial currently. 
DTLS for the PeerConnection and any data channels, and DTLS-SRTP for the 
media channels.  See ekr's security spec.  As for implementations, that 
should not be a problem.  Plain SRTP with SDES I consider more 
problematic, since it inherently exposes the keys to the un-trusted app 
and server.


-- 
Randell Jesup
[e-mail]