We are using jssip 3.3.4 to handle incoming calls.
We are seeing a few systems where the call is not answered when the user clicks the answer button.
The answer button essentially does:
session.answer(callOptions);
session.connection.addEventListener('addstream', function (e) {
console.warn('call answered');
});
On most systems we see the log message 'call answered' and life is good.
On a small number of windows systems (windows 10 1909) the addstream event doesn't fire and we don't see the log message 'call answered' and the call also isn't answered.
We don't think the problem is network related because in at least one instances we have two pc's in the same office. One works and one doesn't.
The SIP server is asterisk 16.
I know that the event addstream is deprecated in favor of the ontrack event see RCT docs. Try switching the events does that fix the problem?
Related
I just pushed my new updates on play store and all over sudden am getting this error, I have tried to research online for answers but I get non, any help what this error means and how to fix it?
Any help and guidance on how to fix this is highly appreciated
I'm glad to see others have been impacted and it was not just me!
It seems to be a bug with the Google review system. Best thing to do is contact them via the link to their form in the footer of the email you received.
Update 2:
I did not take any action and passed the review process today.
Update 1:
I received the reply I have screenshot below, which does not help much. I asked what the notification was about and he did not address the issue at all, so now I don't know what to do. However he did confirm that my app was currently in the review queue, so maybe we just need to wait. Maybe the email notification with errors can be ignored. I will wait a few days to see if my app passes review without taking any further action.
I've just updated my Data Safety forms adding Device or other identifiers because my app request Ad Id, BSSID etc.
I've faced the same issue, and the solution is :
You need to check if you're using third-party libraries (in my case, IronSource and AdMob) that collect the user data.
If you're using IronSource you need to fill the Data Safety from here :
https://developers.is.com/ironsource-mobile/general/google-data-safety-questionnaire/
After you fill the Data Safety, hit the save button and wait for the review to complete.
I was recently investigating an issue related to a delay in rendering a welcome/greeting message for the first time when webchat is launched. The very first activities network request (before showing the welcome/greeting message) is usually 2-6s long(mostly it's either 2.5s or 5-6s). We are trying to implement this using BotFramework webchat version: 4.10.1 with react (minimizable version).
What I'm trying to accomplish is to load welcome/greeting message faster than the current time and upon checking the performance profile I found that activities network request(directline.botframework.com/v3/directline.../activites) is taking either ~2.5s or ~5.5s and after that, there is some more buffer time in between before the welcome message gets rendered.
I tried to record the performance profile of both cases(2.5s/5-6s)
2.5s
https://i.imgur.com/InEyHxl.gif
5s
https://i.imgur.com/yl3l6Z8.gif
Trying to find more information on how to improve/fix this behavior and gain more insights on this. I would be really glad if anyone can share your thoughts on this issue. Please let me know if I need to provide more information.
This is probably a bug that should be solved in a more recent version of webchat
bugreport in github
I want to turn off the display at a particular point using DisplayRequest.RequestRelease but im getting various exception. When i tried for desktop im getting "Arithmetic result exceeded 32 bits" error. In phone im getting system.excecutionEngine exception. I need to know the correct usage of this function.
There are two things wrong here.
DisplayRequest.RequestRelease is used to release a previous request to keep the display alive. If you haven't called RequestActive before, then it won't work and will throw the exception.
If you are doing it to release a previous call, then it's possible that things are going wrong after a suspend operation, because you may have inadvertently called RequestRelease in your OnNavigatingFrom member. Please see my blog for full details at Most of my Windows 8 Apps are broken. Yours probably are too
I have run into an Interesting scenario. Its also present here by someone on msdn forums
When I launch my application, if I lock the screen or if a call comes at that time and on resume after unlocking or disconnecting the call in respective scenarios, the application crashes throwing 0x8000ffff error. This I have observed also happens when an emailcomposetask is open from my application.
Previously I thought that it was because I was not handling Obscured and Unobscured. But now that I am handling them, still I am receiving the same case. I have observed that many other applications also crash but there are some applications like Facebook and Twitter which are able to handle it. Has any one faced this same situation? Can you please provide me a fix for this?
Am I doing anything wrong?
also note that I have changed my default loading page. Its not mainPage.xaml but xyz.xaml, where I am checking for tokens and redirecting user to mainPage automatically without any button click.
Edit : Added StackTrace
at Microsoft.Phone.Execution.NativeEmInterop.NotifyFullObscurityChanged(Boolean isObscured)
at Microsoft.Phone.Shell.PhoneApplicationService.OnFullObscurityChanged(Object sender, LockStateChangeEventArgs e)
at Microsoft.Phone.Shell.Interop.ShellPageManager.ShellPageCallback_OnLockStateChange(Object source, LockStateChangeEventArgs e)
at Microsoft.Phone.Shell.Interop.ShellPageCallback.FireOnLockStateChange(Boolean fLocked)`
This mainly happens because of the code in OnNavigatedTo() and Page_Loaded() event handlers. Place break points and check for the issues in those two methods.
When an app is resumed in the cases you mentioned, these two methods are called in the same order.
Hope this solves your problem.
Update based on your comments:
There you are. You are clearing the entire Navigation history, and hence it dont know where to go now(even the current page is removed).
My suggestion is, Move your back history removal code from OnNavigated to the Page_Loaded event.
I'm seeing an odd behavior in WebKit (on Android) where my server process is sending it a response that it needs to handle immediately (rather than wait for readyState 4). In Firefox and Safari this works as expected, but on webkit, not only does it not respond to the readyState but instead it appears to fire off a repeat request to the server!
This only seems to happen when the server takes a little while to react to the request. I'm still poking around to see what the exact circumstances are that bring this about, but am curious if this is a known bug and what, if anything, is a workaround.
[EDIT] This is just getting weirder and weirder. As long as the server responds within about 10 seconds, everything is fine. But if it takes longer than that, then the request is resubmitted. However, the browser appears to not be aware of this re-submission, or if it is, it's not reporting it in any way. I attached a unique ID to the request and when it arrives for the second time on the server the id is the same. But it's definitely spawning off an additional call to the server. I'm sort of at a loss as to how to debug this further.
No one has piped in, so. I have fixed the problem by killing the connection from the server side.
So, my solution:
a) client makes call to server (which is a perl.cgi)
b) server code:
print (some JSON for the broswer);
close(STDOUT); #this sends a readyState 4 to the browser and closes the connection.
&methodThatTakesAWhile();
This doesn't explain WHY the browser is misbehaving, but it does get around this particular bug.