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

[Christer Holmberg <[e-mail]>]

Hi,

>> For the Web use case, I think PRANSWER is an unnecessary distraction; if
>> we're writing both initiator and responder, multiple O/A rounds, or use of
>> multiple PeerConnections, is a much cleaner solution for the use cases I can
>> wrap my head around.
>
> I'd remove that qualifier.  We currently have a draft that describes
> both cloning AND PRANSWER, both of which are more cleanly addressed by
> either multiple O/A rounds or multiple independent sessions.
>
>PRANSWER:
>The ability to describe a session that includes receipt capabilities
>that are a superset of send capabilities.  SDP O/A doesn't really
>provide a way for me to describe this because the default assumption
>is that items not appearing in the answer are no longer needed.
>With something like bundle involved, we could split m= lines into
>sendonly and recvonly portions to allow for this case to be provided.

I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.

>CLONING:
>The ability to use the same transport primitives to interact with
>multiple peers.  Ostensibly, this is to prepare for a session, with
>only one continuing to completion, mainly to reduce clipping.
>By adding candidates from all serial offenders to the same answer, you
>can get ICE setup, though I doubt that DTLS handshakes will be able to
>complete unless we permit multiple a=fingerprint lines and a few other
>things.  I'm still disinclined to support this feature.  Let the
>forkers have clipping.

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

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

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

>That is, unless you are willing to consider a better API that makes
>these issues SEP.

You have one in mind? ;)

Regards,

Christer