Re: RTCSession object

I have as a TODO from the last meeting to propose something for freezing
and RTCP non-mux.  I have something in the works which is similar to this,
but different in the specifics. I hope to have it ready soon.
On Apr 24, 2014 8:21 PM, "Robin Raymond" <robin@hookflash.com> wrote:

>
> Pursuant to the last ORTC public meeting:
> https://docs.google.com/presentation/d/1ZP2bt_
> coR47Y3O2Mf003sD5n8mx8CLClhZs3YSX-E-Y/edit?usp=sharing
>
> Slide 23.
>
> I propose we should add the concept object "RTCSession".
>
> The object could be like this:
> [Constructor()]
> interface RTCSession {
>    static RTCSession defaultSession();
> };
>
> defaultSession - obtain a reference to the default RTC session object for
> the current web page [sandbox??]
> (^please, someone come up with a more refined definition)
>
>
> The idea is that you can construct objects without specifying the
> RTCSession object, as the default for the current web page session will be
> used.
>
> For example,
>
> var myTransport = new RTCIceTransport(myRole); can be used and the default
> web page "RTCSession" object would be used.
>
> But the session could be explicit so:
>
> var mySession = new RTCSession();
> var myAudioTransport = new RTCIceTransport(mySession, myRole);
> var myVideoTransport = new RTCIceTransport(mySession, myRole);
>
> ... would mean these RTCIceTransports are tied to a particular
> RTCIceTransport session distinct from the "default" or any other RTCSession
> created.
>
>
> This would resolve the "freezing" foundation problem as discussed in the
> ORTC meeting where implicit freezing rules could be done except we had no
> idea what RTCIceTransport objects were related to other RTCIceTransport
> objects vs RTCIceTransport objects that need their own private freezing
> relationships.
>
> I can see this RTCIceTransport being an optional constructor option for
> RTCIceTransport but perhaps we'll need it for other objects too in the
> future to group them together into a common session (or perhaps not).
> Bottom line though is the interface causes no additional programming pain
> for the simple use cases who can simply ignore this session option (and
> thus get the page default) but those who need to be precise with the
> freezing rules can use this RTCSession object to explicitly define
> RTCIceTransport relationships.
>
> Further, I believe maintaining compatibility shims with WebRTC 1.0 peer
> connection to make ensure groupings and freezing are respected will need
> some way to collect the RTCIceTransport object relationships together for
> the sake of freezing.
>
> On and I future propose we can use implicit freezing rules as a result of
> adding the "RTCSession" object as we discussed in the last ORTC meeting
> (i.e. freezing upon common "local" + "remote" foundations with the order of
> freezing dependency determined by RTCIceTransport object creation).
>
> -Robin
>
>
>