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

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

Can this proposal for 6.1 in RFC 8864 take us closer to a solution?

The proposal has the ambition to establish a procedure for a low risk 
for stream ID collission even when mixing SDP and DCEP channel 
negotiation/establishment.

Current wording:


6.1 Managing stream identifiers

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.


   ----------------Proposed wording------------------------

6.1 Managing stream identifiers


SCTP stream identifiers associated with data channels that have been 
negotiated using DCEP MUST NOT be included in SDP offers and answers.


In order to keep risks for SCTP Stream identifier collisions low, the 
following actions shall be applied:


- When SCTP Stream identifiers have been assigned through any 
mechanism,  then even STCP stream identifiers MUST be used in SDP offers 
from the endpoint which initiated a data channel establishment resulting 
in an even SCTP stream ID. Odd STCP stream identifiers MUST be used in 
SDP offers from the endpoint which initiated a data channel 
establishment resulting in an odd SCTP stream ID. The answering parties 
MUST use the same SCTP stream ID as received in the offer.


- If no channel has been opened on the association, the SDP negotiation 
MAY use even or odd SCTP stream identifiers in the initial SDP offer. 
The answering party MUST use the same SCTP stream ID in the answer as in 
the offer.


- collisions MUST be handled by the usual mechanisms used to avoid SDP 
signalling glare.

--------------End of text proposal------------------------

Questions:

1. Can we hint or specify which the usual mechanisms for avoiding SDP 
signalling glare are?

2. Can we describe in a proper way that the WebRTC API and stack with 
negotiated=true option shall be used to establish data channels after 
SDP negotiation if DCEP may be used later in the same association. I 
think that would be a useful information to include here.

Regards

Gunnar


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