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

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 25 February 2014 17:55 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 9248F1A013E for <rtcweb@ietfa.amsl.com>; Tue, 25 Feb 2014 09:55:04 -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 HTbiV-6JtK5E for <rtcweb@ietfa.amsl.com>; Tue, 25 Feb 2014 09:55:01 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CBECC1A017A for <rtcweb@ietf.org>; Tue, 25 Feb 2014 09:54:56 -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 s1PHsrSw022766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 11:54:54 -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 s1PHsrKa030474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 12:54:53 -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; Tue, 25 Feb 2014 12:54:53 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//sW+yX/9iL+AA==
Date: Tue, 25 Feb 2014 17:54:53 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFF7AFD@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <CAJuyhsz4ZG_ReNEqmu+fTcSDfXxCnKWaVBhYvjf4XsWxSXB1mQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <CAJuyhsxz4X2aDNx2Y1Y2Gi9G0D12Ort95QFD=cQ6s-zM5GK9Uw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFF58DB@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFF5D26@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se> <530CCB54.4000106@alum.mit.edu>
In-Reply-To: <530CCB54.4000106@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VXxg-u_x9dQavpk-o1mHH6Yfn1g
Subject: Re: [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: Tue, 25 Feb 2014 17:55:04 -0000

Hi Paul,

Please see comments inline.

> Christer - comment at end
> 
> On 2/25/14 4:08 AM, Christer Holmberg wrote:
> > Hi Raju,
> >
> >>> Anyway, can you give me an example of a case where you want to use
> >>> SDP, and where you need to negotiate the re-transmission values etc?
> >>
> >> [Raju] A simple example would be 2 browsers talking thru an intermedia
> proxy, which wants to know what protocols are
> >> being negitiated and used as part of the session.
> >
> > Sure. I don't question the use-case/need for using SDP to negotiate
> channel usages.
> >
> >> 1. Calling client creates data channel (using
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel)
> with desired
> >> attributes and sets negotiated=true. So, calling browser saves the
> attributes for the data channel but won't use DCP.
> >> 2. These attributes are sent via SDP to peer client (via proxy).
> >> 3. Peer client sets these same attributes while creating data channel and
> sets negotiated=true but won't do DCP.
> >> 4. Peer client echo the same attributes back in SDP answer.
> >>
> >> Now, data channel stacks on both ends will use same attributes, similar
> to DCP use case, with the only difference being DCP is not used here.
> >
> > My question was regarding the re-transmission values etc.
> >
> > Why do the peers need to negotiate those? Why would an intermediary need
> to know about those? Why not simply define those in the protocol
> description, and each endpoint supporting the protocol will then know what
> values to use?
> 
> IIUC, the webrtc people are "humoring* us by making provision for
> registered subprotocol names, and using SDP to negotiate channels. I
> suspect that for the most part they have no intention of using those.
> (The subprotocol name is *optional*.)
> 
> So these parameters are needed to properly initialize a channel when the
> subprotocol is not specified.

[Raju] If I understand correctly, these parameters simply define the 
data channel transport properties. Yes, they may have some correletion with 
subprotocol, but that's not a one-to-one mapping.
For example, a given subprotocol could run on a reliable or 
unreliable transport; depending on app needs it may use unreliable 
transport and deal with reliablity at subprotocol stack (or ignore it).

> 
> Also, we still have an open question about what attributes must be
> present in a subprotocol specification. It is at least possible that
> some subprotocols may work with a variety of settings of these attributes.

[Raju] Right, this fits into my explanation above.

> 
> This draft should probably say more about this. It could say that:
> 
> * the SDP MUST be consistent with the attributes specified in the
> subprotocol definition, OR
> 
> * the SDP MUST NOT specify attributes specified in the subprotocol
> definition, OR
> 
> * attributes specified in the SDP override those specified in the
> subprotocol definition.

[Raju] Good point. I like item 1 above; sure we can add it to this 
draft. Then individual subprotocol drafts 
(e.g. draft-ejzak-dispatch-msrp-data-channel-00) could get into the
details of what that consistency is.

Best Regards
Raju