Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTCSctpTransportState: state transitions? #635

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

Comments

Projects
None yet
3 participants
@aboba
Copy link
Contributor

aboba commented Jan 11, 2017

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

This comment has been minimized.

Copy link
Contributor Author

aboba commented Jan 11, 2017

@robin-raymond @lgrahl What do you think?

@lgrahl

This comment has been minimized.

Copy link
Contributor

lgrahl commented Jan 11, 2017

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

This comment has been minimized.

Copy link

pthatcherg commented Jan 12, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.