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

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