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

[Christer Holmberg <[e-mail]>]

Hi,

I thought that we had more or less agreed on the fact that, eventhough we would support forking, we would only support one "active" remote location - and typically that would be the location from where you got the previous answer.

So, if you receive an answer from R1, that becomes "active". Then, if you receive an answer from R2, that becomes "active".

Then, if you receive an UPDATE from R1, you would reject it, since R2 is "active".

...or, alternatively you could switch back to R1, and accept the UPDATE. That is implementation dependent, and nothing we need to specify.

Do people think that is not enough, and that we would need to support multiple remote locations simultanously (no matter whether it's implemented using cloning or something else)?

Regards,

Christer



________________________________
From: [e-mail] [[e-mail]] On Behalf Of Harald Alvestrand [[e-mail]]
Sent: Wednesday, May 02, 2012 6:54 PM
To: Roman Shpount
Cc: [e-mail]
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

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.