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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 28 February 2014 15:57 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 233621A085D for <rtcweb@ietfa.amsl.com>; Fri, 28 Feb 2014 07:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 IUHRaU2FSPjd for <rtcweb@ietfa.amsl.com>; Fri, 28 Feb 2014 07:57:12 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id EEA131A0859 for <rtcweb@ietf.org>; Fri, 28 Feb 2014 07:57:11 -0800 (PST)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id XpJw1n0021YDfWL5DrxA4y; Fri, 28 Feb 2014 15:57:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([130.129.152.238]) by omta20.westchester.pa.mail.comcast.net with comcast id Xruu1n00H58sGga3gruwrg; Fri, 28 Feb 2014 15:55:08 +0000
Message-ID: <5310B14E.4000809@alum.mit.edu>
Date: Fri, 28 Feb 2014 10:54:54 -0500
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>
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17826DFFF2E4@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=1393603030; bh=f9fp8KuOfJ9zm18eCbvBXn0kpxqdlHNcscQWACXwnYQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Wty/t3CKlGV6bmgUveOI19/eVax5fLR92zlZKhnw5o4eOnYB51pIN1bWF0FksP8mO QkIqLDP7ZIZIWe7RtQ/eYYjX5zxNd+092y6wttmlgTxv7wf9vRKMEcro1Ge7vjM/oN YLvCTO2AGtU3dx7nIB/ajKX6wg0rm5iWyIBEAOT8S0bwD4SZJww1mVHWK0MY6xE5ip Fz/LHBB1EDMryF7IYjo5jngXBbjc3BJZwsDMoAjtWQNYZ7XZsbmtZiXRwRf+IAKqMr myPixABBWTdHHtMbCJMutU1x1erkZbUwfLlLwU6iqiG2r0SeEK2lQuh3SQyqYpzoD7 Fn0u4btruV8iw==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n13U3mXsFmOm3W1h2rb-McMytDE
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: Fri, 28 Feb 2014 15:57:13 -0000

Raju,

On 2/27/14 5:59 PM, Makaraju, Maridi Raju (Raju) wrote:
> Hi Christer,
>
>> Hi,
>>
>> 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?

It might help if the O/A negotiation also followed the even/odd rule.
But there are difficulties in knowing who is even and who is odd for the 
first O/A.

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.

	Thanks,
	Paul

> Thanks for agreeing to add this to the draft!
>
> Raju
>
>