I understand the memory issue. However, which is the status of this issue then? Some questions: 1) Assuming that the only difference between FF 67 (it works) and FF 69 (readyState is "connecting" forever) is that in 67 FF indicates out:256,in:2048, and in 69 FF indicates out:12,in:2048, and assuming that the trace in #c8 is similar in both cases with just that difference, why does it work in 67 (readyState becomes "open")? 2) Is there any issue to fix in usrsctp regarding this? May be usrsctp does not honor the out:16 of FF 69 and places in:65535 in the INIT_ACK and FF does not like it? 3) Is there any issue to fix in FF itself?
Bug 1562341 Comment 22 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I understand the memory issue. However, which is the status of this issue then? Some questions: 1) Assuming that the only difference between FF 67 (it works) and FF 69 (readyState is "connecting" forever) is that in 67 FF indicates out:256,in:2048, and in 69 FF indicates out:12,in:2048, and assuming that the trace in #c8 is similar in both cases with just that difference, why does it work in 67 (readyState becomes "open")? 2) Is there any issue to fix in usrsctp regarding this? May be usrsctp does not honor the out:16 of FF 69 and places in:65535 in the INIT_ACK and FF does not like it? 3) Is there any issue to fix in FF itself? 4) How is Firefox supposed to work if more that 16 DCs are desired by the app? Will it use SCTP_ADD_STREAM request so the remote peer must allow it? (currently we reject such a request). 5) Which exact behavior does https://phabricator.services.mozilla.com/D36517 change?