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

Paul Kyzivat <> Tue, 25 February 2014 22:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 928C91A02BF for <>; Tue, 25 Feb 2014 14:26:43 -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 oM1nE4_Fq_ak for <>; Tue, 25 Feb 2014 14:26:42 -0800 (PST)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:17]) by (Postfix) with ESMTP id D75191A0298 for <>; Tue, 25 Feb 2014 14:26:40 -0800 (PST)
Received: from ([]) by with comcast id Wdm41n0041YDfWL5AmSfPe; Tue, 25 Feb 2014 22:26:39 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id WmSf1n00e3ZTu2S3gmSfEv; Tue, 25 Feb 2014 22:26:39 +0000
Message-ID: <>
Date: Tue, 25 Feb 2014 17:26:39 -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
To: "Makaraju, Maridi Raju (Raju)" <>, "" <>
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=1393367199; bh=4sk0b6R8xCpQ3ESyGiDYXt6/w5R0wPm3Sj2DHymimuc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qRtMC26ja9DjCzv0F/XJuAalXkkVCEbtfB6YEaWNgRnfth42vd+hZrDnacNkz4DbQ xvE6Ekb48S0VrwMCszAjFeXcjVTen1xJGwg05v6JTs+cTzHf7c3HSBksG0hzvqijcv wSKnGjjW4bxYpGTXTQkHvFJkH5SOxPTYhG94nezzQPrh74BqhitzMDplRGvOCQi7Oo AgbH/xB8cvnjKjR/Uw07OJSPhdaNtt2hEqSs1a4SMo65Dlk2dUq7UfG/v1DVvKE3LX ETJ+wrHyfphPz9oOe2vpJ0PLERWX/6xD1qMy3vIUBvGYrELQXT+sh1RTWke1UyyfDI XgHW96FXZB0Wg==
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:26:43 -0000

On 2/25/14 12:54 PM, Makaraju, Maridi Raju (Raju) wrote:
> Hi Paul,
> Please see comments inline.
>> 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.
> [Raju] If I understand correctly, these parameters simply define the
> data channel transport properties. Yes, they may have some correletion with
> subprotocol, but that's not a one-to-one mapping.
> For example, a given subprotocol could run on a reliable or
> unreliable transport; depending on app needs it may use unreliable
> transport and deal with reliablity at subprotocol stack (or ignore it).

In some cases. But in general it is easy and common to define a protocol 
that needs a reliable transport, and it won't work without one.

What if every application in the world that uses TCP had the option to 
specify if it was reliable or not? How many would screw it up?

>> 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.
> [Raju] Right, this fits into my explanation above.
>> 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.
> [Raju] Good point. I like item 1 above; sure we can add it to this
> draft. Then individual subprotocol drafts
> (e.g. draft-ejzak-dispatch-msrp-data-channel-00) could get into the
> details of what that consistency is.