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

Christer Holmberg <> Tue, 25 February 2014 22:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 098A71A033A for <>; Tue, 25 Feb 2014 14:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4kkr99CIMDJH for <>; Tue, 25 Feb 2014 14:59:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4D4621A0338 for <>; Tue, 25 Feb 2014 14:59:36 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-53-530d2056c7b5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id EB.34.23809.6502D035; Tue, 25 Feb 2014 23:59:34 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 23:59:33 +0100
From: Christer Holmberg <>
To: Christer Holmberg <>, Randell Jesup <>, "" <>
Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzwgAIpVwD//+vjwAAFQT74
Date: Tue, 25 Feb 2014 22:59:32 +0000
Message-ID: <>
References: <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvjW6YAm+wwdXVQhZnt2VZrP3Xzu7A 5LFkyU8mjw/L17EFMEVx2aSk5mSWpRbp2yVwZXRtX8dWcFi0Yu7BKYwNjPsFuxg5OSQETCQu 3d3BBmGLSVy4tx7I5uIQEjjEKPF3yX5GCGcJo8S738eBMhwcbAIWEt3/tEHiIgKtjBJXV0xm BekWFoiVONiylRHEFhGIk3j0YBs7hB0l0fUBIs4ioCpx+N0sMJtXwE1ibksDM8SCI8wSLedn sYIs4BTwk7i0JA6khhHoou+n1jCB2MwC4hK3nsxngrhUQGLJnvPMELaoxMvH/1ghanQkFuz+ xAZha0ssW/iaGWKXoMTJmU9YJjCKzEIyahaSlllIWmYhaVnAyLKKkT03MTMnvdxoEyMw5A9u +a26g/HOOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNzV/Jb7347a 3IcHz3940Sct7JB3avZta69ftTOj+pny1y8SuVRT/r20u51DIPhbo5NSgE+b68Vj253NSo6u 5Xx0abP4QsHZ+9k/7ndfY6H/TrypWVhkndbN/KMKAjKcMhH/F8g15WbJtwfOyN+0+u7W3/OU /h/YVPbnXtWWX1dmBn99VL/lvIkSS3FGoqEWc1FxIgDpzT0ORwIAAA==
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Feb 2014 22:59:40 -0000

Anyhow, I agree we should move this discussion elsewhere.



Sent from my Sony Ericsson Xperia arc S

Christer Holmberg <> wrote:

Hi Randell,

I am not sure whether an WebRTC endpoint (e.g. a browser) would have to implement this. The JS Application can insert the information into the SDP before sending it out on the wire (in cases where SDP is used on the wire).



-----Original Message-----
From: rtcweb [] On Behalf Of Randell Jesup
Sent: 26 February 2014 00:41
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

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

Randell Jesup -- rjesup a t mozilla d o t com

rtcweb mailing list

rtcweb mailing list