IETF Logo Mail Archive

Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN?

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Thu, 06 February 2014 20:00 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 DA5701A0518 for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 12:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 vp68y6_YDQEo for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 12:00:38 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 694A71A04F8 for <rtcweb@ietf.org>; Thu, 6 Feb 2014 12:00:31 -0800 (PST)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s16K0NWx013158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 14:00:23 -0600 (CST)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s16K0MxO030882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:00:22 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 15:00:22 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>
Thread-Topic: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN?
Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKv//80KA///u5jCAABV0AP//7Huw//GCr+D/4wMwcP/GAokw/4wAYID/F/v1AP4v9dVQ/F95A/A=
Date: Thu, 06 Feb 2014 20:00:21 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFD199B@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <A21E0980-2F38-4156-AE03-8C5D80FE74F0@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D144004@ESESSMB209.ericsson.se> <4B7CB104-BD52-4392-A0B5-4F5C187AA001@ericsson.com> <9E34D50A21D1D1489134B4D770CE0397680AB034@SZXEMA504-MBX.china.huawei.com> <E1FE4C082A89A246A11D7F32A95A17826DFCF772@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D15F323@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFCF8DA@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D15FC31@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFCF9D5@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D15FD97@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15FD97@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN?
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: Thu, 06 Feb 2014 20:00:40 -0000

> Is there a reason why we couldn't mandate usage of the same id in the core
> spec? Then the correlation would not be dependent on the negotiation
> mechanism(s).

[Raju] WebRTC does not provide any rules for external negotiation of data channels, so it should leave all the procedures, including stream id management, outside the scope. Having "symmetric stream id" restriction puts unnecessary hurdle on external negotiation procedures, which adds no value overall. Like an example app may not care which data channel/stream-id is used for send or receive, it just wants to know data is received and sent (the data itself may have some identification info).
 
Btw, the SDP based external negotiation draft http://tools.ietf.org/id/draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt is already proposing to use symmetric stream ids. Other external negotiation protocols may put such restriction as they fit.

-Raju

v2.23.0 | Report a Bug | By Email