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

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Nov 2014 19:20:21 +0000

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.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21 November 2014 21:17
To: [email-masked]
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

---

From: Christian Groves <[email-masked]>
Date: Mon, 24 Nov 2014 11:00:39 +1100

Hello Christer,

I made a similar comment to the authors. If DCEP is used, it could 
allocate the SCTP StreamIDs so they may not have to be negotiated via 
draft-ejzak. Only which protocol and associated parameters.

Regards,
Christian

On 22/11/2014 6:20 AM, Christer Holmberg wrote:
> 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.
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer 
> Holmberg
> *Sent:* 21 November 2014 21:17
> *To:* [email-masked]
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Nov 2014 19:13:15 -0500

On 11/21/14 2:20 PM, Christer Holmberg wrote:
> 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.
>

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

> 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?
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Nov 2014 02:33:36 +0000

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:[email-masked]>
Sent: ‎24/‎11/‎2014 02:13
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP

        Thanks,
        Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 25 Nov 2014 10:25:13 +1100

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:
> 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
>
> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 24 Nov 2014 23:34:38 +0000

Per discussions with Christian, we are going to propose new backward compatible syntax and use cases of ejzak-mmusic-data-channel-sdpneg to use it external negotiation of subprotocol(s) and their attributes while using DCEP for establishment of the DC. We will update MMUSIC list for feedback on the proposal and will cc clue alias.
Please stay tuned.

BR
Raju

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Monday, November 24, 2014 5:25 PM
> To: [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 11:23:50 +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:[email-masked]] On Behalf Of Christian Groves
Sent: 25. marraskuuta 2014 1:25
To: [email-masked]
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:
> > 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.
>
> 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).
>
> 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:[email-masked]] *On Behalf Of 
> > *Christer Holmberg
> > 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.
> >
> > 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
> >
> >
> >

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 11:33:02 +0000

Hi,

>Per discussions with Christian, we are going to propose new backward compatible syntax and use cases of ejzak-mmusic-data-channel-sdpneg to use it external negotiation of subprotocol(s) and their attributes while using DCEP for establishment of the DC. 
>
>We will update MMUSIC list for feedback on the proposal and will cc clue alias.

Please don't cross-post on multiple lists. Interested people should follow the discussion on the MMUSIC list.

Regards,

Christer

> 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 
> > > 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.
> > >
> > > endpoints can choose when to open the data channel – otherwise it 
> > > is considered open once the SCTP association has been created.
> >
> > 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).
> >
> > > together with draft-ejzak-mmusic-data-channel-sdpneg, or whether 
> > > it should be optional?
> > >

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Nov 2014 11:41:12 +0000

> If you provide the SCTP port in the WebRTC API, then DCEP won't be used.
You meant "(stream) id" instead of "SCTP port"? In WebRTC API createDataChannel(), use of DCEP is controlled by using "negotiated" parameter. (Stream) id specification only determines the stream id to be used.

BR
Raju

> From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Tuesday, November 25, 2014 5:24 AM
> To: Christian Groves; [email-masked]
> 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.
> 
> I thought the reason we used DCEP was so that it was compatible with WebRTC
> endpoints. So is this not a concern anymore?
> 
> 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
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 11:47:26 +0000

Hi,

> 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

> 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.
> 
> > --------------------------------------------------------------------
> > --
> > --
> > > open the CLUE data channel, once it has been negotiated using 
> > > draft-
> ejzak.
> > >
> > > finished and the SCTP association used to realize the data 
> > > channel(s)
> has been created.
> > >

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Nov 2014 12:00:07 +0000

> > In WebRTC API createDataChannel(), use of DCEP is controlled by using
> "negotiated" parameter. (Stream) id specification only determines the stream
> id to be used.
> 
[Raju] 
IMHO, I am in favor of not mandating DCEP for non-WebRTC device CLUE usage. Furthermore, to be consistent it may be better not to use DCEP even when CLUE is used by a WebRTC device.

BR
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Nov 2014 13:42:48 -0500

> IMHO, I am in favor of not mandating DCEP for non-WebRTC device CLUE usage. Furthermore, to be consistent it may be better not to use DCEP even when CLUE is used by a WebRTC device.

If we mandate using draft-ejzak for establishing the clue channel, then 
DCEP won't be *used*. I think we simply make a requirement for support 
of draft-ietf-rtcweb-data-channel, and don't mention 
draft-ietf-rtcweb-data-protocol. If there are dependencies between those 
two, then that is not our problem. (I thought data-channel had a 
dependency on data-protocol, but I don't see it now, which is a good thing.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 19:17:41 +0000

Hi,

I agree with Paul.

But, the question is still whether the CLUE data channel spec ahould still define the DCEP code point for the CLUE data channel, IF someone e.g. want to specify usage of CLUE in a non-O/A environment.

Regards,

Christer

Sent: ‎25/‎11/‎2014 20:43

        Thanks,
        Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 26 Nov 2014 11:20:32 +1100

I'm OK with dropping DCEP. It could be worth keeping the DCEP code point 
as you say for non-O/A environment.

Regards, Christian

On 26/11/2014 6:17 AM, Christer Holmberg wrote:
> Hi,
>
> I agree with Paul.
>
> But, the question is still whether the CLUE data channel spec ahould 
> still define the DCEP code point for the CLUE data channel, IF someone 
> e.g. want to specify usage of CLUE in a non-O/A environment.
>
> Regards,
>
> Christer
>
> > IMHO, I am in favor of not mandating DCEP for non-WebRTC device CLUE 
> usage. Furthermore, to be consistent it may be better not to use DCEP 
> even when CLUE is used by a WebRTC device.
>