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

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Thu, 27 February 2014 22:59 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
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 4C73E1A02A6; Thu, 27 Feb 2014 14:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 WCDKXSH_WHe9; Thu, 27 Feb 2014 14:59:09 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CF22B1A015E; Thu, 27 Feb 2014 14:59:08 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1RMx4S9027874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 16:59:04 -0600 (CST)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s1RMx3f5029253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 17:59:03 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 17:59:03 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel
Thread-Index: AQHPMv00Ot+PDux+H0inH2oRraNWlJrH7JxQgABjlQCAAR/dwIAAideA//+55EA=
Date: Thu, 27 Feb 2014 22:59:02 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFFF2E4@US70UWXCHMBA02.zam.alcatel-lucent.com>
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>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1C023A@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/M2rWQQXjuaftK4609_hJgfy3xA0
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: Thu, 27 Feb 2014 22:59:10 -0000

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)".

Thanks for agreeing to add this to the draft!

Raju