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
>