FreePBX | Register | Issues | Wiki | Portal | Support

SIP OPTIONS messages as a ping (Twilio)


(AllianceDoug) #1

In Twilio’s documentation (found here) for setting up SIP connections, they mention sending SIP Options messages from my PBX to the Twilio SIP Trunk. Here is what is says:

Optionally set-up your Communications Infrastructure to issue SIP OPTIONS messages as a ping mechanism to your Elastic SIP Trunk (Send the Message Request To: Termination URI you created ( example.pstn.twilio.com )); the Twilio platform will respond appropriately. Please maintain the Ping lower than 1 SIP OPTIONS every 10-15 seconds to avoid your requests from being banned by our Platform.

A bit further down in the same page in the “Deploying behing a NAT” (here), it mentions:

If you’re deploying behind a NAT without a Session Border Controller, it’s important to keep open the NAT translation binding.

For Signaling, when using UDP, this may be achieved by periodically sending SIP OPTIONS to Twilio, which will respond with a 200OK.

Where is this set up in FreePBX?

We have intermittent outages that end up resolving after a couple call in/out attempts, and I’m hoping this will help that issue.

Thanks!


(Lorne Gaetz) #2

You’re looking for Qualify frequency, or qualify=yes depending on whether you’re using pjsip or chan_sip.


(AllianceDoug) #3

Thanks - I would not have found it without you pointing me to the word “Qualify”. Found that in the FreePBX GUI under Settings -> Advanced Settings -> Device Settings -> “SIP qualifyfreq”. It was set to 60 (must be the default). I’ll lower it to 30 seconds (since the Twilio documentation says no more than every 10-15 seconds) and see if that helps. For future readers, the help text for this setting reads:

KEYWORD:DEVICE_SIP_QUALIFYFREQ
Default setting for SIP qualifyfreq. Only valid for Asterisk 1.6 and above. Frequency that ‘qualify’ OPTIONS messages will be sent to the device. Can help to keep NAT holes open but not dependable for remote client firewalls. See Asterisk documentation for details.

The setting below this is “SIP and IAX qualify”. It was set to yes (that must be the default). The help text for this option reads:

KEYWORD:DEVICE_QUALIFY
Default setting for SIP and IAX qualify. Whether to send periodic OPTIONS messages (for SIP) or otherwise monitor the channel, and at what point to consider the channel unavailable. A value of ‘yes’ is equivalent to 2000, time in msec. Can help to keep NAT holes open with SIP but not dependable for remote client firewalls. See Asterisk documentation for details.

Sounds like if FreePBX doesn’t receive a response from the SIP Trunk provider within 2 seconds, the channel is considered “unavailable”. I’m not sure what happens then… Maybe service is down until “SIP qualifyfreq” seconds and it tries again.

I would guess the “SIP and IAX qualify” needs to be set to “yes” in order for the ping to happen every “SIP qualifyfreq” seconds. Can anyone confirm that is how it works?

Also, the help text says “Frequency that ‘qualify’ OPTIONS messages will be sent to the device.” What is “the device.”?
I would guess it is every Trunk “host” that is configured under TrunkName -> sip Settings -> Outgoing (PEER Details) / Incoming (USER Details) -> host=“your SIP Trunk URI / IP here”.

Can anyone confirm that this is what these settings are acting upon?

Thanks.


(Tom Ray) #4

So the terms “Trunks” and “Extensions” are just that, terms. To the PBX everything is a peer/endpoint. Doesn’t matter if it is a trunk or extension.

The qualify frequency is how often the PBX should send an OPTIONS message to the device it’s configured for. In the case of your trunk(s) for Twilio, Twilio is the device. In the case of your extension, the phone that is registered to is the device.

While this can help with your issue, you really need to look at your firewall/NAT settings because that is the cause of this more than anything else. Your NAT state tables could expire data faster than 30 seconds or your quality period.

Honestly, if you’re using SIP Registration with them then drop the registration time down to 60 seconds or so because each REGISTER attempt will do the same thing as qualify which is keep the NAT hole open on your firewall since it’s generating an outbound request.


(Lorne Gaetz) #5

This setting controls the default qualify setting for new devices, but won’t affect existing. Qualify frequency is controlled per device from either the advanced tab when you edit an extension, or with the trunk peer details.


#6

That should not be the case! If there is no response to OPTIONS within two seconds, Asterisk immediately sends another. It marks the host unreachable only after seven failures in a row.

If your trunk was marked unreachable, there was probably no connectivity between the PBX and Twilio for at least 14 seconds. I doubt that Asterisk marked it inappropriately, though if you suspect misbehavior, a simple test would be to monitor traffic to an extension with
sip set debug peer <extensionnumber>
unplug the Ethernet cable and see when ‘unreachable’ occurs.

If you are using registration with Twilio and have a static IP, consider using IP authentication instead. Also, set your firewall to pass all SIP traffic from Twilio IP addresses to the PBX, so you aren’t depending on ‘keeping the NAT association alive’. Asterisk ignores ‘unreachable’ for incoming calls, so if there is connectivity when a call arrives, it will come in.

If you determine that Asterisk is not malfunctioning with regard to reachability but you still see unreachable events in the log, test by e.g. running continuous pings to various addresses to determine if the trouble is with your network, firewall, internet connection, or ISP’s connectivity with Twilio.


(Tom Ray) #7

Also why are you using Chan_SIP for Twilio? They are a prime example where PJSIP is the proper choice. One trunk instead of five.


(Jared Busch) #8

It is also their default recommendation in the current guide.


(system) closed #9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.