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

Lock up of implemented UI. #107

Open
rndthoughts opened this issue Sep 2, 2019 · 5 comments
Open

Lock up of implemented UI. #107

rndthoughts opened this issue Sep 2, 2019 · 5 comments
Labels

Comments

@rndthoughts
Copy link

Describe the bug

I have implemented pjsip4net in a WinForms (4.7.1) application and use the .Build.Start() function to start pjsip from Program.cs. Everything works correctly except I keep getting regular but intermittent UI lockups. I initially thought it would be because there are locks around procedures like "GetCallById" and multiple calls might be deadlocking the UI but i've removed all these and it still happens. I've also run a profiler on the code and I can't see any deadlocks occurring.

It doesn't appear to be a call state change, as it usually happens mid-call. The call is not dropped and the user's can still hear each other. I have no errors logged and nothing in the trace logs. The whole UI just freezes. I think pjsip is being hosted in the main UI thread but I'm not sure why this would lock the UI. Is there a way i can move it to another thread?

To Reproduce
Steps to reproduce the behavior:

  1. Answer/Make a Call
  2. UI locks up mid-call

Expected behavior
UI should stay responsive

Screenshots
N/A
Environment (please complete the following information):

  • OS: Windows 10
  • Ethernet
  • Version - Latest

App configuration (please complete the following information):

  • Either an xml config: [e.g. App.config]
  • or a code config: [e.g. custom IConfigurationProvider, fluent config]

Additional context
Add any other context about the problem here.

@siniypin
Copy link
Collaborator

siniypin commented Sep 6, 2019

Hi Steve,

as a rule of thumb you should run your SIP UserAgent in a background thread and update your UI through a SynchronizationContext making no downstream calls to pjsip4net in callbacks you'd dispatch.

Cheers

@siniypin
Copy link
Collaborator

siniypin commented Sep 6, 2019

I've concluded that it is a decision app developers supposed to make on their own, whether to dispatch events to any SyncCtx present.

@siniypin
Copy link
Collaborator

Here, found some old samples:
https://gist.github.com/siniypin/5f403be8dc6e5b2f802e926c1b7855d3

@rndthoughts
Copy link
Author

Thanks, I'll take a look!

@siniypin
Copy link
Collaborator

Hi Steve,

did it work for you? Care to share your findings?

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

No branches or pull requests

2 participants