im having the exact same issue with android failing to connect on first try. did you find any solution. i also have a ticket in with sangoma but the tech hasnt been able to fix the issue just stating that when he connected his android phone to my pbx it worked fine…
Sangoma support has been running tests on our PBX for approximately one week. So far nothing conclusive.
I have a 6 step process to reliably recreate the bug that you can give to your Sangoma Tech.
If I follow these 6 steps, I can get 2 way audio to fail every time.
1 - Phone must be Android. I-Phones do not appear to have this issue
2 - Sangoma app is the ONLY app installed
3 - Phone MUST be on Cellular Data (not WiFI), WiFi MUST be turned off at the phone level.
4 - Phone must be locked for a minimum of 10 minutes
5 - Alarms, Badges, Alerts and notifications must not disturb the phone during the 10 minute minimum lock duration.
6 - An incoming call alert from the Sangoma Talk app is allowed after the phone is locked and undisturbed for 10 minutes
Also give your Sangoma tech the link to this video to show how to recreate the error;
Dropbox - SangomaTalk_AndroidAudioIssue-O.mp4
Please confirm that you cpatured traffic on your WAN interface (as I requested 7 days ago) and RTP did not arrive from the mobile.
Are you saying that it doesn’t fail from their test phone (presumably on a Canadian mobile carrier)?
Please confirm that it works ok on a remote Wi-Fi network.
I think this problem is caused by new energy saving “features” of Android. I had a similar problem with my eNotify app. My Oneplus phone
has Oxygen 13.1/Android 13 installed. There are relevant settings for apps at two different locations…very confusing.
Yet…you say that the app loads correctly…
I got distracted with other troubleshooting ideas and neglected to respond to your post.
When audio fails, I confirm packets do not arrive at the PBX.
All wifi networks, even internal corporate WiFi are remote to the PBX.
The problem does not manifest itself when the phone is on WiFi.
Sure, but have you confirmed that RTP from the mobile does not arrive at the WAN interface of your firewall?
A video update and a follow up video to my original video.
I had some people reporting back that they tried to recreate the bug but could not. I found they were not following the steps required to recreate the bug.
My previous video touched on some concepts but I failed to explain the importance of adhering to a few key points. Not adhering to the specific criteria I outline here will cause a test to fall outside of the control group for creating this bug.
This NEW video attempts to eliminate any ambiguity and shows how to recreate the bug with 100% accuracy.
The search for a solution continues.
Today I used FreePBX’s internal packet capture. Here is what I found.
This is a packet capture when Audio Fails;
This is a packet capture when Audio Works!;
I don’t know what filter you used, but the result has no useful information.
Here is a packet capture taken under the conditions where you observe a failure, except that my phone has other apps installed, and is running Groundwire, not the Sangoma customized version.
Notes:
192.168.88.160: LAN address of PBX
159.89.179.103: Acrobits SIPIS server
77.136.66.238: Address of mobile carrier’s IPv6->IPv4 gateway (SFR France)
Redacted info: Domain name and SIP listen port of PBX
Pkt 36 is INVITE sent from PBX to SIPIS
Pkt 38 has X-Sipis-Push-Status: Alerting-Device
Pkt 40 has X-Sipis-Push-Status: Push-Notification-Sent
Pkt 44 has X-Sipis-Push-Status: Device-Making-Progress
Pkt 85 is answer from mobile device (relayed by SIPIS)
Let me know if you want any other details about this capture.
The filter used is the IP address of the Android phone
You fall outside of the control group for creating the bug for one possibly two reasons.
(1)To recreate the bug, the Sangoma Talk must be the ONLY 3rd party app installed.
(2)You are using a derivative comparable product. Supposed to be functionally identical, but possibly not.
You did give me an idea of something I could try. I am going to test Groundwire to see if the issue is the same.
@lgaetz @Stewart1 @jackcampbell
Sangoma Talk - Audio continues to fail under the parameters of the control group
Acrobits Groundwire - Works perfectly and does not fail under the parameters of the control group
Sangoma Talk is Version 1.0.8 build 1820065 ci 1903
Acrobits Groundwire is Version 6.2.3 build 2015930 ci 139141
It would appear Sangoma needs to go back to Acrobits and get new version white label of Groundwire.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.