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

Paul Kyzivat <> Tue, 25 February 2014 16:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CA8691A077A for <>; Tue, 25 Feb 2014 08:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i1tpsuJZxgNO for <>; Tue, 25 Feb 2014 08:56:53 -0800 (PST)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:32]) by (Postfix) with ESMTP id 6507D1A07CD for <>; Tue, 25 Feb 2014 08:56:53 -0800 (PST)
Received: from ([]) by with comcast id WbxF1n0050vyq2s53gwsFW; Tue, 25 Feb 2014 16:56:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id Wgws1n00B3ZTu2S3Rgwstm; Tue, 25 Feb 2014 16:56:52 +0000
Message-ID: <>
Date: Tue, 25 Feb 2014 11:56:52 -0500
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1393347412; bh=gqnBRLe4rG5PIW4/jXJvrQaNoiSqaHG0UMsKvjNPbmM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QdlcpZHyPiLqPlKLbZ4oF89khoXdKQj+uc1X6E/gS6AbHv5fm0ugQX7okPJY+6/MK uSE1lXQcBnDsvRgITpf0sNKfB/EdZDFY3fZJoe1X68ypcsQlz+6uuKjg6SgL9oQUrf GeNORDpsDnjHiEh49qWFTvXuRC8q+gEpbQ0H90vAlH/RhzLhEM5GZadfsegauw7MIB qHUqL0p28qVcOLACDLdTf/tPv8KrY/w+XvERb91QBjqlMNIPhR7T9EO3SmunF/bjHH SKQQfrBf+X6ER3VIxpJCA0IyZ7Vb7lOIy4c4uq9BDWO1zMvmR970h5gaQeIua25LR8 3X6VVK5ELqW6w==
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 16:56:55 -0000

Christer - comment at end

On 2/25/14 4:08 AM, Christer Holmberg wrote:
> Hi Raju,
>>> Anyway, can you give me an example of a case where you want to use
>>> SDP, and where you need to negotiate the re-transmission values etc?
>> [Raju] A simple example would be 2 browsers talking thru an intermedia proxy, which wants to know what protocols are
>> being negitiated and used as part of the session.
> Sure. I don't question the use-case/need for using SDP to negotiate channel usages.
>> 1. Calling client creates data channel (using with desired
>> attributes and sets negotiated=true. So, calling browser saves the attributes for the data channel but won't use DCP.
>> 2. These attributes are sent via SDP to peer client (via proxy).
>> 3. Peer client sets these same attributes while creating data channel and sets negotiated=true but won't do DCP.
>> 4. Peer client echo the same attributes back in SDP answer.
>> Now, data channel stacks on both ends will use same attributes, similar to DCP use case, with the only difference being DCP is not used here.
> My question was regarding the re-transmission values etc.
> Why do the peers need to negotiate those? Why would an intermediary need to know about those? Why not simply define those in the protocol description, and each endpoint supporting the protocol will then know what values to use?

IIUC, the webrtc people are "humoring* us by making provision for 
registered subprotocol names, and using SDP to negotiate channels. I 
suspect that for the most part they have no intention of using those. 
(The subprotocol name is *optional*.)

So these parameters are needed to properly initialize a channel when the 
subprotocol is not specified.

Also, we still have an open question about what attributes must be 
present in a subprotocol specification. It is at least possible that 
some subprotocols may work with a variety of settings of these attributes.

This draft should probably say more about this. It could say that:

* the SDP MUST be consistent with the attributes specified in the 
subprotocol definition, OR

* the SDP MUST NOT specify attributes specified in the subprotocol 
definition, OR

* attributes specified in the SDP override those specified in the 
subprotocol definition.