So I utilize Voyant Sip trunks, following their recommended setup exactly (found here Voyant FreePBX Guide). I have a few servers up with different trunks, all no problems, except for this one particular server. Contacted the provider because I was seeing randomly rejected notices from the trunk, of course after the client tells me calls are failing. Fast forward, Voyant tells me that when a call goes in, and they send back a 486 Busy, we respond with an ACK and it has an invalid route line (Route: <sip:…:6000;lr>). That is verbatim, not masked. So when we send that ACK with the invalid route, Voyant disregards it, and it keeps trying and eventually they blacklist our server IP for 30 minutes because they think it’s spam / fraud.
Here is an image they sent me from their side with an example. Again, this only happens with 486 Busy.
Any suggestions on this? I cross checked the trunk setup side by side with another server that is working fine and they all match, minus the authentication information. I’m just not sure where header information can be modified for this particular case.
I will update that outbound proxy line with your suggestion and see what happens. Thank you for the recommendation. Voyant sent me some more examples too. It seems to happen intermittently. He sent me one example with a 486 busy and we responded with a valid route, and then another one shortly afterwards with the invalid string posted above. Seems very odd with the inconsistency.
The full SIP trace would really need to be seen to understand where it is truly originating from. The value I posted will not add a Route at all on the Asterisk side.
That’s what I assumed looking at the string. The only reason they recommended I use that is because the FreePBX doesn’t do DNS SRV lookups properly? This was back in July 2019. This was recommended to me back when I used the following at that time:
FreePBX Version: 14.0.13.4
Asterisk Version: 13.22.0
Was that resolved somewhere between there and the current version and that outbound proxy won’t be required at all?
Back at that time, I was seeing intermittent call failures. They informed me that they were seeing registrations on one server, but call attempts were being routed to the secondary server even though the first one was up still. It kept bouncing back and forth. So they recommended I put in that outbound proxy to one server or the other, but I lost redundancy with them by doing so. This did fix that issue though.
Here was their response to that issue back then:
It looks like you’re being impacted by FreePBX’s inability to do DNS SRV lookups correctly. I see your registrations going back and forth between our Plymouth, MN node (137.192.80.65) and our Dallas, TX node (137.192.78.65). This will cause outbound calls to fail if you’re registered to one node, but you send the calls to the other node.
There are two ways to work around this:
The first is to change your endpoint to an IP endpoint. The advantage of this is that it maintains redundancy. The drawback is that it’s not a registration endpoint.
The second is to use an outbound proxy in your FreePBX. The advantage of this is that you keep your registration endpoint. The drawback is that you lose redundancy. If you’re interested in this, under Connectivity > Trunks > (your pjsip trunk) > PJSIP Settings tab > Advanced tab, in the Outbound Proxy field, put in either sip:ply-st.sip.global;lr or sip:dal-st.sip.global;lr whichever you prefer.
There is a possible third way, where you have two registration endpoints in our portal and two trunks in your FreePBX; one as a UDP trunk and one as a TCP trunk. Each trunk would use a different Outbound Proxy. TCP and UDP must be configured to use separate ports on your side. This should allow you to registered to each of our nodes, since the IP:port is unique for each. This configuration is untested, though.
I’m not aware of any known current issues in that area, and 16 and above have test coverage of it. If the SRV records are configured in a failover fashion it should stick to the first one only. As well 13 doesn’t have failover, so it wouldn’t failover if the first one failed anyway.
I wish they had filed an issue with us with the information at the time.
Even though plmomn-access-sbc2.sip.global. has a priority of 10, the registrations or calls will intermittently be sent to dllstx37-access-sbc2.sip.global. When this occurs, the SRV record has not changed and plmomn-access-sbc2.sip.global is still accessible.
