Search results

Maybe this will be of some help: http://forum.yealink.com/forum/showthread.php?tid=41461

You should be able to do some fancy stuff on a local vm or something that will reboot the phones using the web gui

Have you created the devices in fusionpbx and chosen the correct template? Have you even checked provisioning is enabled in default settings?

Why are you trying to do this by the way? Why do you need to accept bad sip requests?

Did you not read the this? Using SIP messages is unfortunately not an option, because the registration dies due to network problems, which a service provider does not get fixed.

It could be anything, try posting some logs, we may be able to help.

You may simply have run out of disk space. Go into /var/log and remove some logfiles then investigate why the disk is full

These errors are usually caused by incomplete upgrades, have you done advanced/upgrade then checked one box at a time and run through it?

PS search for Branding in the members area.

If that is the case, email support@fusionpbx.com

I cannot remember, you would be better off capturing all events and then registering a phone. Also, if you were purely a Yaalink house, they can call a URL when they register.

This is the actual bit of code that is involved: if ($action == "unregister") { $command = "sofia profile ".$row['profile']." flush_inbound_reg ".$row['user']." reboot"; } if ($action == "provision") { $command = "lua app.lua event_notify ".$row['profile']." check_sync...

No, I still think the above, the 'sync' command is sent to the phones causing a reboot so the sync is getting there, the only reason I can think why they do not provision, its based on the same sync command, is because they do not have the provisioning URL, for many years the provisioning URL...

That is not the way things work at all. The provision button sends a sip request to the phone to sync, it should be immediate. My guess is what is happening here is that the provisioning server is not being sent in the provisioning file, that would cause this behaviour, ie only works on a...

Yes, you would need to monitor the event socket.

I think you would need to capture some of this voicemail sip traffic somehow in order to get more help or at least some much more specific documentation on what is going on. The capturing of the traffic shouldn't be too difficult if you can get a switch with port mirroring or something similar...

For me, route53 is perfectly adequate. I also have other health checks going on with Nagios doing sip options pings, disk space test etc, etc, It has server me well for a few years now. When I do maintenance I usually get a very smooth failover, I may have to use IP tables to block ping access...

I use route 53 health checks.

Black and whitelist are fine for normal scenarios, ie there is going to be two way traffic, the above is an example of an edge case that does not require two way traffic. This also only works the way I describe above with UDP, TCP would fail as it needs the three way handshake. I know many...

Someone correct me if I am wrong here but following that above advice gives you a big gaping hole protected by nothing other than security through obscurity... Lets assume a premium rate number, here in the UK maybe £3 per minute. So if we know the sip endpoint for the above gateway eg...