I’ve got a new asterisk server here at the office, and we’re trying to
set it up to replace our old one. We’ve set up the new machine with
the latest version of asterisk, since the old one was running
a pretty build.
I replicated the configuration on the new machine to match the old one
as much as possible. Same sip accounts, same dial plan, same mail
boxes. I even copied over the voice mail folders, and it all seems to
work fine. The phones I’ve tested with can call each other, can call out
to the world, and get calls coming in from the world.
So, after the testing seamed done we took down the old machine and
assigned the old machine’s IP address to the new machine. We hoped
that all the office phones would not even notice notice the change, and
would smoothly transition to talking to the new server instead. The
trouble is that only about 1/5th of the phones did this properly.
“sip show peers” shows the other 4/5th of our phones as not registered.
I did some packet sniffing with wire shark, and also some snooping
with “sip set debug on.” It seems that the problematic phones are
actually sending floods of sip REGISTER requests to our new server,
but then asterisk appears to just drop them silently. No error
messages in the console, no nothing.
If anybody could help me out with debugging this it would be much
appreciated. I can provide any relevant info here, if only I’m told
exactly what, and possibly how (since I’m still relatively new to
asterisk).
Anyway, many thanks in advance for any help I might be able to get
-Patrick
Will do. Unfortunately I can’t play around with this stuff until everybody clears out of the office later at around 6 or 7. So, I’ll post back that trace and peer status sometime around then.
Oh, I almost forgot. Here’s wire shark sniff of a packet from another phone which fails to register, if that’s any help. Again, the IPs are redacted. (Note that I didn’t see anything in wire shark that looked like a server response, I think the register request is just ignored):
Not sure why you blocked out your IPs ending in .186 and .188. Were those public addresses?
Looks like the REGISTER attempt says devices are at some private addresses:
10.0.1.19 for 204
10.0.1.21 for 200
It’s possible you have a strange NAT issue or some other limitation of ports by way of an intermediate router, switch or firewall. Or more than one network interface on the new PBX with some associated routing irregularities?
How fragmented is your network? Appears to be split address spaces, so you’ve got a whole host(s) of places to start looking for unexpected network service actors saying the wrong thing! DNS, VLAN, DHCP, etc.
Right, ok, I should definitely have explained this before hand. It’s not that bad of a fragmentation. The server is on an external IP, and all of our office phones connect to it via that external IP. And, of course, all of our phones are on a NATed connection when they talk to the outside world.
However, I didn’t expect this to cause major issues. That’s how our existing system is set up, and it’s working smoothly. Plus, on the new system that I’m having trouble with several phones do connect properly to the external IP of the asterisk server. So, I would expect the rest of the phones should be able to connect properly too (and they do, but the registration just gets silently ignored).
I’m not meaning to insist that this networking setup isn’t the problem, but I definitely want to stress that the smooth functioning of the existing system, along with a select several phones which work on the new system already indicates to me that either the problem is elsewhere, or that if the problem is with networking issues then at least not an insurmountable.
Still very confused about why things aren’t working,
(And not totally convinced it’s because of networking issues)
-Patrick
P.S.
And yep, the 188 IP is the external IP of the asterisk server. And the 186 IP is the IP our NATed phones use. Both the phones and the server are on the same internal network, but they talk externally. And yes, this seems silly now that I think about it, but that’s how the existing system was already set up (though not by me). And when replicating things on the new system I’ve kept things they way they are so that I wouldn’t have to go and change the configurations on our phones (though I can always do that if really necessary).
Also, I just changed the network configuration around such that the phones now talk to the asterisk server purely on the internal network. I now get similar registration requests like
asterisk*CLI> sip show peers
Name/username Host Dyn Forcerport ACL Port Status
200 (Unspecified) D N A 0 Unmonitored
201 (Unspecified) D N A 0 Unmonitored
203 (Unspecified) D N A 0 Unmonitored
204 (Unspecified) D N A 0 Unmonitored
206 (Unspecified) D N A 0 Unmonitored
207 (Unspecified) D N A 0 Unmonitored
208 (Unspecified) D N A 0 Unmonitored
209 (Unspecified) D N A 0 Unmonitored
210 (Unspecified) D N A 0 Unmonitored
211 (Unspecified) D N A 0 Unmonitored
212 (Unspecified) D N A 0 Unmonitored
213 (Unspecified) D N A 0 Unmonitored
214 (Unspecified) D N A 0 Unmonitored
215 (Unspecified) D N A 0 Unmonitored
216 (Unspecified) D N A 0 Unmonitored
218 (Unspecified) D N A 0 Unmonitored
219 (Unspecified) D N A 0 Unmonitored
220/220 10.0.1.51 D N A 5060 Unmonitored
221 (Unspecified) D N A 0 Unmonitored
223 (Unspecified) D N A 0 Unmonitored
239 (Unspecified) D N A 0 Unmonitored
300 (Unspecified) D N A 0 Unmonitored
22 sip peers [Monitored: 0 online, 0 offline Unmonitored: 1 online, 21 offline]
asterisk*CLI>
Also, yes, the phone 220 is indeed connecting. It’s one of the few that does. 214 and 216 would connect too (if they were turned on). As would a few others, but the vast majority of them don’t. Interestingly, the ones that asterisk turns a blind eye to are all of a different cisco model. That probably has something to do with it, but I have no idea as to the details of how or why.
So this works okay with some phones, call them model X, but not Cisco Phone Model Y ?
What is X ? What is Y ?
I think you made the right move by straightening out the network, but it seems like you are running into Cisco SIP incompatibility issues. Those can be frustrating and the lack of manufacturer documentation does not help.
