Re: [rtcweb] Minimal SDP negotiation mechanism

[Harald Alvestrand <[e-mail]>]

On 09/20/11 14:42, 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...)
> 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.
I get a steady increase in my uneasiness here. A PeerConnection should 
(in my opinion) be about the connection between the browser and a single 
other endpoint, and the media transmitted between those two. Once we 
start requiring that the PeerConnection know the difference between 
"early" media and "late" media, it seems to me we're slipping down a 
slippery slope.

 From the standpoint of PeerConnections, it may make sense to treat a 
forked call as two PeerConnections rather than one - but in that case, 
we may have the need to be able to create a PeerConnection from another 
PeerConnection (duplicating state, and maybe sharing resources, which is 
ugly).

Forking is hard, it seems.
>>> 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?
The browser (PeerConnection implementation) or the Javascript?

That's a question I don't have an answer to.

Is there any information in there where the browser would act 
differently if it knew which offer the answer was associatied to?

I went over the offer/answer with Per Kjellander today; if we follow RFC 
3264's recommendation of only having one outstanding offer at a time, we 
did not find any need to identify offers ("there can be only one") - if 
we can get into the situation where we get an answer after we've sent 
out a subsequent offer and gotten that answered, we may get a need for it.
> Regards,
>
> Christer
>
>