Re: Need to expose RTCSocket object

For forking conditions, we can reuse the same RTCSocket object with two 
connections, each object becomes distinct but uses the same physical 
port and local ice information. Everything else is unique (and should 
be). So why is clone needed? I don't think it's desirable to auto-clone 
media track settings for example from one object to another.

> Martin Thomson <mailto:martin.thomson@skype.net>
> 3 September, 2013 1:17 PM
>
> [MT] I'd consider that a feature, not a bug.
>
> Iñaki Baz Castillo <mailto:ibc@aliax.net>
> 3 September, 2013 1:15 PM
>
> The problem above is that you must enter again the full list of media
> streams (and maybe customized settings per RTCTrack, along with DTMF
> stuff) in the second RTCConnection. That was the main purpose of the
> clone() method: to clone the RTCTrack instances within the connection.
>
>
> Martin Thomson <mailto:martin.thomson@gmail.com>
> 3 September, 2013 1:09 PM
>
> Not really - implementing this is massively complicated.
>
> The alternative is actually fairly straightforward:
>
> var conn = new RTCConnection(...);
> // ...send offers...
> // first answer
> conn.addRemoteCandidate(...);
> // second answer
> var conn2 = new RTCConnection(conn.localSocket, ...);
> conn2.addRemoteCandidate(...);
>
>
> It's not significantly different, or even much harder. Except that
> you don't have to worry about the state of the first connection.
> Describing what actually happens during the cloning process is
> non-trivial, and given how much we care to support forking (i.e., we
> shouldn't care if forking requires a huge amount of work), I think
> that this is the right balance.
>
> Cloning was a complete mess in WebRTC. This API is better, but it
> places far too heavy a burden on the browser implementation.
>
> Iñaki Baz Castillo <mailto:ibc@aliax.net>
> 2 September, 2013 4:44 AM
> 2013/9/2 Gustavo García<ggb@tokbox.com>:
>> I'm sorry but why do you need to retrieve it later with getLocalSocket?
>
> In the current approach, you get the local RTCSocket of a
> RTCConnection, and create a new RTCConnection with same local socket.
>
>
>> I'm not a big fan of supporting complex SIP forking scenarios in WebRTC, but if supporting them is a requirement it looks like if calling RTCConnection.clone() for each forking answer could be enough.
>
> That would be a simpler approach indeed. So:
>
>
> ---------------------------------------
> var conn = new RTCConnection(iceOptions);
>
> // first reply arrives:
>
> conn.connect(remote IceDescription)
>
> // second reply arrives:
>
> var conn2 = conn.clone();
> conn2.connect(remote IceDescription2)
> ---------------------------------------
>
>
> ok?
>
>
>
>
> Gustavo García <mailto:ggb@tokbox.com>
> 1 September, 2013 6:45 PM
> I'm sorry but why do you need to retrieve it later with getLocalSocket?
>
> I'm not a big fan of supporting complex SIP forking scenarios in 
> WebRTC, but if supporting them is a requirement it looks like if 
> calling RTCConnection.clone() for each forking answer could be enough.
>
> Regards,
>
>
>