This thread started back in 29 Sept. 2018 but is now locked so I can't post my follow-up on the issue. The URL for that post is https://3cx.com/community/threads/yealink-subscribe-request-no-response-by-3cx.59799/ .
After a rather arduous journey into the guts of debian linux, I discovered the problem. In a nutshell, the sip.multicast.net registration (224.0.1.75) fails for the network adapter. It apparently fails because the 3CX Phone System Service (“3CXPhoneSystem01.service” - systemd startup file) starts before the network adapter is ready. This causes local provisioning (by Plug and Play - PnP) to fail.
Interestingly, this problem is documented by at least two others and that a restart of the SIP service will "fix" the problem is what lead me to the following solution. Also note, the firewall checker also stops and starts the SIP Service so that will "fix" the problem as well.
The solution is to slow down the start of the “3CXPhoneSystem01.service”. I did this via two methods:
The net effect of either of those two was to slow down the “3CXPhoneSystem01.service” enough so that the adapter had enough time to finish initialization.
I need to mention that this is a problem new with my 15.5 install. An install I did over a year ago did not exhibit this problem on the exact same hardware with the exact same phones.
I tried to submit this as a problem to 3CX, but their take is that it's not a phone system problem and my particular NUC isn't supported. I have different thoughts on this as they supplied the ISO and you'd think they'd want the phone system to run on more devices but I digress.
If anyone is interested, I can share more of the gory details. I'm not a Linux expert by any means and I had to do this trouble shooting myself. I really like the product, but I am vastly disappointed by 3CX support in closing this case.
For whatever it's worth, I consider the 3CX phone system software to have failed for the following three reasons:
I hope this helps someone when they experience this problem. I'd like to see 3CX actually address this problem instead of us users having to craft our own fix.
After a rather arduous journey into the guts of debian linux, I discovered the problem. In a nutshell, the sip.multicast.net registration (224.0.1.75) fails for the network adapter. It apparently fails because the 3CX Phone System Service (“3CXPhoneSystem01.service” - systemd startup file) starts before the network adapter is ready. This causes local provisioning (by Plug and Play - PnP) to fail.
Interestingly, this problem is documented by at least two others and that a restart of the SIP service will "fix" the problem is what lead me to the following solution. Also note, the firewall checker also stops and starts the SIP Service so that will "fix" the problem as well.
The solution is to slow down the start of the “3CXPhoneSystem01.service”. I did this via two methods:
1) Modify the .service file to include: “ExecStartPre=/bin/sleep 30” just after the [Service] header.
This worked, but any restart of the service is delayed by 30 seconds, not just at reboot. This method was to test the "Starts Too Fast" theory and it did "fix" the problem. So I started looking for why the service was starting before the adapter was ready.
2) Modify the .service file to include (eno1 is my adapters' name) just after the [Service] header:
ExecStartPre=-/bin/netstat -g
ExecStartPre=-/sbin/ifquery eno1
This worked, but is hard-coded to the adapter name which isn't a universal solution. I'm still using this one. It's faster than the hardcoded sleep, but could still fail. I'd need detail help with Linux to get further.
This worked, but any restart of the service is delayed by 30 seconds, not just at reboot. This method was to test the "Starts Too Fast" theory and it did "fix" the problem. So I started looking for why the service was starting before the adapter was ready.
2) Modify the .service file to include (eno1 is my adapters' name) just after the [Service] header:
ExecStartPre=-/bin/netstat -g
ExecStartPre=-/sbin/ifquery eno1
This worked, but is hard-coded to the adapter name which isn't a universal solution. I'm still using this one. It's faster than the hardcoded sleep, but could still fail. I'd need detail help with Linux to get further.
The net effect of either of those two was to slow down the “3CXPhoneSystem01.service” enough so that the adapter had enough time to finish initialization.
I need to mention that this is a problem new with my 15.5 install. An install I did over a year ago did not exhibit this problem on the exact same hardware with the exact same phones.
I tried to submit this as a problem to 3CX, but their take is that it's not a phone system problem and my particular NUC isn't supported. I have different thoughts on this as they supplied the ISO and you'd think they'd want the phone system to run on more devices but I digress.
If anyone is interested, I can share more of the gory details. I'm not a Linux expert by any means and I had to do this trouble shooting myself. I really like the product, but I am vastly disappointed by 3CX support in closing this case.
For whatever it's worth, I consider the 3CX phone system software to have failed for the following three reasons:
First, Startup is failing to wait for a ready interface. That’s the root problem and if the interface for an IP based phone isn’t working @ startup there should be messages clearly noted that something is wrong.
That’s the second issue – no message that sip.mcast.net is not working (and thus local provisioning via PnP).
The third issue is that when the interface did start up, the proper configuration for it was not done (as sip.mcast.net remained missing).
That’s the second issue – no message that sip.mcast.net is not working (and thus local provisioning via PnP).
The third issue is that when the interface did start up, the proper configuration for it was not done (as sip.mcast.net remained missing).
I hope this helps someone when they experience this problem. I'd like to see 3CX actually address this problem instead of us users having to craft our own fix.
