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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 24 February 2014 13:18 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1721A0852 for <rtcweb@ietfa.amsl.com>; Mon, 24 Feb 2014 05:18:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzpqGqBBJdB6 for <rtcweb@ietfa.amsl.com>; Mon, 24 Feb 2014 05:18:33 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 285391A0471 for <rtcweb@ietf.org>; Mon, 24 Feb 2014 05:18:32 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-53-530b46a749ea
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 46.55.10875.7A64B035; Mon, 24 Feb 2014 14:18:32 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 14:18:29 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8A==
Date: Mon, 24 Feb 2014 13:18:29 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1B4DA3ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje4KN+5gg87N3BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr40T7YqaC5WYVjZuPsjQwzjDoYuTkkBAwkXi6bCkLhC0mceHe erYuRi4OIYFDjBLnTkxggnCWMEo87XkB5HBwsAlYSHT/0wZpEBFQl7j88AI7iC0sECBx4OIl doh4qMT7K/OZIGw9iaNP/7GC2CwCqhKb3n5jBLF5BXwlul+uBlvMCLT4+6k1YPXMAuISHw5e Z4Y4SEBiyZ7zULaoxMvHEHMkBJQk1h7ezgJRny/R/G8iE8RMQYmTM5+wTGAUmoVk1CwkZbOQ lEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjOy5iZk56eWGmxiBYX9wy2/dHYynzokc YpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OTy7d9uWUNz3Mc5k6b/MQy +vykCA/Rqtarr180vFDOYFEweX3m9fPD56UkD2m4PdvDyinjZRC7rOncv91vWi9sUlE74eOz ILf1XYhDdLNJtGswr6VCb6PEX/0p7b8KWFrMGj7aff3ItMPN4LyDk9CO6glrTa94/tvTbn6q mVP2MedXwSNxd5VYijMSDbWYi4oTAevZlwRJAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MRTpMEOFWPB9tgKf43IbuUxtnc4
Subject: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 13:18:36 -0000

Hi,

A few questions on  draft-ejzak-dispatch-webrtc-data-channel-sdpneg:

Q1:

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

Example:

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.


Q2:

Would it be possible, for subprotocol values, use the same IANA registry/values as for the WebRTC Data Channel Protocol?


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.


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.

Regards,

Christer