Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres
Christian Groves <Christian.Groves@nteczone.com> Mon, 17 February 2014 05:07 UTC
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7108B1A0358 for <clue@ietfa.amsl.com>; Sun, 16 Feb 2014 21:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.5
X-Spam-Level:
X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6] autolearn=no
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 fhPV5EGT4IYf for <clue@ietfa.amsl.com>; Sun, 16 Feb 2014 21:07:13 -0800 (PST)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230C91A0353 for <clue@ietf.org>; Sun, 16 Feb 2014 21:07:12 -0800 (PST)
Received: from ppp118-209-188-133.lns20.mel6.internode.on.net ([118.209.188.133]:56532 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Christian.Groves@nteczone.com>) id 1WFGNb-00050x-JX for clue@ietf.org; Mon, 17 Feb 2014 16:04:31 +1100
Message-ID: <530198FB.9000905@nteczone.com>
Date: Mon, 17 Feb 2014 16:07:07 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: clue@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <vd5x2knhr4rleweleq05w8po.1392599487052@email.android.com> <53016764.9050201@nteczone.com> <53018B68.2080209@alum.mit.edu>
In-Reply-To: <53018B68.2080209@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/oHPS7GNkNpcA0xUXLehxp57AhLE
Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2014 05:07:38 -0000
Hello Paul, On 17/02/2014 3:09 PM, Paul Kyzivat wrote: > On 2/16/14 8:35 PM, Christian Groves wrote: >> Hello Christer, >> >> Please see below. >> >> Regards, Christian >> >> On 17/02/2014 12:11 PM, Christer Holmberg wrote: >>> Hi, >>> >>> If the offerer offers a data channel, AND also some way indicates >>> support of CLUE, we can always specify that the offerer MUST be able >>> to use the data channel for CLUE. The WebRTC data channel protocol can >>> then be used to open the channel for CLUE. >> [CNG] I agree. >> >> I'm still uncomfortable with the way these drafts are layered. > > I'm troubled too, but maybe not exactly the same way you are. > IMO it isn't that the layering is so wrong. Rather it is that the > terminology used is confusing. [CNG] Yes the terminology isn't helping either. > >> The SCTP >> draft allows the specification of "app"s that relate to the SCTP >> association as a means of negotiating what goes in the SCTP association. >> One of those "app"s may be the webrtc data channel. It has its own means >> of negotiating of what is in the SCTP association (i.e. Richard's >> draft). > > I agree with your interpretation here. That doesn't mean the layering > is wrong - just the terminology. > > The use of a=sctpmap is clearly intended as an analog to a=rtpmap. But > in reality its purpose is not at all analogous to a=rtpmap. So the > name confuses. > > And that mis-analogy is continued, by language that says sctpmap is > defining a mapping from a port number to a payload format. Again, that > is not what it is doing. (If it were, then you would be restricted to > one payload format for all the streams on the association.) AFAICT, > the name you are giving in sctpmap describes some sort of "convention" > for how all the streams in the association are to be managed and used. > E.g., "webrtc-datachannel" says that the streams will be managed in > pairs, as channels, and that webrtc data channel protocol may be used > to dynamically assign channels. (That is the same conclusion you have > reached.) > > IMO a lot of the language should be changed to be less confusing. > >> Both these methods are basically just indicating what will be in >> the SCTP streams. > > Both? Which? The only thing that actually says, in SDP, what will be > in the individual SCTP streams is Richard's draft. [CNG] The SCTP draft does say which "apps" will be in the association. That what I mean by "what's in the streams" in the general sense. > >> Rather than have two methods for negotiating what is >> in the SCTP association it almost seems better to have one method for >> negotiation of what apps there are and then to tag whether or not the >> webrtc data channel will be used to open it. >> >> e.g. >> >> m=application 54111 SCTP/DTLS 54111 >> a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3; >> webrtc-datachannel-tag >> a=webrtc-datachannel:max-message-size=100000 streams=1 >> >> webrtc-datachannel-tag would take whether an "app" uses the webrtc data >> channel open protocol. >> a=webrtc-datachannel attribute would give the attributes of the >> protocol. > > There are problems with this - not for CLUE, but for webrtc, or > anything that doesn't want to use O/A to define every channel. > > The webrtc data channel open protocol does not take a stream ID as an > argument. It internally assigns stream IDs. Rtcweb has specified how > you can use preassigned channels without the open, but then it isn't > using the data channel protocol. [CNG] I just threw something together here without much thought. So for the case where the streamID isn't specified "data channel protocol" could be the value to indicate that it is used? > > IMO, from an mmusic perspective, we need to support both the static > and dynamic assignment of channels. We just want it to be done more > clearly. [CNG] Perhaps this is key, for a particular app in a SCTP association we need to say whether or not the streamID assignment is static or dynamic via the data channel protocol". > > From a CLUE perspective, we need to decide if we want to use the > static or dynamic assignment. IMO the preferred choice is not obvious > - both have their attractions. At the moment I am *slightly* > preferring the dynamic. [CNG] Dynamic is probably OK so long as we have some sort of label mechanism to help sort out mapping when you have multiple instances of the same app. > > Thanks, > Paul > >>> >>> But, never the less, it would probably be good to have an example >>> showing how things would look like using Richard's draft, until we've >>> decided whether we are going to use it or not. I'll add that. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Sony Ericsson Xperia arc S >>> >>> Christian Groves <Christian.Groves@nteczone.com> wrote: >>> >>> >>> Hello Christer, >>> >>> I think that for the signaling we must specify a way of negotiating at >>> the SDP level whether CLUE is supported. I agree there's lots of >>> ways it >>> could be done but we need to indicate which one/s CLUE should use. >>> >>> So for the SDP O/A procedures and example I think you have to assume >>> the >>> use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say >>> its a CLUE data channel according to the SDP given. You're just opening >>> a generic channel, which may or may not be clue. Particularly in the >>> Answerer's case, it doesn't know that the Offer is going to use the >>> channel for CLUE. >>> >>> However: >>> m=application 54111 SCTP/DTLS 54111 >>> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 >>> a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 >>> >>> would unambiguously define it as a CLUE data channel. >>> >>> Regards, Christian >>> >>> On 17/02/2014 11:16 AM, Christer Holmberg wrote: >>>> Hi Christian, >>>> >>>> If you want to negotiate usage of CLUE (or, any other specific usage >>>> of a webrtc-datachannel) in SDP, one option is to use Richard's >>>> draft. The usage of that draft is listed as an open issue in the CLUE >>>> data channel draft. >>>> >>>> SIP also provides other mechanisms, e.g. media feature tags, for >>>> indicating support of features. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> Sent from my Sony Ericsson Xperia arc S >>>> >>>> Christian Groves <Christian.Groves@nteczone.com> wrote: >>>> >>>> >>>> Hello Christer, >>>> >>>> With the use of webrtc-datachannel how do I negotiate via SDP >>>> whether I >>>> want to use clue or not? >>>> >>>> A SCTP association (and thus webrtc-datachannel) for example could be >>>> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >>>> association to figure out that the endpoints support >>>> webrtc-datachannel >>>> put don't support the application that you want. >>>> >>>> In the example in section 4.6 there's no way of distinguishing that >>>> description for CLUE vs BFCP vs anything else. Its not a CLUE data >>>> channel is a generic data channel. >>>> >>>> Regards, Christian >>>> >>>> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> The draft submission deadline has passed, but I still wrote some >>>>> more text, shown below, for the SDP Offer/Answer Procedures section. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> PS. Note that I will be on vacation next week, so I will once again >>>>> do my best trying to stay away from e-mails :) >>>>> >>>>> ----------------------- >>>>> >>>>> 4. SDP Offer/Answer Procedures >>>>> >>>>> 4.1. General >>>>> >>>>> This section describes how the SDP media description ("m=") >>>>> line for >>>>> a CLUE data channel is created, and how it is used in SDP >>>>> offers and >>>>> answers. >>>>> >>>>> NOTE: The proceudres associated with "m=" lines for other >>>>> media types >>>>> (e.g. audio and video) used in a CLUE session are outside the >>>>> scope >>>>> of this document. >>>>> >>>>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data >>>>> Channel >>>>> Negotiation mechanism >>>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>>>> will be used with the CLUE data channel. >>>>> >>>>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will >>>>> be used >>>>> with the CLUE data channel, a new associated 'sub-protocol' >>>>> value >>>>> needs to be registered with IANA. >>>>> >>>>> 4.2. SDP Media Description Fields >>>>> >>>>> The field values of the "m=" line for the CLUE data channel >>>>> are set >>>>> as following: >>>>> >>>>> >>>>> +----------------+----------------+------------------------+----------------+ >>>>> >>>>> >>>>> | media | port | >>>>> proto | fmt | >>>>> >>>>> +----------------+----------------+------------------------+----------------+ >>>>> >>>>> >>>>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP >>>>> port | >>>>> | | value >>>>> | | value | >>>>> >>>>> +----------------+----------------+------------------------+---------------+ >>>>> >>>>> >>>>> >>>>> Table 1: SDP "proto" field values >>>>> >>>>> 4.3. SDP sctpmap Attribute >>>>> >>>>> The field values of the SDP sctpmap attribute associated >>>>> with the >>>>> CLUE data channel "m=" are set as following: >>>>> >>>>> >>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>> >>>>> >>>>> | sctpmap-number | app | >>>>> max-message-size | stream | >>>>> >>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>> >>>>> >>>>> | fmt value of | "webrtc-datachannel" | >>>>> Implemenation | "1" | >>>>> | the "m=" line | | >>>>> specific | | >>>>> >>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>> >>>>> >>>>> >>>>> Table 2: SDP "proto" field values >>>>> >>>>> 4.4. SDP Offerer Procedures >>>>> >>>>> The procedures for the offerer follow the normal proceures >>>>> defined in >>>>> [ref-to-3264]. >>>>> >>>>> When the offerer creates an offer, which contains an "m=" line >>>>> for a >>>>> CLUE data channel, it assigns the field values to the "m=" line >>>>> according to the procedures in Section 4.2. In addition, the >>>>> offerer >>>>> MUST insert an SDP sctpmap attribute associated with the "m=" >>>>> line. >>>>> >>>>> In an offer, the offerer MUST NOT insert more than one "m=" >>>>> line for >>>>> a CLUE data channel. >>>>> >>>>> NOTE: CLUE does not support the usage of multiple CLUE data >>>>> channels. >>>>> >>>>> The offerer MUST NOT insert more than one SDP sctpmap >>>>> attributes in >>>>> an "m=" line for a CLUE data channel. >>>>> >>>>> If an offerer, in a subsequent offer, wants to disable the >>>>> CLUE data >>>>> channel, it assigns a zero port value to the "m=" line >>>>> associated >>>>> with the CLUE data channel. The answerer MUST NOT insert an >>>>> SDP >>>>> sctpmap attribute associated with the "m=" line. >>>>> >>>>> 4.5. SDP Answerer Procedures >>>>> >>>>> The procedures for the answerer follow the normal proceures >>>>> defined >>>>> in [ref-to-3264]. >>>>> >>>>> If the answerer receives an offer, which contains an "m=" line >>>>> for a >>>>> CLUE data channel, and the answerer accepts the "m=" line, it >>>>> creates >>>>> and inserts an "m=" line in the associated answer. The answerer >>>>> assigns the field values to the "m=" line according to the >>>>> procedures >>>>> in Section 4.2. >>>>> >>>>> If, in the offer, a zero port value has been assigned to the >>>>> "m=" >>>>> line for the CLUE channel, or it the answerer does not >>>>> accept the >>>>> "m=" line, but accepts other "m=" lines in the offer (i.e. the >>>>> answerer will not reject the whole offer), it still inserts an >>>>> "m=" >>>>> line for a CLUE data channel in the associated answer. The >>>>> answerer >>>>> then assigns a zero port value to the "m=" line. The answerer >>>>> MUST >>>>> NOT insert an SDP sctpmap attribute associated with the "m=" >>>>> line. >>>>> >>>>> 4.6. Example >>>>> >>>>> m=application 54111 SCTP/DTLS 54111 >>>>> a=sctpmap:54111 webrtc-datachannel >>>>> max-message-size=100000 streams=1 >>>>> >>>>> Figure 1: SDP Media Description for a CLUE data channel >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >
- [clue] CLUE Data Channel: SDP Offer/Answer Proceu… Christer Holmberg
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Christian Groves
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Christer Holmberg
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Christian Groves
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Christer Holmberg
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Christian Groves
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Paul Kyzivat
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Paul Kyzivat
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Paul Kyzivat
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Christian Groves
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Christer Holmberg
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Liuyan (Scarlett)
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Makaraju, Maridi Raju (Raju)
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Paul Kyzivat
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Paul Kyzivat
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Christian Groves
- Re: [clue] CLUE Data Channel: SDP Offer/Answer Pr… Paul Kyzivat