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

[Christer Holmberg <[e-mail]>]

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



> -----Original Message-----
> From: clue [mailto:[e-mail]] On Behalf Of Christian 
> Groves
> Sent: Monday, November 24, 2014 5:25 PM
> To: [e-mail]
> 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:[e-mail]>
> > Sent: ‎24/‎11/‎2014 02:13
> > To: [e-mail] <mailto:[e-mail]>
> > 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:[e-mail]] *On Behalf Of 
> > > *Christer Holmberg
> > > *Sent:* 21 November 2014 21:17
> > > *To:* [e-mail]
> > > *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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/clue
> > >
> >
> > _______________________________________________
> > clue mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/clue
> >
> >
> > _______________________________________________
> > clue mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/clue
> 
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/clue