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

Christer Holmberg <> Mon, 24 February 2014 15:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6045D1A0104 for <>; Mon, 24 Feb 2014 07:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id neddLGGZep_y for <>; Mon, 24 Feb 2014 07:21:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 835EB1A0100 for <>; Mon, 24 Feb 2014 07:21:49 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-ef-530b638cb3af
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 0E.EF.04249.C836B035; Mon, 24 Feb 2014 16:21:48 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 16:21:48 +0100
From: Christer Holmberg <>
To: Richard Ejzak <>
Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw
Date: Mon, 24 Feb 2014 15:21:47 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvjW5PMnewwfpHChbPehtYLdb+a2d3 YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIO3nnMUnBbuuLU9zXsDYxzxLoYOTkkBEwk WpfdYIawxSQu3FvP1sXIxSEkcIRR4tzmFSwQzhJGienv5rN2MXJwsAlYSHT/0wZpEBHQltj2 8gELiM0soC5xZ/E5dhBbWCBWYvfR9YwQNXESjx5sY4ew3SS6/h4Aq2cRUJU427QazOYV8JWY 03MHavF8Jom5e9eA7eIUCJR4tCEXpIYR6Ljvp9YwQewSl/hw8DrU0QISS/ach7JFJV4+/scK YStJrD28Heo2PYkbU6ewQdjaEssWvmaG2CsocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGLk KE4tTspNNzLYxAiMkoNbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGMUuML6aeLo9kXtBlUR5o83jm4tu3DQX9og5baRXuf3bt8Rj537YTxQMNbYR3a8l vyRw3aJeo2f5qxlbNDZMiZD9P2m5usLGu20mv/QCRQPSfi4LL40xmfnCed65ggomoxUnfnHe eftFmdVhT8k3w+uRIi77eQ7uqGX7sYLNeWXZ5mg2Cd31nUosxRmJhlrMRcWJADYIs6dgAgAA
Cc: "" <>
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: Mon, 24 Feb 2014 15:21:56 -0000


>>>> Q2:
>>>> Would it be possible, for subprotocol values, use the same IANA registry/values as for the WebRTC Data Channel Protocol?
>>> This is really more a question for the data channel design itself.  A decision has been made to use the PPID for framing rather than protocol identification.  There is some discussion of this in another thread.
>> I am not talking about the PPID - I am talking about the Protocol field in the DATA_CHANNEL_OPEN message, which (afaik) specifies the same thing as the subprotocol parameter in your draft.
> This issue did come up in another thread, and the answer is yes.  It should probably be documented in the core data channel specs and just referenced here.

Good. Sorry if I missed the previous discussion on the topic.

>>>> Q3:
>>>> It would be good to clarify, if only one data channel is requested (or, even required), that the stream value must be the same in the Offer and Answer.
>>> I thought this also came up in an earlier thread and that it is documented (or should be documented) in the core data channel docs.  My understanding is that the stream id is always the same in both directions for a particular data channel.   
>> Correct. But, there should be an Offer/Answer procedure section in your draft, which shall say that the stream number must be the same. You can then reference to the data channel doc for justification.
> Since there is no disagreement over how it should work, we can clarify as necessary in a subsequent draft.

>>>> Q4:
>>>> I have issues with the max_retr, max_time and unordered parameters.
>>>> First, they seem to specify SENDING capabilities, rather than RECEIVING capabilities.
>>>> Second, they seem to describe characteristics associated with the subprotocol, in which case they could be specified in the associated subprotocol specification.
>>> This should be a topic for discussion in London.  As it is currently written, these parameters are of the "take it or leave it" variety, i.e., the answerer either accepts the options listed
>>> in the offer or rejects the data channel outright.  This is true for the in-band control protocol (please correct me if I am wrong on this), so we adopted the same approach for the
>>> SDP-negotiated case.  Some have suggested that we should allow more flexibility in negotiation of these parameters when using SDP.  If there is general agreement that it should be
>>> done this way, I see no problem with defining parameter negotiation rules for SDP in the next version of the draft.
>> The difference is that your draft is based on Offer/Answer, which is about indicating receiving capabilities (yes, I know we have broken that rule in the past).
> There are many examples of attributes that use different negotiation models than this.  The only requirement is that the semantics of the negotiation be defined in the document defining the attribute.

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 :)