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

[Roman Shpount <[e-mail]>]

On Thu, Oct 13, 2011 at 12:29 AM, Randell Jesup <[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.

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.
_____________
Roman Shpount