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

[Christer Holmberg <[e-mail]>]

Hi,

>> 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.

I was thinking about the same once, but I think I found some issues (unfortunately they don't come to my mind at the moment).

But, it's for sure an alternative we could look into.

That would allow ICE to take place during the early session, but media might be more tricky - unless you also add the m- lines of each remote peer to the "pretended" single peer.

> 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.

Can I use the same local descriptor for every setLocal() call?

>>>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.

Can you then at least tell me when I'll be able to buy the Microsoft Surface? :)

Regards,

Christer