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?
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…
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.
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 correct entries to replace the above mentioned incorrect entries should be;
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?
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.
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?
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