I’ve posted something on this error before (which was cause by a miss-configured switch port), but this time i’m stuck with the cause. I am currently investigating every possible networking issue, but wanted to see if anyone can help here too and cover both “bases”.
Randomly, phones on a ring group will either correctly all ring, or sometimes not ring, or sometimes ring for a second then disconnect etc. When viewing things in the CLI is see that:
all the extensions are “called”
–“Called 191” etc
they then “ring”
–SIP/191-xxx… is ringing
Then i get…
–Got SIP response 400 “Bad Request” back from x.x.x.x
–SIP/191-xxx… is circuit busy
This might be for one extension, all but one, or a random selection from the ring group
This is random in its occurrence and has just started happening since Friday when i added two new phones to our network (which i’ve since un-plugged.)
Out phone network and data network are separated by VLANS and have different internet connections too. As i say, this has just started to happen, apparently, at random, with nothing i can think of changing.
I honestly think it must be a networking thing, but i feel like I’ve exhausted the options there.
Thanks for the confirmation. I was suspecting this (hence the added info) and the fact that this appears to have begun to occur after a period of significant growth for us in terms of internal users and therefore traffic going in and out (the Firewall) on the VoIP. Its worked till recently and as i’m a “learn as i go” FreePBX/Asterisk/Linux admin I’ve been happy to leave it “working” this way to this point.
The only option with the servers hardware is to use a USB NIC (not a great choice i know). Do you think this will cause just as many problems as I’m trying to solve? Going down the LAN and then also via USB bus to get to the VoIP server for something like VoIP traffic that needs a reliable transport…? I might have to rethink a few things if this wont do…
just posting an update as this is becoming increasingly confusing, but also problematic as the ring group at issue is the main customer service one so the problems are not only difficult for them to handle but also my boss freaks out when the phones dont work properly.
So…
The issue above continues. There is no obvious reason or cause i can see. Sometimes i get no –Got SIP response 400 “Bad Request” back from x.x.x.x" sometimes I’ll get one or two, sometimes (the times my boss most freaks out) I’ll get 5-6 of them and the phones bounce around the remaining extensions, some ringing, some not.
So to maybe offer some more potentially useful info… is this config OK?
FreePBX server has Public IP with firewall on it, limited to required SIP ports and defined IPs.
This sits behind another FW which forwards all SIP focused traffic to it. A semi DMZ if you like. It has no internal IP address
All (internal and external) phones connect to its Public IP.
So internal phones go OUT the firewall and back IN to the “Public” IP of the VoIP server (hope that makes sense).
One single NIC on the FreePBX server, on a 100MB network connection straight into the “main” firewall.
All the phones connect via a main switch on the internal network, again 100MB, to the “main” firewall.
SO… does all the “going out” to the Public IP and “coming back in” cause problems? if so, why at random times?
Internet connection is ADSL
This is really confusing me right now, so ANY help is greatly appreciated.
Doesn’t sound like a good way of doing things if all phones are connecting via the firewall. Does the firewall have a SIP ALG or SIP Helper function? If so try switching it off. If the router is under heavy load this could cause this type of intermittent problem. Can you see any unusual firewall activity in the firewall logs or any unusually high traffic rates on the firewall?
Is it possible for you to add a second network adapter in the FreePBX server so that phones register directly on an internal IP address? You can still leave the default gateway set to use the external address as the internal card will only be used for traffic on the same subnet.
