Re: [rtcweb] Minimal SDP negotiation mechanism

[Christer Holmberg <[e-mail]>]

Hi, 

>> In SIP it's possible to get two or more different answers back for 
>> one offer, due to forking.  I'm not sure you want/need to 
>> handle that 
>> case, but it can and does in-practice happen in SIP.
>> Whether we want the browser to support forking is one 
>> thing, and I guess it much depends on whether we want to be 
>> able to do things on the media plane during the early phase 
>> of a session establishment.
> I think we need to do all the transforms we need to do. It 
> would be great if there was a consistent set of things we are 
> required to be able to do.
> If a JS app wants to support forking, I think it's reasonable 
> to leave it to the JS which answer it wants to pass on to the 
> PeerConnection object. When we get multiple ANSWERs like 
> this, is there any information from the first ANSWER that 
> needs to be preserved after the second ANSWER has arrived? (I 
> really hope that the answer is a really clear NO...)

The answers as such are independent from each other, so from that perspective the answer is NO :)

The question is whether we want to allow actions to to take place on the media plane before we know which early dialog will be part of the established call.

For example, you won't be able to perform resource reservation procedures for multiple early dialog if the browser only deals with one early dialog at any given time.

>> But, at least the API needs to allow a JS SIP app to 
>> "replace" a previously received SDP with a new one (if the 
>> SIP app, in the forking case, for example chooses to always 
>> use the latest received SDP answer).
> We might get SIP compatibility if we decide that SDP ANSWER 
> can be received at any time, changes the state of the 
> connection, and never generates a response. SDP ANSWER is now 
> an one-way offer/answer.

Doesn't the browser still need to know with which offer the answer is associated?

Regards,

Christer