Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Justin Uberti <juberti@google.com> Thu, 31 October 2013 00:23 UTC
Return-Path: <juberti@google.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 DDA5321F9FE9 for <rtcweb@ietfa.amsl.com>; Wed, 30 Oct 2013 17:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.634
X-Spam-Level:
X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
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 susVrHWTsbTq for <rtcweb@ietfa.amsl.com>; Wed, 30 Oct 2013 17:23:29 -0700 (PDT)
Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B881011E82DF for <rtcweb@ietf.org>; Wed, 30 Oct 2013 17:23:26 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id 11so1421122vbe.17 for <rtcweb@ietf.org>; Wed, 30 Oct 2013 17:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UuNq3QO/lpOhwsYA4bAII/e4SU+batEm2pn8rlaKf6k=; b=VMdBCDYiEjcuT0EIn51zj4++dcZqLNAjcLn7ofqt0KSEU840V9vnvqznwZ/0CcTatA ozqGfnC+1DrZaYZGkIG844tS1icYl8yD436/Mph2KaFGAtY44mIx5LagCJrraUSS2JWQ BewiDfbJMKqd+5z5SQYa8Iyv1mN439MRuEDjPb+hTeOJ3v5268kPf84WwToAlD7rtBF4 gOnqGAKmNyxw+ic/YgP+bMOiNGigXvnbIDeYdeeCZ2Z26bTQSKJpo3Tt+ihQB9ObT3Fn Caticd0VM0t8RhH8v6mHovI8PjO5J5pLs4emo37YYKZ3F14oFwbkTQSC+SVkkpCmgncz JbdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UuNq3QO/lpOhwsYA4bAII/e4SU+batEm2pn8rlaKf6k=; b=EfgfeKFIFQ18MITh4MRgoWpD94fn+XAwgL1iPlG3kUG0DA4LYSPLBpcJ7GuYmcTE/V iqqj1EYlIEGomWZiKcTezbMt7Y2j4WfyMoq0NgnNVgg8jvlF6aUtPZG9y7bSIQCS/B0/ 3tyM74owG84MiYV2/WlDpoQRurvZt8K+/Z9MhF+URU+81WsbWehfevH9M/zzQhlLxBZ6 X9Fvk6BBIAQ4vh59tP0YrEmjv71VuFUjkVQjx1pUDlmWxjcPz71GgyuyPiaOE3c7ll2Z 0KYMXuI7uMvoe51g8dKWJeAkzVVf1aS7SVrKq2Nle17YwrpN+r+L6lKJchBanMB4ICwh koTg==
X-Gm-Message-State: ALoCoQkco7lzNDbswmZ5z6MNjLk73mg4nuGMo30VdPR1PsoJUQdYt4eUAWZQ3DEYu2ofDPjjhvOfW6sgYh+oVKTPsR+jzjw58zoAqYqly1ytIr6OxbUnxEi8BwPFe40kGCifT2BMBb/zKfEusCTb0hdP3X+jYak5sCyg+2Vhstpr/g0D28QRMScxh74oDtkWS/UhAKD7K2x9
X-Received: by 10.58.238.9 with SMTP id vg9mr131042vec.43.1383179006101; Wed, 30 Oct 2013 17:23:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Wed, 30 Oct 2013 17:23:05 -0700 (PDT)
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86DB71@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com> <A87B4291-FA11-43BB-B8F0-55C59CF63421@lurchi.franken.de> <CAOJ7v-20YkvazNLqmbjQcOkhaedd+MKm8d6x2oeL46imvuLrzA@mail.gmail.com> <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com> <526F3D5A.9010205@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D2BB@US70UWXCHMBA04.zam.alcatel-lucent.com> <52707155.8090003@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86DB71@US70UWXCHMBA04.zam.alcatel-lucent.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 30 Oct 2013 17:23:05 -0700
Message-ID: <CAOJ7v-3KXYBqxi6UBNx13xnf50kvnYNs+CR1xNKy1cbeRV3F6Q@mail.gmail.com>
To: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="047d7bd7578251e5b304e9fe75ce"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.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: Thu, 31 Oct 2013 00:23:32 -0000
Note also that DTLS role can change during the lifetime of the session (e.g. a peer that was active can become passive, and vice versa). So we will need to be more specific about when the role is in fact determined - perhaps the initial DTLS roles used in the session. On Wed, Oct 30, 2013 at 1:49 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> wrote: > Hi Randell, > Thanks again for your response. > > You asked what I thought would help to clear up any confusion around the > stream id assignment issue. I think clearer definitions of the different > types of negotiation, and a few more guidelines in the text would be great. > Please correct any of the following suggested guidelines to avoid > potential stream id conflicts. > > 1) For in-band negotiation before establishment of the SCTP association, > the application should use only deferred stream id assignment based on DTLS > role. (A little discussion of what this means also wouldn't hurt.) > Otherwise a preselected stream id on one side might conflict with a > deferred selection on the other side. > 2) For external negotiation before establishment of the SCTP association, > the application must select stream ids without waiting for determination of > DTLS role. Both peers need to know the stream id allocated to each data > channel via the external negotiation mechanism, so deferred selection > cannot be used. > 3) Prior to establishment of the SCTP association, if the application has > data channels to establish using both in-band and external negotiation, > external negotiation data channels should always be created before in-band > negotiation data channels. This allows the protocol to avoid reusing any > potentially conflicting stream ids allocated by the external negotiation > mechanism. > 4) After establishment of the SCTP association, in-band and external > negotiation can be freely mixed as long as stream id assignment is based on > DTLS role while avoiding already allocated ids. For application selection > of stream ids (rather than protocol selection of stream ids), the > application can determine the DTLS role by examining the exchanged SDP > messages. > > This paraphrases many of the things in your email that aren't yet in the > draft. Some of my confusion was that I was thinking of hybrid negotiation > mechanisms to allow application selection of stream ids with in-band > negotiation before establishment of the SCTP association, but it's far > easier to simply disallow that! > > BR, Richard > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Randell Jesup > > Sent: Tuesday, October 29, 2013 9:39 PM > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol- > > 01.txt > > > > On 10/29/2013 11:06 AM, Ejzak, Richard P (Richard) wrote: > > > Hi Randell, > > > There is clearly a problem with terminology here that is not allowing > > us to converge. Even after your explanation, I believe my > > issues/questions remain valid. I understand that we are discussing the > > data protocol draft, but we cannot ignore the pure external negotiation > > case when discussing compatibility issues. > > > > I'm definitely not ignoring it. I'm not specifying what the > > application does in the external negotiation; just how that affects the > > protocol stacks at either end. See my pseudo-code below, which has the > > advantage of avoiding english vagueries. I think part of the confusion > > comes from looking/thinking about the JS API, not the IETF protocol. > > > > > When I refer to in-band negotiation, I mean the use of the data > > channel protocol Open message to inform the peer browser that a > > specific stream id has been allocated to a data channel. > > > > Agreed. > > > > > When I refer to external negotiation, I mean the case where the data > > channel protocol Open message is NOT used but instead both applications > > need to use the create data channel method on the API to each browser > > to create both ends of each data channel. > > > > Agreed. That's how I've been using it, with what happens to decide on > > what the two apps end up using to initialize the two ends being largely > > out-of-scope to this discussion. > > > > > You apparently also use the term "external negotiation" to apply to > > the case where in-band negotiation needs to be augmented with > > additional communication (i.e., in addition to the Open message) > > between the applications. > > > > No, I didn't mean that to be what the term meant. Where do you think I > > implied that? > > > > > I consider this just a special case of in-band negotiation. Clear > > terminology to separate these cases would be useful since they have > > very different characteristics. Perhaps "augmented in-band > > negotiation" or "hybrid in-band/external negotiation"? > > > > > > The application can choose when creating a data channel via the API > > whether to select the stream id for the data channel or to request the > > browser to select the stream id. Apparently there are cases when the > > application MUST use only one of these options to guarantee correct > > operation. > > > > There are many ways the application can guarantee correct operation. > > Letting the first side of an external negotiation request the stack > > assign a free id of 'correct' oddness is merely an API helper at the JS > > level; it has no impact on the protocol per se, and the application can > > do it itself (with extra bookkeeping, as I stated). As such, it's only > > mentioned in the JS API spec, not the IETF drafts. > > > > > The application can also specifically request whether to send the > > data channel Open message once the SCTP association is established. It > > is understood that if the browser does not send the Open message that > > the peer application must also use its API to create the other end of > > the data channel. > > > > This is the external negotiation - both sides tell the stack that a > > channel has been agreed to. "Agreed to" can be "one side send to the > > other a channel definition, and the second side installs it, completing > > the channel." It also can be "both sides (same JS app) know a priori > > that channel id 0 is the reliable control channel used for Foo > > messages, and so inform the stack". > > > > > Without going through all the cases again, I think it's fair to say > > that the situation warrants some additional explanation (in the drafts) > > to describe these various cases and under what circumstances each is > > allowed. Your pseudo-code does not cover all the cases, and the > > situation is more subtle than you describe it to be. The current > > drafts are far from adequate in this regard. > > > > I think the pseudo-code does cover it - as that's also virtually what > > we've implemented (running code and all that). ;-) The other > > properties discussed emerge from that design and the JS API on top of > > it. You can see the actual (rather more messy!) code in > > netwerk/sctp/datachannel/DataChannel.cpp in Firefox. (Need to handle > > failures, requirement to allocate more streams from SCTP, JS interface, > > etc). > > > > Has my discussion above cleared up any of the confusion? If it has, do > > you have any proposed way to help others avoid that confusion? > > > > Thanks for looking at it before we're at the mics! > > > > Randell > > > > > > > > Please just answer one question: How does the application determine > > its DTLS role (i.e., whether to request even or odd numbers when > > choosing to select stream ids)? Does this need to be inferred from > > allocated stream ids or can the application determine it directly? > > > > > > Thanks, > > > Richard > > > > > > > > >> -----Original Message----- > > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > >> Behalf Of Randell Jesup > > >> Sent: Monday, October 28, 2013 11:45 PM > > >> To: rtcweb@ietf.org > > >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol- > > >> 01.txt > > >> > > >> On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote: > > >>> Hi Randell, > > >>> Thanks for suggesting the stream id assignment algorithm below. > > >> Please bear with me a little longer. I agree that limited > > >> coexistence of application and browser stream id selection is > > >> possible, but it seems that there are some significant restrictions. > > >>> Using in-band negotiation, I cannot see any way in which > > application > > >> selection and browser selection of stream ids can co-exist before > > >> DTLS roles are determined. If application A selects an odd stream > > >> id, the only way to communicate this selection to application B's > > >> browser is via the in-band open message after the SCTP association > > >> has been established. > > >> > > >> No, the application can tell the other end that in conjunction with > > >> the offer (i.e. in application-specific signaling that accompanies > > >> the offer). Any application using external negotiation must, in > > >> fact, handle external negotiation (even if that 'negotiation' is a > > >> set of hard-coded channel ids). > > >> > > >> Any later non-external-negotiated channel creations will select an > > >> unused id of the correct even/oddness (per DTLS role). One SHOULD > > >> create all initial-connection-time externally negotiated channels > > >> before adding any new automatic (data-protocol) ones, in order to > > >> avoid surprises -- though I'd be rather surprised that an > > application > > >> would mix them in that way. If the app does, it will work fine > > though. > > >> > > >> There is an implicit assumption that anything using external > > >> negotiation is either two instances of the same JS app or a > > >> cooperating app and server (those are by far the most common cases, > > >> and virtually the only cases), or two different apps that > > nonetheless > > >> know how to talk to each other and negotiate the channels on their > > >> own (I'll believe this when I see it, but it might happen). > > External > > >> negotiation was added specifically for these pre-cooperating cases. > > >> > > >> Also, one point perhaps missed from the W3 spec: > > >> > > >> 7. If the value of the |id > > >> > > >> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-datachannel- > > >> id>| > > >> attribute is null, initialize it to a value generated by the > > user > > >> agent, according to the WebRTC DataChannel Protocol > > specification, > > >> and skip to the next step. Otherwise, if the value of the |id > > >> > > >> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-datachannel- > > >> id>| > > >> attribute is taken by an existing ||RTCDataChannel| > > >> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def- > > >> RTCDataChannel>|, > > >> throw a |TBD| exception and abort these steps. > > >> > > >> Note this means you can create a channel for external negotation and > > >> let the browser select the id (which you then would tell the other > > >> side, and > > >> *they* would specify it to their end). Note that the ID will not be > > >> set until DTLS roles are decided (and that's when onopen should fire > > >> as well). This would not be very useful for setting up channels > > >> before offer/answer, but once offer/answer has completed, it lets > > you > > >> get a local channel id of correct oddness without having to scan all > > >> current datachannels to find an unused id value (assuming you're > > >> mixing styles of creation). > > >> > > >> (We may need to add a line to the IETF drafts to cover this case; > > >> need to check). The application *could* just scan all known > > channels > > >> instead, that's just a pain. And it really only matters if you mix > > >> types, which is likely to be rare outside of "create these N > > >> hard-coded channels at offer/answer time, then have some dynamic > > >> (automatically-assigned-id) channels that get used later if needed." > > >> > > >>> It doesn't help to tell application B since it can't report the > > >> information to its browser. So if application B creates another > > data > > >> channel and requests browser selection of a stream id then B's > > >> browser might end up selecting the same odd stream id, since it has > > >> no way to know to avoid it. Not unless we reserve id values > > >> exclusively for application selection. Do you agree? If so, we > > >> should document this restriction. > > >> > > >> When you tell the browser/protocol that a channel has been > > externally > > >> negotiated, it will mark that as in-use of course. That's why > > >> collisions can only happen when the other side creates an > > externally- > > >> negotiated channel of the "wrong" oddness in a race with an > > automatic > > >> creation from this side. This is trivially avoided when building an > > >> app. > > >> > > >> Much of this discussion in the mail I'm replying to is moot, since > > >> it's based on an incorrect assumption about mixing. > > >> > > >>> There is no problem if only browser selection of stream ids is > > >> allowed before the SCTP association is established since both > > >> applications can learn which side owns odd/even values after channel > > >> open is reported to the peer (since there has to be at least one > > data > > >> channel created to trigger the establishment of the SCTP > > association). > > >> Now application and browser stream id selection can co-exist without > > >> a hitch. > > >>> If we assume only application selection of stream ids is allowed > > >>> with > > >> in-band negotiation before the SCTP association is established, then > > >> we can also allow co-existence of application selection and browser > > >> selection of stream ids after establishment of the SCTP association, > > >> as long as there is a way for each application to determine DTLS > > role. > > >> They can't use the trick in the last paragraph since the browsers > > >> haven't been asked to assign any stream ids. Is there an API > > >> mechanism available to determine DTLS role? Am I missing something > > here? > > >>> With external negotiation, only application selection of stream ids > > >> can be allowed before DTLS role is determined since the external > > >> negotiation mechanism needs to be able to report to both peers (and > > >> browsers) the stream id(s) selected. Once DTLS role is determined > > >> then application and browser selection of stream ids could co-exist, > > >> but requires that the applications learn which DTLS roles were > > >> negotiated (same issue as above). > > >>> Interestingly, in-band and external negotiation can co-exist before > > >> DTLS role is established as long as application selection of stream > > >> ids is used exclusively. All forms of in-band and external > > >> negotiation can co-exist after the SCTP association is established > > as > > >> long as the applications know the DTLS roles. > > >> > > >> I'm not going to reply line-by-line here, since I think much of this > > >> is based on a slightly incorrect understanding. > > >> > > >>> In summary, the following combinations are allowed: > > >>> > > >>> 1) application selection with in-band negotiation before SCTP > > >>> established and app determines DTLS role > > >>> 2) browser selection with in-band negotiation before SCTP > > >>> established > > >>> 3) application selection with external negotiation before app > > >>> determines DTLS role > > >>> 4) application selection with in-band and external negotiation > > >>> before SCTP established and app determines DTLS role > > >>> 5) any combination of selection and negotiation after SCTP is > > >>> established if DTLS role is available to app > > >> I'd put it this way: > > >> > > >> 1) You can create any number of DataChannels before > > >> createOffer()/createAnswer() so long as all of them are > > automatically > > >> assigned ids (what you call browser selection). The actual ids are > > >> assigned after the DTLS roles are known. > > >> > > >> 2) You can create any number of externally-negotiated channels > > >> before createOffer(). There is no need for them to match DTLS > > roles. > > >> > > >> 3) The answerer must create any externally-negotiated channels from > > >> its side before the channels can be used, and also SHOULD do so > > >> before creating automatic channels unless the application has made > > >> sure somehow > > >> a collision is impossible/unlikely. In reality, there's no reason > > not > > >> to install the externally-negotiated channels before trying to > > create > > >> more, so the point is basically moot. (Note: you don't have to > > >> install the externally-negotiated channels before createAnswer, > > >> though normally I'd suggest doing so, just before creating > > >> automatically-generated > > >> ones.) > > >> > > >> 4) You can create externally-negotiated channels and then > > >> automatically negotiated channels before calling createOffer. You > > >> can even mix them, since the automatically-generated ones will be > > >> assigned ids later when DTLS role is known (and will avoid any > > >> already in-use). I'm not sure this is behavior that anyone would > > >> *need*, so I see no reason to promote mixing in that way - but it'll > > work. > > >> > > >> 5) Once the association is up, the application can use the method > > >> above (negotiated=true but no id=N) to allocate ids without fear of > > >> collision with automatic channels. > > >> > > >> This is all emergent from the even/odd selection and letting the > > >> protocol choose ids when not externally negotiated. > > >> > > >> Pseudo-code: > > >> > > >> creation: > > >> externally-selected-id? > > >> yes-> mark channel in use > > >> if channel already in use complain and fail > > >> no-> dtls role known? > > >> yes-> assign unused channel of correct oddness; send > > OPEN > > >> no-> queue channel id selection > > >> fire onopen if association is up > > >> > > >> incoming OPEN message: > > >> if channel already in use > > >> yes-> complain (perhaps fire onerror TBD) > > >> no-> Mark channel in use; inform application > > (ondatachannel); > > >> send ACK > > >> > > >> Pretty darn simple. > > >> > > >>> If DTLS exchange and SCTP establishment are associated with > > separate > > >> offer/answer transactions, there might be a few more combinations to > > >> consider. The list also does not describe what is possible if DTLS > > >> role is not available directly to the apps. > > >> > > >> DTLS and SCTP association establishment are async to offer/answer > > >> (kicked off by successful offer/answer completion). > > >> > > >>> The above discussion might be an argument for segregating the > > stream > > >> ids available for application and browser selection. There sure are > > >> plenty of them. What do you think? Then we wouldn't need to make > > >> DTLS role available to the app and there would only be a few > > >> restrictions on browser selection (it can't be used for external > > >> negotiation before DTLS role is determined). And you could always > > have an overflow rule. > > >>> Please correct me if I have missed anything. Thanks! > > >>> > > >>> BR, Richard > > >>> > > >>>> -----Original Message----- > > >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > >>>> Behalf Of Randell Jesup > > >>>> Sent: Sunday, October 27, 2013 4:46 AM > > >>>> To: rtcweb@ietf.org > > >>>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol- > > >>>> 01.txt > > >>>> > > >>>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote: > > >>>>> Richard, > > >>>>> > > >>>>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote: > > >>>>>> Hi Harald, > > >>>>>> You said: " I can't see a way to mix the two paradigms that > > >>>>>> guarantees this never happening." The two paradigms being > > >>>>>> browser selection vs. application selection of data channel > > stream ids. > > >>>> You can. You just have to be careful. For example, your > > >> application > > >>>> could define that pre-negotiated channels will use 100-110, and > > >>>> then specify those to both ends before association/offer/answer. > > >>>> Later > > >> it > > >>>> could use data-protocol to add dynamic channels (using even-odd). > > >>>> Since we've told both ends about 100-110, there's no problem here. > > >>>> Even/odd is ONLY to avoid glare when both sides decide to open a > > >>>> channel "at the same time". If you add a pre-negotiated channel > > >>>> after initial establishment, it's up to you to avoid colliding > > with > > >>>> any existing channels and to avoid colliding with any > > >>>> in-process-of- creation dynamic > > >>>> (data-protocol) channels. There are a number of ways to avoid > > such > > >> a > > >>>> collision safely (never use dynamic channels; use the DTLS role or > > >> an > > >>>> existing dynamic channel id to determine even/odd, etc). > > >>>> > > >>>>>> My proposal has three elements, which together can guarantee > > that > > >>>>>> there are no stream id allocation conflicts between peers: > > >>>>>> 1. The browser and application select stream ids based on > > >>>> initial > > >>>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial > > >>>>>> offerer uses even ids, initial answerer uses odd ids). With this > > >>>>>> rule, the offering application knows its role immediately > > without > > >>>>>> waiting for the DTLS or SDP handshake to occur. > > >>>>> A similar issue has come up in the discussion of partial > > >>>>> offers/answers. (Regarding how to assign a=mid values.) And a > > >>>>> similar solution was proposed. > > >>>>> > > >>>>> It was then rejected on the basis that sometimes both "ends" > > think > > >>>>> they are offerers or answerers. This comes about as a result of > > >>>>> signaling-only B2BUAs that play games with O/A on two legs. > > >>>> Exactly why we went with DTLS roles. > > >>>> > > >>>> -- > > >>>> Randell Jesup -- rjesup a t mozilla d o t com > > >>>> > > >>>> _______________________________________________ > > >>>> rtcweb mailing list > > >>>> rtcweb@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/rtcweb > > >>> _______________________________________________ > > >>> rtcweb mailing list > > >>> rtcweb@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/rtcweb > > >> > > >> -- > > >> Randell Jesup -- rjesup a t mozilla d o t com > > >> > > >> _______________________________________________ > > >> rtcweb mailing list > > >> rtcweb@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Randell Jesup -- rjesup a t mozilla d o t com > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] I-D Action: draft-ietf-rtcweb-data-proto… internet-drafts
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Ejzak, Richard P (Richard)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Michael Tuexen
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Justin Uberti
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Ejzak, Richard P (Richard)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Michael Tuexen
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Ejzak, Richard P (Richard)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Harald Alvestrand
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Ejzak, Richard P (Richard)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Paul Kyzivat
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Michael Tuexen
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Ejzak, Richard P (Richard)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Ejzak, Richard P (Richard)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Paul Kyzivat
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Eric Rescorla
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Matt Fredrickson
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Ejzak, Richard P (Richard)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Paul Kyzivat
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Eric Rescorla
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Paul Kyzivat
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Eric Rescorla
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Harald Alvestrand
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Harald Alvestrand
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Randell Jesup
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Max Jonas Werner
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Paul Kyzivat
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Ejzak, Richard P (Richard)
- Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-p… Justin Uberti