Audio Issues with Sangoma Talk

Commercial Modules Sangoma Talk / Software Phone
1

I have been using Sangoma Talk Iphone for several weeks without an issue.

I had received complaints about Android phones not connecting when waken up by push notifications.

Sooo… I purchased my first ever android phone and set it up with Sangoma talk. I now have I-Phone and Android setup side by side on the same network, both with Sangoma Talk installed.

If I close the IPhone App, push notifications loads the app, and I can answer an incoming call, audio works in both directions. The log shows SIP connection via the Sangoma Digital Ocean servers. I-Phone app works PERFECTLY!

If I close the Android App (and let the phone sit for 10 minutes), push notifications loads the app, but audio does not connect in either direction. The android phone receives the Push notification via the Sangoma Digital Ocean servers, but does not have SIP audio through the Sangoma Digital Ocean servers. When the app is closed, and woken up by push notificaiton, SIP does not properly go through the Sangoma Digital Ocean servers. (keep in mind this works perfectly in the I-Phone app sitting side by side to the Android). I noticed the registration through the Digital Ocean Servers expire after 600 seconds. It would appear that after this registration expiration, the SIP connection via the Digital Ocean Servers stops working, but the Push notification continues to function.

For the android app to have audio in both directions, I have to open the App and have the app in the foreground which does successfully connect directly between PBX and the Android App. (OR) route through the Digital Ocean servers within 10 minutes of the registration.

It would appear the Android app does not re-register to Digital Ocean servers once the phone is locked and/or the app is in the background.

What logs do you need to see to help diagnose this?

2

Did you look at this?
Audio issues on some Android Phones - Sangoma Softphones - Documentation (freepbx.org)

If you have and that’s not it, I think you need to engage Sangoma directly for this. The softphone comes with support.

Sangoma Soft Client Feedback - Sangoma Softphones - Documentation (freepbx.org)

3

Definitely not an Android platform wide issue. Ive veen using Sangoma Talk on Android for years without a single issue and use it daily. No audio issues… Ive used it on Samsung Galaxy S21, S22 and S23 Ultra 5G…

4

Thanks comtech. I checked the settings you suggested. All was set correctly.

I’ve opened a support ticket with Sangoma.

Ill wait to see how they want to proceed.

5

To provide more context to this issue, I have been able to narrow down how to recreate this bug.

Both the iPhone and Android using cellular data. Both are using T-Mobile.
iPhone - Works
Android - Audio fails if the phone is locked for 10 minutes or more

Both the iPhone and Android using wifi;
iPhone - Works
Android - Works

I’ve had a support ticket in with Sangoma for 23 hours and 32 minutes, so far no response.
Case Number 01499737

6

2 days now getting ready to roll into our 3rd day. No contact from Sangoma Support.

7

What does Digital Ocean have to do with it?

8

Their is no DO or VULTR FreePBX issue. I have deployments running just fine for years. Active working production systems right now. You have some other issue, most likely setup, firewall, etc…

9

Digital Ocean servers do the Push notifications and sometimes is the route for the SIP traffic.

Its not a firewall issue, remember iPhone app works just fine.

3rd day past now going on our 4th day. No contact from Sonoma support.

10

Ive made a video to show this bug.

The video first shows you that Sangoma Talk does function as desired, then I show you how to create the audio failure.

Dropbox - File Deleted - Simplify your life

The video player below may not function, so the link above is provided as an alternative.

11

Works fine here, but I noticed that the INVITE sent from SIPIS has a private (CGNAT) IP address in the SDP, likely related to the mobile network being IPv6 only. This doesn’t directly cause trouble, because when the app starts sending audio, Asterisk starts sending audio back to the IP address from which it is coming.

Please confirm that in your router/firewall, you have Asterisk’s RTP port range (default is UDP 10000-20000) forwarded from any external address to the LAN IP address of the PBX. Also that RTP Symmetric for the remote extension is Yes.

If you already have these settings or they don’t help, at the Asterisk command prompt type
pjsip set logger on
make a failing test call to the mobile, paste the Asterisk log for the call at pastebin.com and post the link here.

12

Stewart, thank you, the command pjsip set logger on was what I needed to figure this out.

