Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

[Harald Alvestrand <[e-mail]>]

On 05/02/2012 05:40 PM, Roman Shpount wrote:
>
> On Wed, May 2, 2012 at 9:35 AM, Harald Alvestrand 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Especially, I am worried about what the state of the
>     peerconnection has to be before it is cloned, what the state of
>     the peerconnection is after it is cloned, which peerconnection
>     owns the various resources allocated (ports are the obvious part
>     of it), and which peerconnection any streams (local or remote)
>     attached to the peerconnection before the clone are attached to
>     after the clone.
>
>
> I thought there was a discussion on this list about using the same set 
> of ports, ICE candidates and turn connection across multiple 
> peerconnections. I am actually curious if there is ever a down side of 
> using the same set of ICE candidates for all the streams within the 
> all peerconnections for a given web session. It should be possible to 
> disambiguate those streams based on remote IP/port and SSRC.
It does mean that the implementation will have to do reference counting 
to know when it can close the port - if one clones the socket and binds 
the clones to different remote ports, I think the OS will take care of 
it on Unix, I'm not sure how it goes for other OSes.

Does someone know what the semantic of bind() is here - whether one 
needs to have an unbound port to fork from in order to bind to different 
remote addresses? I've not tried this myself.

In the case of hardware codecs that must be allocated to a specific 
stream .... if one supports forking, which connection (if any) gets the 
codec? The first one to start using it? What happens to the second one?

>
> The state that must to be replicated with the peerconnection is the 
> latest offer information. It would probably be less disruptive if 
> peerconnection has some sort of clone method instead of using a 
> factory. It should be possible to clone the connection between the 
> time offer is generated and the final answer is received.
I kind of think it's less disruptive to the people who don't want to 
fork stuff if you must instantiate a different object in order to 
support forking. Then implementations that don't support forking can 
simply not offer a constructor for that object.