Signaling is done with pjsip TCP port. You can change the binding at Asterisk SIP Settings and restarting Asterisk.
I am at the stage where the app says “You will receive an email with the deeplink. Please open the email on your mobile device and click on the link”.
The email arrives and contains the same invitation as the first one I got after I clicked “Invite” from user manager. Clicking on the “Login Link” returns “API server… not connected for session. Please make sure Clo”.
I don’t recognize that error, and I just confirmed that all is working on this end. Please open a support ticket so we can review in depth.
https://wiki.freepbx.org/display/FPAS/How+To+Open+A+Support+Ticket
Now it’s working, I had to reinstall the module cause the Cloud Connect Agent Status was stuck at installing… 0%.
1 Like
So whatever bind port I have for PJSIP, that is also the destination port where the client will send PJSIP tcp registrations to.
It might be useful to be able to keep the pjsip bind port internally at default 5060 but pick a different external port to where inbound invites/registrations will be sent to.
E.g. we have our PBX behind a NAT router and Asterisk signalling bind port at 5060. We are not using the freepbx firewall and probably won’t be.
Considering the security implications of having to have a port forwarded without whitelisting IP addresses it would be good to have the possibilty to change the destination port that packets will be sent to on the external firewall but leave the pjsip bind port unchanged, cause changing it on a production system would be too inconvenient.
Edit:
Please forget what I said. It’s TCP but everything else is on UDP so it’s no problem using a different bind port.
Since the SIP signaling port is included in the SIP packets, the only way this would work is if the router fixes the SIP packets on the fly as they pass thru the router. That’s what a SIP ALG does, and they are notoriously poor at it.
The PBX Firewall with responsive enabled works fine. With Intrusion detection configured in System Admin, that’s a solid second line of defense. You could add a dynamic blacklist as another layer of security.
1 Like
I forwarded the TCP listening port to my router and the Sangoma-Connect-app can now connect to my freePBX server. I can also make and answer calls…yet, there is no audio! Any hints?
Audio uses the same RTP port range as all other SIP clients, 10k-20k by default. Those ports must be forwarded as well if they are not already. Also confirm you have the correct NAT config in Asterisk SIP Settings.
ok, thanks…I usually dont do port forwarding at all…I dont feel comfortable with so many ports open!
We are having a problem where we do not get any inbound calls. The mobile app will register and connect just fine. We can make internal and external phone calls with all audio working. The only issue we are having is that the app does not ring when we get inbound calls. No inbound calls are working at all but everything else is working. Any thoughts on why this would be?
Open a support ticket please. Anything I do here would just be a wild guess, but registration without calls sounds like a SIP ALG on the router to me.
I’ll open a ticket… I don’t know why it would be SIP ALG. The server runs in the cloud with a dedicated public IP and the phone was on LTE so nothing was behind any router. It does the same when behind firewalls but SIP ALG is the first thing I disable on Unifi USG Pros when we install them.
I’m having issues with the app on my Android. It works great unless I minimize the screen to check email etc. then it seems to close and does not ring on inbound calls. If I leave it open and my phone screen locks the app closes and does not receive inbound calls.
Is there a setting I’m missing?
Open a support ticket pls. When the app goes into standby, the push servers take over the registration and then relay the ring to client, my guess is there is something going on with the push registration(s).
Dumb question but I’m not sure where to open the ticket. I can’t find Sangoma Connect under FreePBX support, it’s not listed under Commercial Modules.
Open it as a zulu ticket.
We use Bria Enterprise across our company, but we intentionally have Push disabled. So long as the client is configured correctly, at least on Android and so long as Google doesn’t f*** it up later, push services aren’t necessary. Sure, Push can make your life easier, but it does come at a number of potential costs that should not be ignored. It might be just fine for most but still entirely unacceptable for others, especially of a security mind-set.
For example, use of interceptive push services requires explicit case-by-case approval if you are an employee or contracted by certain government agencies and intend to use such services for official communications of any kind. So, it’s not unreasonable for any of us to want to know what is and is not being routed through someone else’s server beyond our own. Our company manages clients for a number of HIPAA/HI-TECH compliant agencies and a few gov and gov-adjacent agencies. Disclosure of this type of information is important to us and those clients.
To question a tossed about statement of “absolute necessity” is also not even the least bit outrageous…and I’d argue that absolute trust is even more dangerous. Not all of us are ready to hand everything over to a system we have no control over…anybody who has lived through the makings of Google’s Graveyard can attest to the need for autonomy in some cases. In the world of cloud services, “here today; gone tomorrow,” is the understatement of the f’ing century. #ProveMeWrong 
I marvel at the ease with which folks these days have forgotten that a PBX is a piece of critical communication infrastructure for most of the people using it…and should be treated as such. I’ve never been one to blindly accept the “because everyone else is doing it” excuse.
Serious question here. I have a mobile client that “always works” or at least, has “always worked” once I setup my FreePBX server. (I am not exactly sure WHY you think that an on-prem solution doesn’t “always work”: but perhaps you have a lot of people deploying FreePBX who don’t know how to build reliable on-prem servers. Not my problem, though!)
Anyhoo, It appears to me that the “free 2 user trial” is 1 year only, and after that you have to buy a minimum 20 user Zulu cloud PBX?
But I don’t WANT a 20 user cloud PBX. My on-prem FreePBX cost nothing and I like it and want to keep it. Is there a way to get a “perpetual” 2 user license of Zulu so I can just use Sangoma Connect on a single mobile phone as a permanent soft phone app?
My current Android softphone app I use with FreePBX is CSipSimple. It works well but of course, I wouldn’t be adverse to paying a bit of money for a softphone app that was better and worked with FreePBX. If Sangoma Connect is better and had a “buy-once, no ongoing subscription” price that was reasonable I’d give it a whirl.
Anyway, thare ya have it. No chance of getting me to chuck my on-prem PBX and go 100% cloud - possible chance of getting me to pay a bit of money for an app. So my question is, do you honestly want to sell softphone apps or is this just a sort of hook to try to sell cloud PBXs which you are never going to get me to pay for? Because if it’s the second I don’t want to spend the time on it.
Hi Ted
At present we have no plans to sell a perpetual license for either Zulu or Sangoma Connect. There will probably be changes to license pricing once Sangoma Connect goes to general availability, so I will pass your comments onto the product manager for consideration.
Thanks! I would not expect a perpetual license for any cloud service of course. But the app doesn’t HAVE to use the cloud servers if it connects to an on-prem server since it can get all it needs from the on-prem server. Making it connect is your guys choice not mine. Whatever it’s getting from cloud can simply be made unavailable.
Keep in mind that Microsoft originally claimed Office 2021 was going to be subscription only - and backed off from that 4 days ago:
Your managers really should consider that if Microsoft is sensing “software as subscription fatigue” that the software subscription market expansion is probably pretty much done, and additional FUD that “everyone is going to cloud” isn’t going to expand the Zulu cloud PBX market.
Cloud has a place - for some. But not for all. Please tell the product manager to try to remember that. I look forward to seeing future offerings.