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

[Gunnar Hellström <[e-mail]>]

It seems to me that the realistic solution is to separate the SDP 
exchange for the SCTP association from the SDP exchange for the channel 
establishment. Then the same odd/even rule can be used for SDP based 
opening of channels as for DCEP based.

For a simple case it looks less efficient, by requiring two SDP 
exchanges, but it will be similar to when using DCEP.

This can be established by changes in 6. and 6.1

------Sentences to change in 6. ---------------------------------------

The generic offer/answer procedures for negotiating the SCTP association 
used to realize data channels are defined in[RFC8841 
<https://datatracker.ietf.org/doc/html/rfc8841>]. This section only 
defines the data-channel-specific procedures.

¶ <https://datatracker.ietf.org/doc/html/rfc8864#section-6-2>

"Initial offer" refers to the offer in which a data channel is opened. 
It can be either the initial offer or a subsequent offer of the 
associated SDP session.¶ 
<https://datatracker.ietf.org/doc/html/rfc8864#section-6-3>

--------Proposed new wording of 
6.-------------------------------------------------------------------------------------------

The generic offer/answer procedures for negotiating the SCTP association 
used to realize data channels are defined in[RFC8841 
<https://datatracker.ietf.org/doc/html/rfc8841>]. This section only 
defines the data-channel-specific procedures.

¶ <https://datatracker.ietf.org/doc/html/rfc8864#section-6-2>

"Initial offer" refers to the offer in which a data channel is opened. 
*The initial offer SHALL be made after the corresponding SCTP 
Association is established.**¶* 
<https://datatracker.ietf.org/doc/html/rfc8864#section-6-3>


--------------Current wording of 6.1 
---------------------------------------------------------------

In order to avoid SCTP Stream identifier collisions, in alignment 
with[RFC8832 <https://datatracker.ietf.org/doc/html/rfc8832>], the 
endpoint acting as a DTLS client (for the SCTP association used to 
realize data channels)MUSTuse even identifier values, and the endpoint 
acting as a DTLS serverMUSTuse odd identifier values.

SCTP stream identifiers associated with data channels that have been 
negotiated using DCEPMUST NOTbe included in SDP offers and answers.

¶ <https://datatracker.ietf.org/doc/html/rfc8864#section-6.1-2>

-------Proposed new wording of 6.1 ---------------------------------------

In order to avoid SCTP Stream identifier collisions, in alignment 
with[RFC8832 <https://datatracker.ietf.org/doc/html/rfc8832>], the 
endpoint acting as a DTLS client (for the SCTP association used to 
realize data channels)MUSTuse even identifier values*in offers,* and the 
endpoint acting as a DTLS serverMUSTuse odd identifier values *in 
offers*. *The answers SHALL have the same identifier values as in the 
offers.*

SCTP stream identifiers associated with data channels that have been 
negotiated using DCEPMUST NOTbe included in SDP offers and answers.

----------------------------------------------------------------------------------

It should be possible to develop guidelines for implementation of the 
resulting procedures in browser based application.

RFC8864 Annex A describes that other methods for assigning stream ID:s 
than the odd/even rule can be defined for specific applications. So, for 
more efficient channel establishment it can be specified that when DCEP 
is not at all used in the SCTP Association, then the application may 
decide on other ways to decide on the SCTP stream ID:s. Proposals for 
such handling may be added to 6. or 6.1. if the main principle above is 
found suitable.

/Gunnar

------------------------------------------------------------
Gunnar Hellström
GHAccess
[e-mail]
Tel: [phone]