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. #360

Open
surfrock66 opened this issue Jan 4, 2022 · 1 comment
Open

Subsequent hold/resume calls fail. #360

surfrock66 opened this issue Jan 4, 2022 · 1 comment

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.

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