Porter

Still no luck with 1108. The license is not valid. It seems like this should be a simple thing to fix - I don't think SnomONE licenses have ever been valid on PBXnSIP installations - and in this case the whole header of the admin page proclaims "PBXnSIP". Is there any way to get a proper (branded) build of SnomONE on this codebase? Thanks!

Thank you for your assistance! I will test today and report back.

I ran into this problem as well, and I noticed that the supplied binaries for Zeta Perseids are not internally SnomONE - they are PBXnSIP. Is it possible that these just need to be recompiled as SnomONE and the licenses will work? Thanks, Jason Porter

Well, that was disastrous. The Debian32 build for 4.5.1.1107 on http://wiki.snomone.com/index.php?title=Updates is *not SnomONE* - it is PbxNsip. So my license (SnomONE Yellow) is invalid. Now I have to revert to 4.5.0.1090... is there any chance that the package can be updated to the correct version on the Updates page? Thank you!

Great, thanks! I will update to 4.5.1 and see what happens.

I reset the phone template (snom_3xx_phone.xml) to the new defaults shortly after upgrading to 4.5.0.1090 Epsilon Geminids, which solved an unrelated issue but did not help on the LDAP/addressbook problem. I don't see a PnP setting per account in the domain accounts overview, except on the Create page. Are you suggesting that I need to delete and recreate the user accounts in order to get the PnP address book function working again?

It used to work fine with PnP on SnomONE but it stopped working on some phones in the recent versions and firmwares. I have several Snom 320s that work fine, but Snom 370s and 760s don't work, they don't seem to see the internal LDAP at all.

We are seeing some odd occasional call drops on 4.5.0.1090 (Debian). Are the fixes mentioned in this thread (update to 4.5.1.1102) relevant? Will there be a bugfix release generally? Thanks!

Bumping this topic... can Snom please provide a sample header configuration that mimics the previous "default" settings? Thank you in advance!

That's great info, thanks for your help! I can noodle through it myself of course, but for the benefit of the community would it be possible for Snom to provide a suggested Custom Header syntax that mimics the previous "default" header behavior? I can imagine that it would be helpful to many people who may experience breakage when attempting to upgrade. Thanks again!

Great, thanks for your help. Do you think it's the header syntax being different that is likely the culprit, or is there some other change in 4.5 that may have caused the problem? I'm hoping I'm not the first to have run into this.

Hi everyone! I have been running 4.3.0.5020 with excellent results but recently received a new Snom 760 to add to our system and noticed that PnP is not supported on these new 7xx models until v4.5. Upgrade to 4.5.0.1030 goes smoothly (Debian version) and the system works without problems for both internal calling and inbound calls, but outbound calling results in an error 400 (Bad Request). I took a brief look at the logs, it seems that the SIP invite being sent is different. On 4.3 it is in the form <sip:[destination]@[trunk-ip];user=phone> on trunk [trunkname] On 4.5 it is in the form <sip:[destination]@[pbx-servername];user=phone> on trunk [trunkname] I neglected to get a proper copy of the log since I reverted to 4.3 quickly, but that was the primary difference that I noticed. I can get more detailed logs if needed, of course... but I wondered if anyone here knows what may have changed in the 4.5 builds to cause this difference? Is the default dial plan behavior different, in a way that needs to be accounted for? Up to this point we have been passing everything out to the trunk since it's a very simple configuration, the dial plan on 4.3 is just a * but has been working fine, internal calls have been handled by the default logic and outbound called-number parsing handled by our provider. The trunks themselves seem to work fine, since we get inbound calls without issue, it seems at first glance to be a difference in the outbound invite syntax. Any help or suggestions would be greatly appreciated, I'm hoping that someone here might have run into this already and discovered the solution. Thanks! Jason Porter

I don't at all, we have a small system. But I know several sysadmins locally that manage much larger systems, who have been impressed with our experience here with SnomONE and the Snom phones. The one company I am thinking of would be running ~800 extensions or so, and have concerns about scalability.

Thanks for the info... Snom, if you're listening... direct bug reports are essential. End-customer technical staff need to able to have confidence that Snom will be responsive when a real technical problem occurs in the software or hardware, and I would think it would be essential to Snom's ability to fix problems as well. Let's not forget... this is not a "consumer" product. A VoIP phone system is typically operated by professionals in some regard, if the end customer is not technical enough to self-manage their phone system, they wouldn't be the ones filing a bug report anyway, it would always be the VAR in those cases. All this change has done, really, is cut off the operators of in-house managed systems from being able to give direct information to Snom when they discover a bug. Please restore bug reporting!

Creating new tickets seems to be disabled globally on support.snom.com. It's hard to have confidence that Snom will continue to be responsive to hardware and software problems when bug reports are no longer being accepted. Is this a temporary website problem, or is it a change in policy? Vielen Dank!