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

Hi,

>> If you provide the SCTP port in the WebRTC API, then DCEP won't be used.
> You meant "(stream) id" instead of "SCTP port"?

Yes.

> In WebRTC API createDataChannel(), use of DCEP is controlled by using "negotiated" parameter. (Stream) id specification only determines the stream id to be used.

Ok. But, the point is that you can create a data channel without DCEP.

Regards,

Christer

> -----Original Message-----
> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer 
> Holmberg
> Sent: Tuesday, November 25, 2014 5:24 AM
> To: Christian Groves; clue@ietf.org
> Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and 
> DCEP
> 
> 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
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue