API call using Curl to SIP provider
is there a way to trigger a function call via API/Curl from the firebox to my sip provider (sip provider supports this ) related to failover event?
if so is there any WG documentation you could point to?
Thanks in advance
0
Best Answer
-
james.carson Moderator, WatchGuard Representative
Hi @lotty
The firebox wouldn't support this out of the gate.
If this is something you wanted to set up, you could potentially use an SNMP trap or alarm log via Dimension to send an email, which could trigger this. The firebox will not make the API call by itself, however.
-James Carson
WatchGuard Customer Support0
Sign In to comment.
Answers
as FYI .. my sip provider tells me this feature is support by many other firewall appliances.
a bit more color on the scenario, on a failover to the backup ISP the IP scheme changes and all the active sip trunks need to be told to register. the sip trunk provider manages the host registrations including recording of the source external IP. Puts the SIP trunk provider in position as the manager of the traffic. The problem comes when my local FB fails over the traffic and now the new source IP but the SIP trunk registrations reflect the pre failover IP.
There are IP based sip trunk registrations and credential based. The credential based just need to be signaled to reregister. The IP based need to have their primary IP and the secondary IP swap positions otherwise the SIP provider will continue to make first attempt to the pre fail IP before timeout and attempt to secondary.
I will try to explore your suggestion to use as a trigger. It would be useful to be able to use a failover message to trigger the API call, otherwise i will need to have some direct independent monitoring of the the public IP path from our SIP endpoint device to the sip trunk provider as the trigger as the SIP voice/fax traffic may failover independent of other traffic
Just surprising that WG does not have this ability as i would think what is going on here is very typical with SIP trunks.
I would suggest creating a support case and ask for that as a feature.
If you do this, please provide more information about your SIP provider and the API they're using.
In general, SIP phones will re-register by themselves to the new IP if their old connection is cut off by multi-WAN. The SIP provider would get the new IP via that transaction. There may be some more advanced set-ups where this is needed, but for the vast majority of customers, nothing additional would need to be set up for multi-WAN to work with their SIP devices.
-James Carson
WatchGuard Customer Support
did extensive testing of multi-wan this past weekend .. the SIP trunks did NOT register following any multi-wan shift ..
discussed the re-registration directly with SIP trunk provider higher level support and was told that instructions must be issued by the endpoint device
they pointed to using Curl and API calls triggered from the endpoint device (ie in this case the WG device or other SIP endpoints )
I was able to get into the the sip reg interface on the SIP endpoints and modify the registration timer to reduce the standard re-reg period but this still leaves a gap relative to fail-over and I do not want push this too far and risk call disconnections .. so there are practical limits
plus this does not address the need to trigger the primary and secondary IP to rotate on the IP based trunk.
i will update our existing Case with WG to include.
Keep in mind in this situation the sip phones register to the local PBX the PBX uses the IP based sip trunk and it is that trunk that does not auto rereg .. it never knows the firewall is routing out the backup interface .. it would have to actively monitor the outbound route to see there is an ip shift to know to re-register and that does not seem to be a feature. The SIP provider gave very direct feedback its upto the SIP endpoint to signal for a re-registration prior to the expiration of the session. A further problem is the SIP provider continues to dispatch to the primary IP if that responds. Why that is important is if the failover was trigger due to quality issue but the main ISP is still actually up then the inbound calls are coming in the main interface even though all outbound traffic is going out the secondary ISP .. the packets are a mess .. its amazing i can still get audio at all. Ignoring the need to call for a registration .. without the API call to swap the Prim and secondary IPs the alternative is to block all traffic to force the inbound calls coming in the main ISP to not communicate when in failover ..if you block the traffic then this will force the SIP trunk provider to send each call down the secondary IP .. the packets will will then get match the IP scheme of the secondary ISP and failover route.. the problem here is need a trigger deny rule plus there will be a 5 second connection lag as the SIP provider dispatches the inbound calls to go through the progression of primary to secondary failover for the trunk.
Handling of the credential based trunk is a bit easier but my phone engineer does not seem to think that is good idea for voice.
Either way, seems to me WG would need to add features to match what other firewall vendors provide.
All the best
Hi @lotty,
Without the RFC number and/or specs for said API, or even an idea of whom your SIP provider is, I can't even begin to assist with this.
While I understand the situation that you're in, the information here is basically "The phone company said it wouldn't work without the thing they said you should provide."
Unless your existing case is about those SIP issues, please create a new support case, and include those details. Without them, we simply will not be able to help.
-James Carson
WatchGuard Customer Support