Re: Need to expose RTCSocket object

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,

On 30/08/2013, at 15:54, Iñaki Baz Castillo wrote:

> We could define that RTCConnection constructor does not require mandatory RTCSocket argument and instead creates a new one which can be later retrieved via getLocalSocket(). But we need something to clone the loaded streams into a connection and share same local port, otherwise how to implement forking?
> 
> BTW I do know that clone() requires more love and specification details, but IMHO is, at least, a way to go for getting forking. We are open to any other aproach anyhow.
> 
> Regards.
> 
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> 
> El 31/08/2013 00:04, "Martin Thomson" <martin.thomson@skype.net> escribió:
> Because clone() is insufficient, complex and hard to reason about.  Clone() is currently underspecified, but if it is similar to the proposal made long back for JSEP, it's a partial clone of state, replicating only the local sockets and none of the additional state already accumulated (including remote candidates and any connection state).
> 
> I've argued in the past that clone() should be removed.
> 
> RTCSocket is invisible if you don't care for those complex use cases.
> 
> > -----Original Message-----
> > From: Gustavo García [mailto:ggb@tokbox.com]
> > Sent: Thursday, 29 August, 2013 2:14
> > To: public-orca@w3.org
> > Subject: Need to expose RTCSocket object
> >
> > Could somebody explain why do we need to expose RTCSocket in the public
> > API "for serial and parallel media forking"?  Could we expose clone method
> > but keep RTCSocket as an internal implementation detail?
> >
> > I'm probably missing something.  Thank you for the info, G.
> >
> >
> >
> 
>

Received on Sunday, 1 September 2013 22:46:06 UTC