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

Christer Holmberg <> Mon, 24 February 2014 14:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B399F1A0874 for <>; Mon, 24 Feb 2014 06:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HwTYoolJB-mQ for <>; Mon, 24 Feb 2014 06:20:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5B3CB1A036A for <>; Mon, 24 Feb 2014 06:20:48 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-7a-530b553e5403
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 90.70.10875.E355B035; Mon, 24 Feb 2014 15:20:47 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 15:18:46 +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///uN6A=
Date: Mon, 24 Feb 2014 14:18:46 +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+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja59KHewwbspbBbPehtYLdb+a2d3 YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI+3NnHXrBVqqLl4TmmBsYW0S5GTg4JAROJ fX23GCFsMYkL99azdTFycQgJHGKUuHj0EhOEs4RRYsXRF+xdjBwcbAIWEt3/tEEaRAS0Jba9 fMACYjMLqEvcWXyOHcQWFoiV2H10PSNETZzEowfb2CFsK4mF7duZQMawCKhKnFxWAmLyCvhK NPR4Q2yawijx+/1dJpByToFAiWenjjCD2IxAt30/tYYJYpW4xIeD15khbhaQWLLnPJQtKvHy 8T9WCFtJYu3h7VCn6UncmDqFDcLWlli28DVYPa+AoMTJmU9YJjCKzUIydhaSlllIWmYhaVnA yLKKkT03MTMnvdxwEyMwQg5u+a27g/HUOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYEzcJ3RvspbHW7OkK6yWa50mm80+Ns/Q8UY/Z90Tm72PitlPf9S++CVcpCFD P6f87rfnt/OrLzooHtm+5nq2+pFjPrbl0d+df6WsujK/xrnm0TseqcmMyY8e1s30uHyhPWve iXM/prFmrPVeXMup7bBKc6F7SfGRn33H5/DV++4zmfU/82fSi1dKLMUZiYZazEXFiQAnCCxk XgIAAA==
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 14:20:51 -0000


>> Instead of defining a new SDP webrtc-DataChannel attribute, would it be possible to define the parameters as extension parameters to the SDP sctpmap attribute (yes, I know the ABNF currently does not allow that)?
>>          a=sctpmap:1000 webrtc-datachannel 1;stream=6;subprotocol="CLUE"
>> I am not saying this would be good or bad - at this point I just want to understand whether it would work.
> It might work, but you would still need a different mechanism to negotiate multiple data channels.  Why bother with two different formats when one will do?

I am sure the syntax could be defined so that you could define multiple channels. Or, you could use multiple sctpmap attributes.

Anyway, that is a syntax question, so we don't need to spend time on it now.
>> 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.

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

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