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

[Paul Kyzivat <[e-mail]>]

On 2/12/24 3:56 AM, Christer Holmberg wrote:
> 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.

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

	Thanks,
	Paul

> 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