Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 02 March 2014 21:59 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 7BFAC1A0B34 for <rtcweb@ietfa.amsl.com>; Sun, 2 Mar 2014 13:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] 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 Btr0ml8TgGHH for <rtcweb@ietfa.amsl.com>; Sun, 2 Mar 2014 13:59:02 -0800 (PST)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id C67701A0B48 for <rtcweb@ietf.org>; Sun, 2 Mar 2014 13:59:00 -0800 (PST)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id Ylhm1n0021ei1Bg51lyykC; Sun, 02 Mar 2014 21:58:58 +0000
Received: from dhcp-hotel-wifi-157-6c.meeting.ietf.org ([130.129.157.108]) by omta24.westchester.pa.mail.comcast.net with comcast id Ylwj1n00W2LcPnE3klwlwd; Sun, 02 Mar 2014 21:56:56 +0000
Message-ID: <5313A91C.2030407@alum.mit.edu>
Date: Sun, 02 Mar 2014 21:56:44 +0000
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <7594FB04B1934943A5C02806D1A2204B1D1BC516@ESESSMB209.ericsson.se> <CAJuyhsyk4jO_TS=5khD9ROAx7uYU1YAkCV0Xy4QVUkiqXBJJfg@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17826DFFB545@US70UWXCHMBA02.zam.alcatel-lucent.com> <530E4E34.4010707@alum.mit.edu> <E1FE4C082A89A246A11D7F32A95A17826DFFEDAB@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFFF2E4@US70UWXCHMBA02.zam.alcatel-lucent.com> <5310B14E.4000809@alum.mit.edu> <E1FE4C082A89A246A11D7F32A95A17826E0011F6@US70UWXCHMBA02.zam.alcatel-lucent.com>
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17826E0011F6@US70UWXCHMBA02.zam.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393797538; bh=mDLs93P4I8OW62UI7nMzZhDhtW0DubkRJG0wN3OwNl0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E9SbaYp8Ff8sgtM8RnhXqYkzae0cHZ9WbXqVKpJxcOn9Xdi4gUbvSKvk6wNZfYWz9 uwkgOel15YJcyZ6Y+JceKOdcLaj0hpOxJlKKfGfzrQpCGhpkbge6gKbxTG8Eu2qkLn 2h1QNaHZ+H2K0k0X4smvlJPwcBQJ9yDHBZFc/XyZe22rfE52s3tjQrAfI+bTViMfpj PaVitgd3BFNB8lQzyz9wZ/GKTZgtXxTWBw2CVz3/ghZJrZolLrEGVS+8KvcWzZP7p1 vwAR+n+fKRehsdj12HDbd/XwOfYEZxDawtJUm3DqSEIHc1mwWaCBEggVyo3/EAPBmq 3n1qvefuL+mBA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MlVLEMi80wIUYFwgPFBMYjqKHYQ
Subject: Re: [rtcweb] [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel
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: Sun, 02 Mar 2014 21:59:04 -0000

I suspect we are not understanding one another.

On 2/28/14 4:46 PM, Makaraju, Maridi Raju (Raju) wrote:
> Hi Paul,
>
>
>>>> Isn't it enough to, in the data channel protocol spec, say that the
>> odd/even
>>>> rule applies unless the stream id is explicitly negotiated using some
>> other
>>>> mechanism?
>>>>
>>> [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data-
>> channel-sdpneg should still need to say that "when both external and DCP are
>> used, even for DCP created streams the stream ids have to be specified and
>> managed by the application (else DCP stack will default to odd/even rule per
>> DTLS role which may conflict with SDP offer/answer rule)".
>>
>> Can we assume there must be a mechanism for using DCEP and still
>> controlling which channels are used?
>
> [Raju] Yes, we can assume that and it is already supported by :
> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.5
> and
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannel-id
> I believe it is safe to assume non-browser implementations of
> data channel stack gives an option for application to select
> stream ids independent of DCEP or external negotiation.
>
>
>>
>> It might help if the O/A negotiation also followed the even/odd rule.
> [Raju] May be I am missing something here. Richard's draft already has
> a specific even/odd rule for O/A. But the issue is TLS based rule may
> conflict with the O/A rule as TLS roles may change depending on a=setup.
>
>> But there are difficulties in knowing who is even and who is odd for the
>> first O/A.
>
> [Raju] Not related to first or subsequent O/A, but rather a conflict
> between TLS roles vs. O/A.

OK. I didn't state what I meant clearly, and I forgot Richard had an 
even/odd rule. For O/A there really isn't a need for one, since the only 
cases this will be a problem result in O/A glare, and that is then 
resolved via backoff.

What I meant was it might help if the O/A proposal and DCEP followed the 
*same* rule. I think that is what Richard wanted. But he showed why O/A 
can't use the existing DCEP rule, so *that* would be required to change.

>> If the offerer always creates the channel before sending the offer, then
>> that will prevent the two mechanisms from stepping on one another's
>> stream ids.
> [Raju]
> In some cases, initial offer may not have a data channel stream created.
> I don't know how this can prevent stepping on each other?!
> May be I am missing something here?! In most cases TLS role is
> determined after O/A is completed, but offerer creates a data
> channel before answer, then how does it know even/odd rule?
> So, trying to use TLS role for external negotiation is problematic.

For channels negotiated at the same time the SCTP association is 
negotiated the offerer can use *any* ids, since there can yet be no 
conflict.

Then, once the association is established, the channels declared in the 
SDP need to be "opened" (activated?), independently by both sides. They 
will then be reserved.

After that, if the application follows the DCEP even/odd rule, and 
creates the channel at its end before sending an offer, then that cannot 
conflict with channels dynamically allocated by DCEP. And both sides 
then understand who is even and who is odd, so there will be no 
conflicts by the two sides choosing the same channel.

	Thanks,
	Paul