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

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

I see that MMUSIC is about to close, but the list to be open for errata discussions.

One errata discussion we have not closed yet is the one on RFC8864.

 

I would like to see the problem resolved. It blocks referencing RFC 8865 in other standards.

My latest proposal was the one below. Can it be accepted? 



Proposal from April 2024

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) MUST use even identifier values, and the endpoint acting as a DTLS server MUST use odd identifier values.

SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be 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) MUST use even identifier values in offers, and the endpoint acting as a DTLS server MUST use 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 DCEP MUST NOT be 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] <mailto:[e-mail]> 
Tel: [phone]