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

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