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

[Martin Thomson <[e-mail]>]

On 4 October 2012 09:57, Harald Alvestrand <[e-mail]> wrote:
> 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.

The two things that these provide is

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.

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.

Both of these complicate the API significantly.  I'd rather see the
complexity pushed to the applications that need this complexity.

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