@simplydrew wrote:
Hi All,
I seem to have come across a problem that might be configuration related in my setup, but haven't been able to pin it down. FreePBX version is 2.11.0.43, Asterisk version 11.16.0.
I use a few different SIP providers, my primary being a small mom & pop shop, which I have my DIDs with, and route outbound calls to as well. Second in line is Aveno for outbound, and then Vitelity if all else fails. The inbound provider for my DIDs has mostly been solid, and they have a few different POPs across the US - for sake of this explanation, POP1, POP2, and POP3. They're using Asterisk for call control, it appears, and an A2Billing portal where I set DID destinations, etc.
I have my SIP peers setup to all three of their POPs with a separate peer configuration - all of which have the below config, swapping "pop1.provider.com" to POP2, POP3, and so forth.
====
type=friend
qualify=yes
insecure=port,invite
host=pop1.provider.com
dtmfmode=rfc2833
deny=all
context=from-trunk
canreinvite=no
====They'll route calls from any one of those POPs, depending on which one is least busy/responds quickest. Unfortunately, the thing that I'm seeing is that if they lose a POP (provider had a DoS that affected them, etc) or some sort of other connectivity disruption, this presumed redundant peer configuration doesn't appear to work. The call will still try to deliver over the peer that's unreachable, and will not fail over to the others. At first, I thought this was most likely something on their end as a result of not seeing anything in the CLI when making test calls during one of these events - as well as having clear iptables allow rules to all of their POPs, etc.
After doing some troubleshooting with the provider yesterday and intentionally "breaking" a few things, where I had them temporarily IP ban my IP from one POP at a time while I placed test calls, the issue wouldn't reproduce itself at first - but once blocking a POP or two, the provider would eventually see my side returning a busy:
-- SIP/[my cloud PBX IP]-00000013 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
Failed to authenticate on INVITE to '"WIRELESS CALLER" ;tag=as13a3b2d7'Calls are being routed by them to me as SIP/1212XXXXXXX@[my cloud PBX IP], so just sending by DID @ IP.
To them, it looks like I'm actively rejecting invites from their other peers once I'm "stuck" on one, somehow. I've gone as far as temporarily turning iptables off all together while testing with them, and this still seems to happen. They're under the impression that a packet gets sent back to them at one of the other POPs rejecting the call, where everything goes sour. Won't have an opportunity to do a pcap to confirm that until a weekend maintenance window though.
Just throwing this out there to see if anyone has encountered something similar. This, of course, really screws me up when they have a network event at one of their POPs, and while all POPs should be attempting to send me the call (which appears to be happening on their side), it appears that Asterisk is sending something back on my end that is potentially screwing things up.
Any thoughts?
Posts: 1
Participants: 1