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

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