mc_: Do you know by any chance if v5 will have updated push notifications?

Serge: websocket or mobile push?

mobile push\

yes, we've added a couple more...new vm, missed call, and an API to send arbitrary notifications to the phone

not sure what's in 4.3 still

in 4.3 you have only old legacy pusher

i don't know what's going on with the google integration, that's a good question

pn-tok is not used anymore in current firebase pusher, they start use pn-prid

it is in RFC8599

freeswitch port 11000, where should it be open? Does end users use it when make a call?

is it just interserver communications?

Serge: 11000 can be open but generally we recommend just between kam/fs and force all public SIP through kam

certainly for registrations

some send direct FS to carrier though, but carriers should send to kam for inbound

so, iff my clients use port 7000 only, can I block port 11000 with iptables?

in all in one node?

i would, no public inbound connections to 11000, only from kam IPs

Serge it's a good idea to allow your carrier[s] IP[s] to access port 11000 on Freeswitch, as well as all other Freeswitch servers. The reason for carriers is that on an outbound call IF your firewall times out the SIP connection during a call, and the carrier sends a reinvite (often after 10-30 minutes on the call), if the carrier can't reach Freeswitch it will kill the call. The reason to open 11000 to your

other Freeswitch servers is that if there is a conference call, and a new call comes in destined for the conference, but first ends up on a different Freeswitch server, the system will direct that FS server to transfer the call to the FS server where the conference is.

mc_ does the above sound correct? Or have things changed and this is no longer needed?

ruel, as I know carrier will send reinvite to port which is specified on your carrier settings, i.e. port 7000

For inbound yes, but outbound calls go directly out from Freeswitch remember.

Of course it doesn't apply on an AIO server, just clustered.

(I should have specified that, sorry.)

But yes, on a single server, with IP auth, then the carrier should send the reinvite to the Kamailio port.

ruel: at most, i would allow FS to send INVITE to carrier, but even that isn't recommended as much

in our newer clusters, everything proxies through kamailio

as far as i know, we haven't observed calls terminating due to firewall timeouts

between kazoo/carrier, that is

really? So you're doing something like fs_path for outbound now?

Or is it a change in V5 that automatically does it? That does eliminate some complexity with having calls originating from different places than they come into the system.

tbh i forget the mechanism, but yes, effectively an implied fs_path=kam.ip

i think its an opt-in system config thing

but its default on for our installs now

ah ok nice