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.

Sign up for GitHub

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

Jump to bottom

Handle new-initiator/new-responder correctly #61

Open
lgrahl opened this issue May 23, 2019 · 1 comment · May be fixed by #64
Open

Handle new-initiator/new-responder correctly #61

lgrahl opened this issue May 23, 2019 · 1 comment · May be fixed by #64
Labels
bug

Comments

@lgrahl
Copy link
Member

lgrahl commented May 23, 2019

When a 'new-initiator' or 'new-responder' message has been received, the initiator/responder simply replaces the corresponding instance but does not reset its own state.

Due to a limitation of the implementation, after the task has kicked in, it should also...

  • drop the responder in case it is an initiator, and
  • close the connection normally in case it is a responder.
@lgrahl lgrahl added the bug label May 23, 2019
This was referenced May 23, 2019
Open
Open
@dbrgn
Copy link
Member

dbrgn commented Jun 6, 2019

Good point. I assume with "its own state" you mean some fields in the Common struct.

If I'm not mistaken, if the task has not yet kicked in, we only need to reset self.common.signaling_state.

@lgrahl lgrahl self-assigned this Jun 13, 2019
@lgrahl lgrahl linked a pull request Jun 13, 2019 that will close this issue
Draft
@lgrahl lgrahl removed their assignment Jun 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Handle new-initiator/new-responder correctly saltyrtc/saltyrtc-client-rs
2 participants
@dbrgn @lgrahl