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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 25 November 2014 11:23 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 794B21A00A9 for <clue@ietfa.amsl.com>; Tue, 25 Nov 2014 03:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 STc2tTqL84Ac for <clue@ietfa.amsl.com>; Tue, 25 Nov 2014 03:23:53 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE041A008B for <clue@ietf.org>; Tue, 25 Nov 2014 03:23:52 -0800 (PST)
X-AuditID: c1b4fb3a-f79116d000000fec-31-547466c6b717
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A7.A0.04076.6C664745; Tue, 25 Nov 2014 12:23:50 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 12:23:50 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christian Groves <Christian.Groves@nteczone.com>, "clue@ietf.org" <clue@ietf.org>
Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP
Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwAAJH5gAGzPFIAABv9ZSQApnc6AABrtWkA=
Date: Tue, 25 Nov 2014 11:23:50 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com>
In-Reply-To: <5473BE59.4070805@nteczone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje6xtJIQg3NLrSy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJUxZdkRxoJbphWr7s5lb2BcYdLFyMkhIWAi sfTLXBYIW0ziwr31bF2MXBxCAkcYJZYf/s4E4SxhlGj7PZmxi5GDg03AQqL7nzZIg4hAuETH tiuMILawgLtEx+HTLBBxD4l3WzYwQ9h+EhM2T2ECsVkEVCUWr53KBmLzCvhKtL/tYgWxhQRm MUkcnGQIYnMK6EicPf8GrJcR6KDvp9aA9TILiEvcejKfCeJQAYkle84zQ9iiEi8f/2MFOU1C QEli2tY0EJNZQFNi/S59iE5FiSndD9khtgpKnJz5hGUCo+gsJENnIXTMQtIxC0nHAkaWVYyi xanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBEXJwy2+rHYwHnzseYhTgYFTi4d3woThEiDWxrLgy 9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwTpzp4LPr1O6p55b9EDuy ry1sYXWrY/WkluUOAvJl1vx7WcP58k+FLn22nclY43XBNaM97j89pTbMzdh0Krz604u0w5N1 K2s7JwYW9RxZqzrxW41nwoFPeqFM6WaKqRIOXN4Z26cctExQuxp150TeFP/Gd991di/8dmb7 4kT+l09rNjxIvWbdpcRSnJFoqMVcVJwIAHNe9IhxAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/O0mpxscEOYeF2PDR4nNKogvrPzk
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: Tue, 25 Nov 2014 11:23:55 -0000

Hi,

If I understood Paul's comment, DCEP is not required for compatibility with WebRTC endpoints. If you provide the SCTP port in the WebRTC API, then DCEP won't be used.

The question is really whether we want to mandate non-WebRTC CLUE devices to implement DCEP or not.

Regards,

Christer

-----Original Message-----
From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves
Sent: 25. marraskuuta 2014 1:25
To: clue@ietf.org
Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP

I thought the reason we used DCEP was so that it was compatible with WebRTC endpoints. So is this not a concern anymore?

My view is that it should be possible to use external negotiation to negotiate the protocols that are used for the data channel and then use DCEP to establish the SCTP channel. This effectively emulates what we had in our CLUE data channel draft where the a=GROUP:CLUE on the datachannel m=line indicated that CLUE would be used and then DCEP was used to establish the SCTP channel.

Christian

On 24/11/2014 1:33 PM, Christer Holmberg wrote:
> Hi,
>
> I agree with what you are saying, there is no need for DCEP if we use 
> external negotiation.
>
> The question is then whether we should remove DCEP completely from the 
> CLUE data channel draft?
>
> DCEP could be useful if someone implemented CLUE using another 
> signalling protocol than SIP/SDP, but we are not specifying such 
> usage, so...
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ----------------------------------------------------------------------
> --
> From: Paul Kyzivat <mailto:pkyzivat@alum.mit.edu>
> Sent: ‎24/‎11/‎2014 02:13
> To: clue@ietf.org <mailto:clue@ietf.org>
> Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and 
> DCEP
>
> 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
> >
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue