Search results

You could look into uuid_broadcast which seems to be async, you can use it to execute another dialplan. The examples in the docs look promising; https://freeswitch.org/confluence/display/FREESWITCH/mod_commands#mod_commands-uuid_broadcast

Just curious what system they were working with prior to switching to Fusionbpx? In my limited experience, Cisco voip phones are a pain in the ass when it comes to SIP.

It is possible its either your firewall or a firewall the customer is using. I guess it couldn't hurt too much to whitelist all the traffic from their IP to see if that helps, if so then go from there to further refine the access. CSF is probably a bit overkill for a simple voip server, but if...

I did search before posting, didn't find it. Just did another search, still found nothing. Any applicable search terms you could provide to help narrow the search would be helpful. Thank you, this is very helpful and to the point. Much appreciated. It seems straight forward enough that I'll...

Hi all, I have a call center queue setup using the "callback" type, where the agents are signed in all the time (they never signout). The agent extensions also have "Follow-Me" enabled, whereby if their extension is not registered then it is diverted to their remote extension (on their cell...

That was definitely it, thank you very much. I had assumed being the `admin` user granted me all permissions, turns out there was a few random ones I was missing.

I'm trying to modify an existing inbound destination via fusionpbx. Whenever I attempt to save changes it gives me the following error; For context, here is a screenshot of the config I'm attempting to save; The error message doesn't really make sense to me, as a destination is defined. Is...

Sorry for the late update, I was impacted by some recent bushfires here in Australia. Anyway I did have a chance to look into this again, and through-out my testing I happened to switch the external endpoint to use TCP instead of UDP. This caused it to work straight away, which is rather...

I have now done a packet capture on the WAN of the router, and I am seeing the ACK's are being sent to port 5090(on the router) by the external handset. These packets are being allowed through the firewall, but I have disabled the firewall for the time being. At this stage it seems either the...

Thread no longer required. Please delete

Up until now I had just been using siptrace in fs_cli. So I did a packet capture on the pbx, internal handset, and a siptrace on the external handset. I've discovered that the external handset is indeed sending ACK's in response to INVITE's, as shown in the snippet below; Below is a screenshot...

I believe I have resolved the issue with the wrong IP being sent in the "Contact" header. I did this by changing the ext-rtp-ip and ext-sip-ip in the internal profile to be "auto-nat". (I previously thought it was "autonat" which caused me issues). For the external profile they are still set to...

Yes, the external5090 profile is listening on port 5090. The idea behind the 5060->5090 port forward rule is to allow roaming handsets to not configure which port to connect to, they can leave it as the default (5060 for a lot of clients) and it will work whether they are external (elsewhere on...

I think you're right about the ACK's being mis-routed, as per my last reply. I suspect the incorrect "Contact" header is set by the internal handset which assumes the other endpoint is also on the LAN. I assume there's some setting in the PBX to rewrite this header to the correct value, but...

It appears as thought the pbx is sending the internal IP in the "Contact" field, as seen below. I suspect this causes the external handset (the one which initiates the call) to send an ACK to the given contact address (which is not correct as far as the external handset is concerned), therefore...

I have tried disabling the firewall on the router, it makes no difference.

Hi all, I'm having a problem where calls are dropped after 30 seconds, even though 2 way audio is working. I suspect it's somehow a NAT issue, and by doing a siptrace I was able to determine that the call is being dropped due to no ACK being sent by the external handset. I can't figure out why...