Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

[Paul Kyzivat <[e-mail]>]

Randell,

I agree that most of this discussion belongs elsewhere.
But there are a few bits that probably do belong here.

CLUE needs *something* that provides an e2e reliable channel. It could 
be a lot of things, e.g. TCP or TLS. We decided to go with the 
SCTP-based data channel that RTCWEB is defining so that we had the 
potential for a Webrtc endpoint to participate in CLUE without a gateway 
on the clue channel.

That means we will also be using the same stack between non-webrtc clue 
endpoints that are using SIP for signaling.

We are still undecided on whether to use DCEP or SDP O/A to negotiate 
the channel we use. If we use DCEP it will be straightforward for a 
webrtc endpoint. But that is a little unnatural for the sip endpoints. 
For them, the SDP O/A approach would be more natural.

It doesn't matter much if the *only* channel being used is the clue 
channel. It will start to matter if there is a desire to use other 
channels for features that can coexist with clue. E.g. BFCP. (But now we 
see a proposal to put BFCP over websocket, so maybe it won't ever be an 
issue for us.)

The important thing is that if clue decides to use SDP O/A for this, 
(the ejzak draft) then we must be confident that it will be feasible for 
a webrtc endpoint, via javascript, to participate in this negotiation 
and use it to set up the clue data channel. That is the part that 
belongs in rtcweb.

	Thanks,
	Paul

On 2/25/14 5:41 PM, Randell Jesup wrote:
> On 2/24/2014 10:21 AM, Christer Holmberg wrote:
>>
>> I still don't think the information belong to SDP - they define
>> protocol characteristics. The protocol specification should define
>> re-transmission timers etc.
>>
>> Anyway, we can argue about it later. At this moment I think the focus
>> should be on whether to move forward with the mechanism to begin with,
>> and the main feature of the mechanism - which is about negotiating
>> usage of channels :)
>
> This (whether to move forward) is my concern (in addition to Mary's
> about this being the wrong group - MMUSIC is where the SDP should be and
> has been).
>
> The apparent justification for this document is "This document defines
> SDP-based out-of-band negotiation procedures to establish WebRTC data
> channels for transport of well-defined sub- protocols." This seems a
> pretty sparse justification.
>
> We very purposely avoided using SDP for channel setup (after MUCH
> discussion at Boston and elsewhere).  That isn't to say that for
> non-webrtc usage, one could define an SDP used to externally-negotiate
> the settings for DataChannels, which this appears to be.  But I think
> there should a clearer statement as to "why" we should invest the time
> to standardize this now, not just that we "can".  For example, if CLUE
> really wants to use this instead of in-band opens, then maybe there's a
> reason to do so - but don't expect webrtc endpoints to implement this.
> And if so, it should be done in CLUE by request to MMUSIC.
>
> At this point I don't see need to move forward with this, and certainly
> not here.  And I certainly don't want this to delay finalizing the stuff
> needed in MMUSIC for WebRTC use of DataChannels
>