Re: [MMUSIC] [Technical Errata Reported] RFC8864 (7805)

[Christer Holmberg <[e-mail]>]

Hi,

I am not sure what you mean be "pre-agreed data channels", but I was referring 
to applications that use both DCEP and SDP.

Also, your claim that the DCEP odd/even restriction would not apply for 
certain cases is (AFAIK) not defined anywhere. Also, I don't understand why 
the odd/even restriction would not apply in the case where you have pre-agreed 
data channels. You still want to avoid stream ID collisions when using DCEP - 
no matter if you have pre-agreed data channels or not.

Regards,

Christer

> -----Original Message-----
> From: mmusic <[e-mail]> On Behalf Of Harald Alvestrand
> Sent: Thursday, 4 April 2024 8.38
> To: [e-mail]
> Subject: Re: [MMUSIC] [Technical Errata Reported] RFC8864 (7805)
>
> Yes, there are applications that both establish pre-agreed datachannels and
> use DCEP. For those cases, the odd/even restriction does not apply; it is up 
> to
> the application to rendezvous properly.
>
> This erratum removes the incorrect claim that SDP-negotiated channels are
> capable of obeying the odd/even rule, bringing SDP-negotiated channels in
> line with the rules for pre-agreed datachannels.
>
> Harald
>
>
> On 3/27/24 11:48, Christer Holmberg wrote:
> > Hi,
> >
> >>>>> The issues (AFAIU) is when the offerer sends the *initial* offer,
> >>>>> with ACTPASS, and creates one or more data channels using SDP. At
> >>>>> that point the offerer does not yet know whether it will become
> >>>>> DTLS client or server, but it still has to assign identifiers (odd
> >>>>> or even) to the data channels.
> >>>>
> >>>> Good point. At that point there should be no risk of conflict with
> >>>> DCEP.
> >>>> Maybe a revision is needed to deal with that.
> >>>
> >>> Yes.
> >>>
> >>> And, if DCEP is then later used to create another data channel, it
> >>> needs to make sure that it does not re-use the same identifier (no
> >>> matter if it is odd or even).
> >>>
> >>>>> Once the DTLS roles have been determined, the DCEP rules work fine
> >>>>> also for SDP.
> >>>>>
> >>>>> (Personally I have never seen a use-case where both DCEP and SDP
> >>>>> are used to create and manage data channels.)
> >>>>
> >>>> It is hard to envision a use case for it. But as I recall we were
> >>>> trying to avoid precluding it. One alternative would be for the SDP
> >>>> negotiation to include the choice of either DCEP or SDP for
> >>>> negotiating data channels.
> >>>> But
> >>>> could that be done in a backward compatible way?
> >
> > The usage of dcmap does indicate such choice in my opinion.
> >
> > But, again, I cannot guarantee that there are no implementation that
> > use both SDP and DCEP within the same session.
> >
> >>>> If we were able to verify that there is currently no concurrent use
> >>>> in the wild then perhaps we could amend to say that use of SDP to
> >>>> negotiate data channels precludes use of DCEP.
> >>>
> >>> It is difficult to verify that.
> >>>
> >>> But, as discussed above, if we say that in case of ACTPASS the
> >>> offerer can choose either an odd or even value.
> >>
> >> It sounds to me like this is something you'd want to discuss should a
> >> -bis document ever become a reality, but not confirm the erratum
> >> as-is.  Is that correct?  If so, then we want "Hold For Document
> >> Update" rather than "Verified" for this one, correct?
> >
> > We can discuss whether we should fix this using a -bis or an erratum.
> >
> > But, the current erratum should not be agreed in its current form.
> >
> > I think the first thing we need to do is how the solution would look
> > like: the easiest solution would be to simply that say:
> >
> > 1)	If one uses SDP one SHOULD/MUST NOT use DCEP
> > 2)	Remove the even/odd requirement when using SDP (at least when
> using
> > ACTPASS)
> >
> > Regards,
> >
> > Christer
> >
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fmmusic&data=05%7C02%7Cchrister.holm
> ber
> >
> g%40ericsson.com%7Cb1e38f9c6c404579285108dc54696c5c%7C92e84cebfb
> fd47ab
> >
> be52080c6b87953f%7C0%7C0%7C638478058969825780%7CUnknown%7CT
> WFpbGZsb3d8
> >
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C0
> >
> %7C%7C%7C&sdata=2F2msSXLsc9axwanuxC7N4%2B6w%2FwYD4cv9NqjTm3f
> OsE%3D&res
> > erved=0
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fmmusic&data=05%7C02%7Cchrister.holm
> berg%40ericsson.com%7Cb1e38f9c6c404579285108dc54696c5c%7C92e84ce
> bfbfd47abbe52080c6b87953f%7C0%7C0%7C638478058969838191%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1xdEPMYo26r5ZizOpgZ
> UB%2Fs34kJB3PqN%2B4KcydN6LTQ%3D&reserved=0