Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt

"MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com> Wed, 06 March 2013 12:09 UTC

Return-Path: <jerome.marcon@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC28621F851E for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2013 04:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.878
X-Spam-Level:
X-Spam-Status: No, score=-9.878 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyjUO8mZItgP for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2013 04:09:38 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id E29A421F84C2 for <rtcweb@ietf.org>; Wed, 6 Mar 2013 04:09:32 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26C7vsX029294 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 13:09:21 +0100
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 13:08:55 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 6 Mar 2013 13:08:55 +0100
From: "MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqAgAFIbACAAaCdEP//+XgAgAAl0CA=
Date: Wed, 6 Mar 2013 12:08:54 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com>
In-Reply-To: <51371E4A.4040602@ericsson.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 06 Mar 2013 12:09:39 -0000

But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exists in this new draft version - I wonder how the peer can reject an incoming DATA_CHANNEL_OPEN message signaling a 'subprotocol' it does not support.

> -----Message d'origine-----
> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] 
> De la part de Salvatore Loreto
> Envoyé : mercredi 6 mars 2013 11:46
> À : rtcweb@ietf.org
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
> 
> On 3/6/13 11:40 AM, MARCON, JEROME (JEROME) wrote:
> >>> > >4. What happens if the SDP Opening Handshake agreed on some
> >> >data channels using the 'chat' subprotocol, and later on 
> an endpoint 
> >> >creates in-band a new channel with 'file transfer'
> >> >subprotocol ?
> >> >
> >> >When you create a channel, it sends Open on an unused Stream.
> >> >
> >> >
> > That does not answer to my question, so I reformulate: some 
> time after the initial SDP Opening Handshake, can the 
> DATA_CHANNEL_OPEN message create in-band a data channel with 
> a 'subprotocol' not negotiated by the initial SDP Opening Handshake ?
> >
> I do think it should be possible to do it in-band
> 
> However I agree with you that an important side question is 
> if/when that will be also signaled via SDP
> 
> /Salvatore
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>