Multicast works. PnP broken.

[narrington]

Up front, most of our users are remote with SBCs and I have several users who have to have their phones re-provisioned almost daily. The users in question shut down their work equipment at night so this isn't much of a surprise. All of them are NOT having an issue. I just select their phone and "assign ext" back to them. Works like 99% of the time and when it doesn't typically all they have to do is reboot their phone and I repeat the above. Havent had an issue yet.

HOWEVER, I have a total of 5 phones technically alive here in the office. Nobody's here these days to care if the lines go down... except for this one lonely guy. He had an older grandstream that was working just fine for him up untill friday when it decided to finally break down. I replaced it with a GXP2170 and the new phone didn't appear in the list. 3 days of troubleshooting later and I deturmined there was a multicasting issue in the network because I replaced a switch in the rack that was doing a little IGMP snooping and killing multicasting. Disabled IGMP snooping and multicast now works, I now have 5 "new" phones in the list including his new phone... This is where I'm stuck.

I can see the phones, but when I assign them to their respective extensions, they never come out of new. They just sit there. When I check the phones, most of them say "account not registered". I have two exceptions. To get him up and running, I went through and setup the sip account on the new phone for lonely guy. His phone now appears in the list as assigned, but it also says "UNPROVISIONED" the other exception is one of the unused phones just randomly came online and is working. I never even got a chance to attempt to provision that line. So I have 3 phones appearing in new, but not using PnP. In an attempt to trouble shoot further, I grabbed an old phone we had in the back to try and see if I could provision from factory fresh. I fReset the phone to factory and tried it. I can see it in new and I assigned it to lonely guy (just because it's first in the list). the phone does not self configure. I know it at least tried however, because when I go into maintenance/upgrade & provisioning, the provisioning link is populated.

I have run the firewall checker (which works to rebind sip.mcast.net to the interface) and I tried upgrading the firmware on a phone to see if it would trigger something.

Any ideas?

UPDATE: I noticed in the provisioning link the one phone that's still working is using the server's local IP address and the rest are using the FQDN... not sure if that's the issue but I changed it on the test phone and it kind of half self-configured. Basically it set up account 1, but that's about it (none of the BLF settings applied. I have an alias in house to redirect our FQDN (internally) to the phone server IP so MAYBE that's the issue? I guess maybe that alias isn't fully configured correctly? Obviously I need to address that as well, but I can't accept that's the only issue here.

UPDATE#2: I may be on to something, I got another phone up and running... I feel silly... under the phone provisioning tab in the user section, I can change the interface from the FQDN to the server IP. changed that on one phone and then rebooted the phone it question. It's fully up. But the newly configured phone is still borked. I'm going to go through and change the other phones to use the same setting before coming back to this one.

 

[SteveITS]

I don't think it's normal to have to reassign phones if they are turned off. I've seen both SBCs and phones off, and they just recover.

As for the new-doesn't-provision issue, I recall something similar a year ago when the LE root cert expired. 3CX put out a fix back then. What version of 3CX, and what phone model/firmware version?

If using the URL, it should work with split DNS as long as DNS is correct...

 

[narrington]

I don't think it's normal to have to reassign phones if they are turned off. I've seen both SBCs and phones off, and they just recover.

I tend to agree... it's only on two or three phone consistantly, but those are also the only users who full-power-down all their work equipment. In the beginning I looked at it a little deeper and it seems the phone is booting up faster than their SBCs so I think it's a case of the sip registration request the phones is happening when the SBC is down. The request never gets repeated and the switch never sees the phone until after the phone goes into some sort of time out. I don't know for sure that's the case, but I didn't dig too deep. Typically them rebooting the phone fixes it, but if I see it, I can also re-provision the phone from the PBX.

As for the new-doesn't-provision issue, I recall something similar a year ago when the LE root cert expired. 3CX put out a fix back then. What version of 3CX, and what phone model/firmware version?

I'm running 18.0 (Build 965). I don't think this is a cert issue (though I have been wrong before and will again). the webpanel loads with a valid cert through November 23. Besides--as said in one of my updates--after changing the interface value, under phone provisioning, from the FQDN to the servers internal IP address, PnP seems to be working again, all be it very, very slowly.

If using the URL, it should work with split DNS as long as DNS is correct...

I think I understand what you're saying here and yes... sort of... after changing the interface value, under phone provisioning, from the FQDN to the servers internal IP address, PnP seems to be working, all be it very, very slowly. I have an alias in my routers config directing internal traffic pointed at the FQDN to the server's internal IP address. I had to do this because pfsense does some tricky things in the firewall when using NAT on a single internal IP address... I would have preferred a second, 1:1 IP for the server... but that costs money I don't have.

 

[SteveITS]

I have an alias in my routers config directing internal traffic pointed at the FQDN to the server's internal IP address

That sounds like you're using NAT reflection? Instead set up a zone on your LAN's DNS servers to point your 3CX FQDN at the server's LAN IP. Then devices inside the network will connect directly to that server.