IETF Logo Mail Archive

Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 24 November 2014 00:13 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032D61A1B6D for <clue@ietfa.amsl.com>; Sun, 23 Nov 2014 16:13:32 -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 5ZaAeqYnaVwH for <clue@ietfa.amsl.com>; Sun, 23 Nov 2014 16:13:30 -0800 (PST)
Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6111A1B69 for <clue@ietf.org>; Sun, 23 Nov 2014 16:13:17 -0800 (PST)
Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-03v.sys.comcast.net with comcast id KCDC1p0064tLnxL01CDGrs; Mon, 24 Nov 2014 00:13:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-02v.sys.comcast.net with comcast id KCDF1p0133Ge9ey01CDGV3; Mon, 24 Nov 2014 00:13:16 +0000
Message-ID: <5472781B.1050209@alum.mit.edu>
Date: Sun, 23 Nov 2014 19:13:15 -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.6.0
MIME-Version: 1.0
To: clue@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1416787996; bh=T7eru7MqcFK9hxHYHjP/7G2AWkUC0IM9AN3JjcFp2uI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PLZF4HFr/lZ/IpCkvtdDCZwFU3jbbQOffCcu5ESSeaQrFf7UxPNY7CIMesP7BDUWz OaicePXuiT6ox2a0t9vSh08JB2u4ALwHCtp7LX1JLATz6gg1rK0egm41tnhBoBpbBh rFabjU3DTGFn2SEuo96fWCsbI4LEB0pNZo3F3i8FhmuMRlmuxQOs6T4RHlmnbyZeAr IL64b5qoC1gdGDYA2Gxk+IL3koK9T8GN16mVdSy+GxZw5OidINjOaiS6w0MZ8NfcJU /b6eZZOl4RJMrhMV8zSA0XJ0QD6TXRtqNEvfETm21g2wt0tnfylFEjZjIeecgcIf4k aVffg7vVjimKQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/9PzEQVNBFneXBqtSmdltbRCZbNk
Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 00:13:35 -0000

On 11/21/14 2:20 PM, Christer Holmberg wrote:
> FYI,
>
> I sent the following to the MMUSIC list.
>
> The CLUE data channel draft currently assumes that DCEP is used to open
> the CLUE data channel, once it has been negotiated using draft-ejzak.
>
> However, if draft-ejzak forbids usage of DCEP, and/or we don’t think
> it’s needed for the CLUE data channel, we can remove it.
>
> In my opinion, the advantage of also using DCEP is that the endpoints
> can choose when to open the data channel – otherwise it is considered
> open once the SCTP association has been created.

My understanding is that DCEP is *not* used. When you use external 
negotiation you simply agree (externally) on which stream ids are to be 
used (they don't even have to be the same in each direction) and start 
using them.

I could be wrong, but I don't think the webrtc API has a way for you to 
use the DCEP protocol on an externally allocated channel. You can call 
to open a channel without supplying a stream id, in which case DCEP is 
automatically used to assign the id), or else you can supply a stream id 
when opening a channel (in which case DCEP is not used).

I suppose nothing prevents you from using DCEP messages on your 
externally allocated channel, but then you would have to format and send 
them yourself, and decode them at the other end, rather than having the 
library behind the API doing it for you.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* 21 November 2014 21:17
> *To:* mmusic@ietf.org
> *Subject:* [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP
>
> Hi,
>
> draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that
> DCEP will not be used to open data channels – instead data channels will
> be considered open once the SDP O/A negotiation has finished and the
> SCTP association used to realize the data channel(s) has been created.
>
> My question is whether the intention is to forbid usage of DCEP together
> with draft-ejzak-mmusic-data-channel-sdpneg, or whether it should be
> optional?
>
> If optional, there needs to be a way to indicate that application data
> shall not be sent until a channel has been opened using DCEP. In
> addition, it would be useful to be able to indicate which endpoint is
> responsible for sending the DCEP_CHANNEL_OPEN message.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

v2.23.0 | Report a Bug | By Email