Re: [rtcweb] Data Channel Negotiation and reopening of decisions

[Martin Thomson <[e-mail]>]

I should probably collate responses.

On 14 February 2013 01:44, Randell Jesup <[e-mail]> wrote:
>> None of what I suggest would change the API.
>
> I think the no-negotiation proposal would require various API changes if you
> work out the details.

Sure, some changes, but nothing that would prevent channels from being
used interchangeably with websockets.  That is, once they are
established.

> I understand the wish to reduce code.  (You do realize we're running over a
> lightweight stack like SCTP over DTLS over ICE/TURN over UDP, right?  ;-)

Presumably you bought all those other parts of the stack.

> However, I'm not sure that you're actually reducing code by shifting to SDP
> (I think you're just moving the code/complexity, as the existing structures
> for negotiating m= lines can't be reused here I believe).  And I think the
> SDP+no-negotiation-open proposal ends up with yet more complexity (and
> importantly, more application (JS) complexity).

I was under the impression that the SDP code was already needed.  That
was the premise behind making the suggestion - if we're not using SDP
to negotiate channels ever, then I might be tempted to revise that.

> The least complex IMHO is the 0-RTT in-band option, though it's similar in
> complexity to the current "pure" inband (without accelerated call-start
> creation via SDP - i.e. 1.5RTT for all opens).

The least complex is to have the application just use channels with no
in-band messages at all.  But we can't do that because we need to have
messages tagged as being "binary" or "text" to further propagate the
mistake that the websockets design made.

> Partly my comments were aimed at all instances where we go back (and go back
> again) with progress being elusive, not just this one issue.

Yeah, I understand the frustration.  I used to get frustrated with
this sort of thing too.