Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

[Martin Thomson <[e-mail]>]

On 4 October 2012 11:21, Christer Holmberg
<[e-mail]> wrote:
> I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.

Not my point.  My point is that the desired functionality (apply the
answer without invalidating the offer) cannot be easily provided using
SDP O/A.  Most scenarios leave the possibility that the offerer sends
the (provisional) answerer stuff that the answerer doesn't want.

> If you want to support parallel forking, you need to be able to simultanously perform ICE etc with all remote peers.

Right.  You can almost get that by pretending that it's just one
remote peer with lots of candidates.  You can at least get to the
consent point by doing that.  But you aren't going to nominate more
than one pair.  Similarly, this will only generate a single DTLS
session.

Media is a complete mess if you manage to get that far.  Unless you
like scenarios were A and hear B and C, but B and C can't hear each
other and other such joys (there's a consent issue too, but it's a
minor issue of scale).

>>Both of these complicate the API significantly.  I'd rather see the
>>complexity pushed to the applications that need this complexity.
>
> I want to be able to support forking. Exactly HOW it's done can be discussed.

One approach is to create as many RTCPeerConnection objects as you
feel might be needed.  Then it becomes YOUR problem, not our problem.
And those are the sorts of problem I like ;)  (I might be interested
in forking too, but I'm happy to keep my problems private.)

> Also, I can live without support of parallel forking, and I don't really care if serial forking support is provided using cloning or being able to update the remote descriptor (using PRANSWER, or something else).

Serial forking is potentially far easier to support by doing a series
of O/A exchanges:
10: setLocal(offer)
20: get next answer
30: setRemote(answer)
40: goto 10
There's the small matter of having no guarantee that the offer will
set successfully, but I'd consider that an unlikely scenario in
practice.

>>That is, unless you are willing to consider a better API that makes
>>these issues SEP.
>
> You have one in mind? ;)

I am not at liberty to disclose that information.