Solved Snom D735 PnP Provisioning Issue

[Justin Jeremias]

I'm having an issue that I'm wondering if anyone else has seen or has any ideas about. We've used these D735 phones in a few places now (all small installs) and each time I end up having to manually provision the phones to get them to work. I've tried duplicating the issue with other phones, but the Snom D785 and D725 PnP provision without a problem. We're getting ready to do a much larger install with these D735 phones and I'd like to tackle the issue before we get into it and have to do it all manually.
Things I've tried:
- Manual firmware update (this isn't really an option anyway because a manual provision isn't much more difficult than a manual firmware update)
- Option 66 (this made it point to the server but still no PnP)
- I manually added the mac/phone model to an extension and together with option 66 it did provision.

When the mac/phone isn't added to an extension it returns a 404 not found when looking for the cfg file, but that would be true anytime you add a phone that isn't on the system so I'm not sure why that would prevent the phone from PnP provisioning.

Any experience or ideas?

 

[AWS2P]

Speaking about Snom phones, do you get complaints about too low audio volume when using hands free calls, on D735 or D785 this is now Snom new managing system AGC (automatic gain control) and for me it's not good at all, on old series Micro Gain was a setting.

 

[Justin Jeremias]

Speaking about Snom phones, do you get complaints about too low audio volume when using hands free calls, on D735 or D785 this is now Snom new managing system AGC (automatic gain control) and for me it's not good at all, on old series Micro Gain was a setting.

I haven't heard any complaints about that issue so far. Those who have the D785 especially love them.

 

[AWS2P]

Yes me too , i like Snom, but for this specific problem not so much

 

[jcostlow]

I haven't had that issue with the D735 or D785s we have installed. If it is trying to grab a cfg and gets 404 it sounds as if the MAC addresses were configured for RPS.

Do you know if they were added to snom's SRAPS either by distributor or someone else?

 

[JohnS_3CX]

When the mac/phone isn't added to an extension it returns a 404 not found when looking for the cfg file, but that would be true anytime you add a phone that isn't on the system so I'm not sure why that would prevent the phone from PnP provisioning.

Hi Justin,

I see there is some confusion here so I will attempt to give a quick and simple explanation of how this works.

1. A factory reset phone boots up
2. The phone sends a PnP message, and it appears in your 3CX "Phones" page
3. You select the phone, and click "Add" or "Assign" extension
4. This takes you to the extension's provisioning tab and you hit OK
5. At this point the PBX informs the phone of what provisioning URL to follow
6. If you entered the MAC correctly, the phone will request its config file (referencing its MAC)
7. The PBX checks the request, and delivers the file

That's pretty much it. So I think you should take a factory reset D735, upgrade it manually using the firmware we support (not any other firmware please) and see if provisioning it the way our guide describes will work. Don't skip any steps, otherwise we will not know where to look next in our troubleshooting procedure.

Now when compared to a non-upgraded D735, did it provision as expected or did it also fail?

PS: Make sure this test is done on a V16 (latest update), and the phone must absolutely be on the exact same lan as the PBX machine ( I cannot stress this point enough ) otherwise our test is invalidated.

 

[Justin Jeremias]

Hi Justin,

I see there is some confusion here so I will attempt to give a quick and simple explanation of how this works.

1. A factory reset phone boots up
2. The phone sends a PnP message, and it appears in your 3CX "Phones" page
3. You select the phone, and click "Add" or "Assign" extension
4. This takes you to the extension's provisioning tab and you hit OK
5. At this point the PBX informs the phone of what provisioning URL to follow
6. If you entered the MAC correctly, the phone will request its config file (referencing its MAC)
7. The PBX checks the request, and delivers the file

That's pretty much it. So I think you should take a factory reset D735, upgrade it manually using the firmware we support (not any other firmware please) and see if provisioning it the way our guide describes will work. Don't skip any steps, otherwise we will not know where to look next in our troubleshooting procedure.

Now when compared to a non-upgraded D735, did it provision as expected or did it also fail?

PS: Make sure this test is done on a V16 (latest update), and the phone must absolutely be on the exact same lan as the PBX machine ( I cannot stress this point enough ) otherwise our test is invalidated.

I have already done exactly as you specified. The phone never appears in the phones page. The only way I've been able to provision is manually adding the phone to an extension prior to plugging the phone in.

 

[JohnS_3CX]

Ok then in this case you need to be looking in a different direction. The PBX relies on multicast messages to "hear" that a phone is available for provisioning. We often see situations where people connect their phones via switches/routers that do not allow multicast messages to pass, hence the phone never appears on the management console as "new".

At this point the only way forward is to see if

1. The phone actually ever sent the message, by capturing the LAN port the phone is connected to
2. The PBX received the message exactly as it appeared in the above capture (you need to capture on the PBX and compare the two captures) https://www.3cx.com/docs/plug-and-play-ip-phone/

I think this is the best, most reliable way to discover what is happening.

 

[Justin Jeremias]

I haven't had that issue with the D735 or D785s we have installed. If it is trying to grab a cfg and gets 404 it sounds as if the MAC addresses were configured for RPS.

Do you know if they were added to snom's SRAPS either by distributor or someone else?

Ok then in this case you need to be looking in a different direction. The PBX relies on multicast messages to "hear" that a phone is available for provisioning. We often see situations where people connect their phones via switches/routers that do not allow multicast messages to pass, hence the phone never appears on the management console as "new".

At this point the only way forward is to see if

1. The phone actually ever sent the message, by capturing the LAN port the phone is connected to
2. The PBX received the message exactly as it appeared in the above capture (you need to capture on the PBX and compare the two captures) https://www.3cx.com/docs/plug-and-play-ip-phone/

I think this is the best, most reliable way to discover what is happening.

Would this make sense if other phones (even snom like the D785) do appear in the phones page?

 

[JohnS_3CX]

Yes, you still need to verify that the phone sent the message, and that the PBX received it.

Especially because I don't know what network your device passes to reach the PBX, so this method is as close to ground truth as possible

 

[Justin Jeremias]

Here's the capture from the phone lan port and then from the PBX.

Phone LAN Port


PBX

 

[Justin Jeremias]

I finally found a solution! After confirming that the multicast packets were getting to the server correctly I went back through and found that the multicast address 224.0.1.75 was bound to the loopback interface of the server instead of the main lan interface of the PBX. Changing this was also a bit of an adventure because they changed how binding priority is determined, but I'll include the cmdlet below. Once I got this change I rebooted the server and then was able to provision properly. Thanks everyone for your help.


in CMD
netsh interface ip show joins
(this shows what multicast addresses are joined on each interface)

in powershell
set-netipinterface -interfaceindex (interface number) -interfacemetric (cost)
example: set-netipinterface -interfaceindex 15 -interfacemetric 15

 

[NickD_3CX]

Quite an adventure! But I am glad to hear you figured it out.
I still have the question why the other 2 phones worked hat you had initially mentioned, but I guess that will remain unknown forever!