From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] A few questions on
 draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzwgAIpVwCAAV9MgP//6QVg
Date: Wed, 26 Feb 2014 20:02:40 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1BCD34@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se>
 <CAJuyhsz4ZG_ReNEqmu+fTcSDfXxCnKWaVBhYvjf4XsWxSXB1mQ@mail.gmail.com>
 <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se>
 <CAJuyhsxz4X2aDNx2Y1Y2Gi9G0D12Ort95QFD=cQ6s-zM5GK9Uw@mail.gmail.com>
 <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se>
 <530D1C00.7080701@jesup.org> <530E42B1.4030500@alum.mit.edu>
In-Reply-To: <530E42B1.4030500@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gb2KHfOqssIjLjFvLvyqOvayVbY
Subject: Re: [rtcweb] A few questions on
 draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Precedence: list

Hi,

Let's also keep in mind that there has been suggestions to negotiate the ch=
annels using SDP, but in addition also use DCP (I assume that is what your =
DCEP abbreviation stands for :) to explicitly open the negotiated channels.

But, again, as long as JavaScript can access the information (stream id val=
ue etc), in order to add it to the SDP sent on the wire, and as long as the=
 usage of DCP is optional (it was earlier indicated that it IS optional) I =
don't think there should be any impacts on WebRTC.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 26 February 2014 21:38
To: rtcweb@ietf.org
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-c=
hannel-sdpneg-00

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 e=
ndpoint 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 end=
points that are using SIP for signaling.

We are still undecided on whether to use DCEP or SDP O/A to negotiate the c=
hannel we use. If we use DCEP it will be straightforward for a webrtc endpo=
int. But that is a little unnatural for the sip endpoints.=20
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 fe=
atures 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 e=
jzak 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=20
>> protocol characteristics. The protocol specification should define=20
>> re-transmission timers etc.
>>
>> Anyway, we can argue about it later. At this moment I think the focus=20
>> should be on whether to move forward with the mechanism to begin=20
>> with, and the main feature of the mechanism - which is about=20
>> negotiating usage of channels :)
>
> This (whether to move forward) is my concern (in addition to Mary's=20
> about this being the wrong group - MMUSIC is where the SDP should be=20
> and has been).
>
> The apparent justification for this document is "This document defines=20
> SDP-based out-of-band negotiation procedures to establish WebRTC data=20
> channels for transport of well-defined sub- protocols." This seems a=20
> pretty sparse justification.
>
> We very purposely avoided using SDP for channel setup (after MUCH=20
> discussion at Boston and elsewhere).  That isn't to say that for=20
> non-webrtc usage, one could define an SDP used to externally-negotiate=20
> the settings for DataChannels, which this appears to be.  But I think=20
> there should a clearer statement as to "why" we should invest the time=20
> to standardize this now, not just that we "can".  For example, if CLUE=20
> really wants to use this instead of in-band opens, then maybe there's=20
> 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=20
> certainly not here.  And I certainly don't want this to delay=20
> finalizing the stuff needed in MMUSIC for WebRTC use of DataChannels
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb