Re: [rtcweb] Minimal SDP negotiation mechanism

[Harald Alvestrand <[e-mail]>]

On 09/20/11 14:08, Christer Holmberg wrote:
> 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...)
> 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.