Setting up a callback service can include multiple layers of required pass through to your server.
- Does the server have a virus application blocking inbound traffic?
- Does the server have a firewall application blocking inbound traffic?
- Are there internal firewalls along the inbound path to the server blocking inbound traffic?
- Is the ingress router and firewall blocking the inbound path?
- Do you have a specific port policy or route policy in place to permit or deny the inbound traffic?
Once you are sure the inbound path is clear you can check your service.
- Can you get to to the service locally on your machine (127.0.0.1)?
- Can you get to the service from another machine on your network?
- Can you get to the service from another machine off your network?
- Should you be able to get to your service from any other place, other than Verizon, due to a specific route policy?
You can test your callback service using PUT /devices/actions/customFields.
- You need to have at least one active device on your account.
- It provides a fast callback response to your request.
- It changes one of the five available custom fields and does not affect your device, line or account.
- It uses the CarrierService callback, the same callback service used for activations.
- It can be used again and again. Preferably with a variable that sets the time or increments a number for easy identification of changes.
- Test your http callback first, confirming inbound is operational.
- If you require a secure connection, once http is confirmed then move to testing https.
- Https requires a legitimate signed security certificate. A self signed certificate will not work.
- If you require additional security, your can try adding the username and password option.
Read more about registering callback services at ThingSpace Callback Services.