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

Christer Holmberg <> Tue, 25 February 2014 17:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 21EDD1A0108 for <>; Tue, 25 Feb 2014 09:51:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1D6pwn9mZ_Pb for <>; Tue, 25 Feb 2014 09:51:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DF4AB1A013A for <>; Tue, 25 Feb 2014 09:51:38 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-a0-530cd8281639
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 91.5B.04853.928DC035; Tue, 25 Feb 2014 18:51:37 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 18:51:36 +0100
From: Christer Holmberg <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSND/9sNUAP/taKmw
Date: Tue, 25 Feb 2014 17:51:35 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja7mDZ5gg89/eC1WbDjAarH2Xzu7 A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxpWUWe8E0vopfSz6wNDAu5u5i5OSQEDCR eH5vBTOELSZx4d56ti5GLg4hgROMEn8PbWWBcJYwSnz/cQTI4eBgE7CQ6P6nDdIgIuAr0Xv5 HCOILSwQK7H76HpGiHicxKMH29gh7DyJFwengy1gEVCV+DrrKJjNC9Q7s2k71LLNrBL/JzQx gSQ4BXQktu8/DlbECHTR91NrwOLMAuISHw5eh7pUQGLJnvNQtqjEy8f/WCFsJYnGJU9YIep1 JBbs/sQGYWtLLFv4GmqxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbI4tbg4N93IQC83 PbdEL7UoM7m4OD9Przh1EyMwYg5u+W20g/HkHvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MFav079ftTbVaavsLZVrUlwCcXtldvY+v6R8mmP/brY6TaZP2ZaMprEC lm3fo/ue7btqWKb06/PqubZvpWOF1tzfsDFVbureZCauuQfFJkuyRYnuFKusm+J13Wk2ywqv 0uipF6RKTy6cvyPqysIlbtui8kX+PUnQvy78UaX/NMffD9GqN4+941diKc5INNRiLipOBACY bf7jZgIAAA==
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 17:51:44 -0000

Hi Paul,

>> 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.

Why would someone NOT specify the subprotocol?

Especially considering Richard's draft, I thought the whole idea was to be able to negotiate the subprotocol using SDP.

> 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.

Well, in that case the subprotocol specification should define the additional SDP attributes needed.

> 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.

If people see a need for these attributes, fine. But, I still have not seen an example where it would be needed (e.g. the UDP RFC does not specify the timers for SIP - RFC 3261 does :)