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

Randell Jesup <> Tue, 25 February 2014 22:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B303C1A079D for <>; Tue, 25 Feb 2014 14:42:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LqNnVvMIvfKE for <>; Tue, 25 Feb 2014 14:42:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9431F1A0338 for <>; Tue, 25 Feb 2014 14:42:21 -0800 (PST)
Received: from ([]:1075 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from <>) id 1WIQhg-00042J-Iq for; Tue, 25 Feb 2014 16:42:20 -0600
Message-ID: <>
Date: Tue, 25 Feb 2014 17:41:04 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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:42:23 -0000

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