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

[Christer Holmberg <[e-mail]>]

Hi,

> I disagree.
>
> The point of this constraint was to allow concurrent use of the channel with
> both SDP negotiation of channels and DCEP dynamic channel management.
> Absent that I agree that SDP negotiation would be sufficient.
>
> An example of when this could be a problem is when a session is already
> established. Then one side prepares to send an offer to negotiate a new
> channel via SDP. It sends an offer. Concurrently the other side begins to
> use a
> channel via DCEP rules. If they happen to choose the same channel number a
> problem arises. Using the same even/odd rules that DCEP uses prevents this
> problem.
>
> Is there motivation for removing this restriction?

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.

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.)

Regards,

Christer




> On 2/9/24 3:02 AM, RFC Errata System wrote:
> > The following errata report has been submitted for RFC8864,
> > "Negotiation Data Channels Using the Session Description Protocol (SDP)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7805
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Harald Alvestrand <[e-mail]>
> >
> > Section: 6.1
> >
> > Original Text
> > -------------
> >     In order to avoid SCTP Stream identifier collisions, in alignment
> >     with [RFC8832], the endpoint acting as a DTLS client (for the SCTP
> >     association used to realize data channels) MUST use even identifier
> >     values, and the endpoint acting as a DTLS server MUST use odd
> >     identifier values.
> >
> >
> > Corrected Text
> > --------------
> > [RFC8831] does not restrict the SCTP Stream identifiers for data
> > channels negotiated out-of-band. The endpoints are free to assign any
> > numbers to the negotiated data channels; collisions are handled by the
> > usual mechanisms used to avoid SDP signalling glare.
> >
> >
> >
> > Notes
> > -----
> > The procedures of [RFC8832] are inappropriate in this case, because
> DCMAP indicates channels negotiated out-of-band and not via DCEP.
> >
> > At initial offer, the DTLS direction attribute is ACTPASS, so the
> > direction is
> not known. Thus, the RFC 8832 numbering rule is impossible to apply
> anyway.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please use
> > "Reply All" to discuss whether it should be verified or rejected. When
> > a decision is reached, the verifying party will log in to change the
> > status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC8864 (draft-ietf-mmusic-data-channel-sdpneg-28)
> > --------------------------------------
> > Title               : Negotiation Data Channels Using the Session
> > Description
> Protocol (SDP)
> > Publication Date    : January 2021
> > Author(s)           : K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even,
> > Ed.
> > Category            : PROPOSED STANDARD
> > Source              : Multiparty Multimedia Session Control
> > Area                : Applications and Real-Time
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic