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