RTCSctpTransportState: state transitions? #635

Closed
aboba opened this Issue Jan 11, 2017 · 3 comments

Projects

None yet

3 participants

@aboba
Contributor
aboba commented Jan 11, 2017 edited

My understanding is that when an RTCSctpTransport object is constructed, the value of RTCSctpTransportState is new. Now that start method causes an SCTP INIT request to be sent (rather than this happening upon construction), calling start would cause the value of RTCSctpTransportState to transition to connecting, correct?

What if an incoming SCTP INIT request is received prior to the start method being called? Does the RTCSctpTransport object respond or not? Prior to moving sending of the SCTP INIT to the start method, the RTCSctpTransport object would respond upon construction, correct? But now if the RTCSctpTransport object responds prior to calling the start method, this would imply that RTCSctpTransportState could reach the connected state prior to calling the start method, which seems odd.

So I'm inclined to believe that the RTCSctpTransport object cannot respond to an incoming SCTP INIT prior to calling the start method, and therefore that the the connected state cannot be reached prior to calling the start method.

Does this make sense?

@aboba aboba added the 1.1 label Jan 11, 2017
@aboba
Contributor
aboba commented Jan 11, 2017 edited

@robin-raymond @lgrahl What do you think?

@lgrahl
lgrahl commented Jan 11, 2017 edited

As we're using SCTP SO, the SCTP stack will not respond to an SCTP INIT before making a connect (or usrsctp_connect) call which is done in the start method. Setting the SCTP blackhole parameter to 1 or 2 will also prevent SCTP from sending an ABORT chunk after the SCTP INIT has been received due to the fact that we have never started listening. Setting this parameter should probably be required (this is also what FF does by default, Chromium however does not and I'm not sure why it works). Otherwise, we will most likely see aborted connections because one of the peers was not fast enough. With blackhole on, the SCTP INIT will be repeated several times until the other peer responds. This is the desired behaviour we want to have here, right?

To summarise: The SCTP transport will not be able to technically reach the connected state before calling start, so I agree with you.

@pthatcherg

I think you are correct. the SctpTransport shouldn't do anything until Started.

@aboba aboba added a commit that referenced this issue Jan 17, 2017
@aboba aboba RTCSctpTransportState: state transition clarifications
Fix for Issue #635
ff0c4db
@aboba aboba added the PR exists label Jan 17, 2017
@aboba aboba closed this Jan 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment