I have two trunks for our SIP provider. As showing in the pictures, one works fine (usually) but the Los Angeles one is always unreachable. The SIP provider is saying their system is set up fine. My router is not filtering outbound connections (obviously since the Boston trunk is reachable and I didn’t set anything up for that).
FYI the IP addresses in this image are published by Broadvoice / Phonepower.
This is a FreePBX 220.127.116.11 system, on a Frontier supplied router.
I’m very puzzled. Testing against the addresses in your screenshot, I got no response from either.
However, I was able to get responses from both ‘cloud’ servers mentioned in https://support.broadvoice.com/wiki/Configuring_a_Sonicwall .
So I’m guessing that the .13 servers (as a security measure) limit the response to OPTIONS to e.g. registered clients. Does your system normally register to BOS but not LAX? If you disable qualify can you call out on both trunks?
So this morning I ran another “sip show peers” and “magically” the Los Angeles trunk is online. I did nothing that would have caused this issue to be resolve. Obviously it was on the SIP provider side. However, I will still turn off quality for the LAX trunk. Thanks for the recommendation.
Or a problem with a router, or a problem with an intervening firewall, or a pile of old bits finally got swept up from the server room.
I agree the problem was probably at the remote end, but there are lots of places along the way that can screw you up and make it look like the remote end. Either way - congrats.
You are right. I should have used “Likely” instead of “Obviously”.
It’s really 50/50 on that and since it’s UDP we’ll never really know. All we do know is that Asterisk made the attempt about 7 times and got not response. That could be a remote side issue (they got it and didn’t respond) or it could be a local side issue where the provider got the OPTIONS and sent back a 200 OK but it never made it back to Asterisk.
So here’s the big question: When LAX is showing UNREACHABLE can it receive calls? I’m going to guess outbound calls would fail as Asterisk would consider that peer “unavailable”. If it can still receive calls while showing UNREACHABLE then that would confirm @Stewart1’s theory about the rejection of OPTIONS from non-reg’d endpoints. However, if it CANNOT receive incoming calls then there is a networking/routing issue on your side.
That is really what needs to be determined. If @Stewart1’s theory is correct turning off Qualify is the proper solution. If the theory is incorrect, then turning off Qualify doesn’t actual solve the issues that exist.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.