Search results

Have you set a specific caller ID in the outbound route? If not, this should just work. Check the outgoing invite to the carrier with SNGREP to see if it is being sent to the cariier correctly and maybe the carrier is overriding it.

What are you trying to achieve her by using specific outbound routes, is it just to get a different caller id or is there another purpose?

Hi

Cache files on new systems are in /var/cache/fusionpbx That is the directory you want to empty.

Show us the actual message rather than the flow. Press F6 on the invite

So you have a destination configured for 18555285538? That is what they are sending it as? If you have the destination set up, post a log from fs_cli.

We need the detail not a picture. Inside the register press F6 and paste that.

Post some logs when doing the forwarding, preferably using sngrep of the attempt to register to the provider.

Which bit is not working? eg, is the privacy id set in the outbound invite, etc?

What is this order 195 you are referring to? Your 195 may not be the same as mine. Everything that you can set in the webui should be available to set in provisioning, variables may need to be added to the template if they are not already there but it is doable. The gui helps with this. For...

Hi, Everything is probably working as expected. I'm not familiar with Grandstream but it looks like the phones are set to autoprovision at boot. Ideally, you want the BLFs etc set in the device config so that the server provisions the buttons otherwise you will always face this situation when...

In that case you are better sticking with agree's suggestion.

But why not just create separate destinations for each number? If later you need to change the destination it is easier?

Yes, it is exactly as described, destinations create inbound routes.

?

This is now fixed

This is now fixed

This issue has been confirmed and is being worked on currently, expect a fix shortly

This has been confirmed and @markjcrane is working on it right now.

If register is being used and the traffic is coming back to port 5080 then the implication is that port address translation is not being used, either that or some sort of ALG is in play though I doubt it because of the port 5080. Are you able to switch the transport to TCP? That would almost...