What ports are needed to make Zulu 3 work the best.
I look at https://wiki.freepbx.org/display/PPS/Ports+used+on+your+PBX
Says Port 8002, but maybe your RTP ports. No explanation on why “maybe” they either need to be open or not, or is it just if you use chan_sip instead of pjsip.
Q) In what cases will I need to open the RTP ports?
There is another port regarding Zulu Stun server and how port 3478 may also need to be open.
When I first looked at Zulu it looked as everything just ran over 8002 securely, now we are looking to open the RTP ports which is not encrypted.
I just want to know what need to be done to make Zulu work. Opening ports up internally is not as scary as when we open the the public. I’m guessing many of us are looking at Zulu to give the sudden increase demand on teleworking an easy to use and implement solution.
Those ports might needed to be opened if you are having audio issues in your calls. The best way to know this is to try, a support person would be happy to guide thru the best way to set-up Zulu for you, so don’t hesitate to talk to support if anything.
This is the reason why this entire “product” is frustrating. How can this be an “if your having issues”
The Zulu client will use these ports or not. If it uses them as a failover mechanism, then add why it is failing to these in the docs. Not “If your having problems”. I need to know why that “if” might be happening to weight the risk of fixing the “if” or opening the RTP ports. Details are important. If I undergo a security audit and they ask why the ports are open when another client of theirs uses the same product and its not need I can not respond with “Sangoma said if”
When a call is established a process known as ICE negotiation occurs to determine, based on gathered candidates (IP addresses + ports on both sides), what is a viable way to send packets. Essentially both sides sends packets and they figure out which viable paths worked. The one with the highest priority is then used. For having the ports opened it depends on the underlying firewall/NAT properties. If the act of sending packets out the firewall/NAT opens up a mapping that allows bidirectional flow of packets regardless of the remote source, then it can be fine to leave it closed since the ICE negotiation will work. Not all implementations behave the same though so thus why it may be needed to open it up.