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

Subsequent hold/resume calls fail. #4

Open
surfrock66 opened this issue Jan 21, 2022 · 2 comments
Open

Subsequent hold/resume calls fail. #4

surfrock66 opened this issue Jan 21, 2022 · 2 comments

Comments

@surfrock66
Copy link

We were making some modifications to our interface to support multiple lines when we discovered a bug in hold/resume.

If you're on a call, and hold the call (button OR console command oSipSessionCall.hold(); ) it works fine. If you then resume the call (button OR console command oSipSessionCall.resume(); ) it also works fine. Then, if you try to re-hold the call, the hold button freezes and the entire sip stack begins acting strangely. The function calls seem correct, we enter the hold() code, but nothing happens, and we get a sipStack Event of "m_stream_audio_remote_added" instead of "m_local_hold_ok". We actually have to unregister and re-register to be able to start making calls again.

We reverted all changes we made and tested using the upstream library and experienced the same issue. Is anyone else experiencing this?

@surfrock66
Copy link
Author

Subsequent research gave more insight; we had been testing with a recording line, but upon testing with a real recipient we learned that the mic never wakes up on resume. The documented behavior is:

Start Call, both local audio and remote audio work.
Place call on hold, local and remote audio stop, the stack receives a hold_ok.
Resume the call, remote audio returns, local audio never starts sending, the stack receives a resume_ok.
Place call on hold again, remote audio remains, hold button never converts to "resume" button and remains in the disabled state.

We are researching the re-activation of the local audio stream as the potential culprit.

@surfrock66
Copy link
Author

We fixed this by making the resume asynchronous and using "replaceTrack" instead of "addTrack" which adds another Sender, instead of updating tracks in the existing sender. We think this is a change from the WebRTC API from when this was originally developed. Our commit is a giant bundled commit so a pull request isn't gonna just work easily, but the code is here on line 450 of this commit: L1kMakes@6fd731d#diff-0ca66776a62cfb4af660b32adc09131b21a58c29741db80e237ee710eb2ce5e6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant