Re: [rtcweb] *MUST* DCEP?

[Paul Kyzivat <[e-mail]>]

IIUC rtcweb is predicated on the assumption that there is a single 
entity orchestrating the "system" including both of the endpoints of the 
sctp association. You therefore assume that you can a priori assume that 
both ends conform to your "systems document".

A sip endpoint doesn't have that. A major purpose of the signaling and 
the O/A exchange is to find out what we agree to. We won't know in 
advance if the other endpoint follows the CLUE "systems document".

ISTM that you are defining things so that we must use some mechanism to 
negotiate an application-specific agreement between the two ends about 
use of data channels *before* using any data channels.

With the ejzak draft we can use the O/A to negotiate a specific clue 
subprotocol, and then have a reasonable expectation that we can follow 
our own documentation of that protocol to go on.

Using DCEP would be more straightforward, especially for browser based 
endpoints. But if we can't even depend on support of DCEP when we have a 
data channel SCTP association, then DCEP is less useful.

	Thanks,
	Paul

On 3/4/14 11:17 AM, Ted Hardie wrote:
> On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Ted,
>
>     (I think this was open issue #8)
>
>     You closed discussion on this, saying that this should be specified
>     in some rtcweb "system" document. IIUC, then I disagree.
>
>     This is important to others besides rtcweb. We want to use this
>     mechanism, both with and without components that are implementing
>     rtcweb. Certainly for non-browsers.
>
>
> Help me understand why it wouldn't then be in their systems documents?
>
> Ted
>
>
>     This ultimately comes down to what I can expect after having
>     negotiated (in SDP) the establishment of an SCTP association. When
>     doing so, I use a=sctpmap to negotiate the how the association will
>     be used. If I intend to use data channels and DCEP then I want an
>     assurance that the other end does too. (That is the purpose of the
>     SDP negotiation.)
>
>     AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or
>     'a=sctp-datachannel' depending on where I look), that means the
>     other side supports data channels *and* guarantees support for DCEP.
>     There is no means to indicate support for data channels *without* DCEP.
>
>     I don't see any urgent need to have data channels without DCEP, as
>     long as *use* of DCEP is optional.
>
>     IMO things would be less confusing if the two documents were merged
>     into one, that defines the *Data Channel Protocol* (that runs over
>     SCTP). This protocol runs over pairs of SCTP streams, has a small
>     number of messages (open, ack, string-payload, binary-payload,
>     close), and encodes them in SCTP using SCTP messages with particular
>     payloads and SCTP stream reset. The open and ack messages would be
>     optional.
>
>              Thanks,
>              Paul
>
>