Turns out when Sangoma Talk is installed in the PBX, it makes 8x incorrect firewall entries for digital ocean servers. Im guessing digital ocean servers were originally used along side the acrobits servers but have since been replaced by acrobits servers because the 8x replacement IP addresses are all acrobits.

The incorrect entries are;
107.170.65.67
107.170.123.70
107.170.151.176
162.243.35.55
162.243.66.221
162.243.226.67
167.99.48.91
192.241.179.113

The correct entries to replace the above mentioned incorrect entries should be;
165.227.182.9
165.227.223.68
159.89.179.103
165.227.65.164
165.227.115.186
165.227.190.186
159.65.167.207
165.227.210.221

13

This is unrelated to your present audio issue. These addresses are used to register to the PBX on the user’s behalf. If they were blocked, the called phone would not ring (or show any indication of an arriving call). If the needed firewall entries are missing, I’m guesssing that you have Responsive Firewall enabled, which allows the registration to complete and incoming INVITEs to pass.

Did you determine that you have UDP ports 10000-20000 properly forwarded in your hardware router/firewall? Make/model? Any VoIP-related settings? Does it have a public IPv4 address on its WAN interface?

14

Well Stewart you are correct. Our issue is not resolved… Bummer…

We don’t use ports UDP 10000-20000 our SIP provider uses ports 16384 - 32768 so we follow the sip provider’s precedent and use the same port range.

The log is at this pastebin link; FreePBX Sangoma Talk Log - Pastebin.com

15

I don’t understand what actions you took that didn’t resolve it.

Please confirm that your hardware firewall has a UDP port forwarding rule:
Source address (any), source port (any), destination address (public IP of the PBX), destination port (16384-32768), forward-to address (LAN IP of the PBX)), forward-to port (unchanged).

Also confirm that the WAN interface of the firewall has the public IPv4 of the PBX.

If the above is correct and you still have trouble, please post details of your networking equipment.

16

Stewart,

We expose specific IP addresses, we don’t leave the PBX exposed to (any).

We have exposed the acrobits IP addresses and T-Mobile-USA IP addresses.

There is no port reassignment or port changing in the firewall. Its port for port straight through.

The WAN interface on the firewall has the public IPv4

I’m looking at your troubleshooting ideas, and thought it important to remind you, please remember the iPhone app does not have this issue.

17

Capture traffic on the WAN interface and report whether any RTP arrives from the mobile.

18 
v=0
o=- 2023604002 22073 IN IP4 xxx.xxx.xxx.170
s=xhpmgcu
c=IN IP4 192.0.0.4

The SDP from your Sangoma Talk phone has 192.0.0.4 in the c= line (the o= line, which you x’ed out, is not used for the connection). This may be an IPv6 gateway address, and not routable. But since it’s not CGNAT or NAT (RFC1918) the software may not realize it’s dealing with a non-routable address.

Running tcpdump or tshark on the pbx to look at traffic flows may reveal what’s happening. Is Asterisk trying to send media to 192.0.0.4? Is it getting any media from the phone?

Also, compare with logs captured when using the iPhone. What looks diferent?

19

All good ideas.

I want to keep the thought that iPhone app works and never fails in the back of our mind. But lets not use that for our baseline.

I decided to use the baseline that the Android App always works when the app is in the foreground, and audio always fails when the phone is locked for ten minutes.

I just did a very slow and methodical line by line comparison of a log (pjsip set logger on) with the app in the foreground and audio connecting and a log (pjsip set logger on) with the phone locked for 10 minutes and audio not connecting.

Both logs are identical from ringing (to) State: terminated

20

I dove into the logs that the Talk App have available on the phone itself. There are differences here between when the app functions properly and when it does not.

The highlight is a Audio Mode Switch Failure.

App In the foreground - Two way audio works
Info
AudioModeManager
2023-11-10T22:59:39.924Z (1699657179924346)
Origin: AudioModeManager.java:203
Mode switch successful, new mode MODE_IN_COMMUNICATION

Phone locked for 10 minutes - two way audio fails
Warning
AudioModeManager
2023-11-10T23:15:09.230Z (1699658109230821)
Origin: AudioModeManager.java:208
Mode switch failed, desired mode MODE_IN_COMMUNICATION