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!

This is good to know, fixing multithreading will bring SnomONE up significantly in scalability compared to other pure softswitch systems, like FreeSWITCH.

Hi everyone, I'm curious about whether the linux builds (particularly the Debian build) are Intel x86 specific, or if they are platform-agnostic. My question is due to the recent increase in ARM server platforms, including the new Nvidia Tegra2 SoC based systems that are hitting the market now. There are full Ubuntu Desktop and Ubuntu Server builds for Tegra2 and other ARM systems, so this is looking very attractive for small/embedded server systems in a performance class significantly above the older SheevaPlug (and similar). Thanks for any information!

We're seeing similar behavior with assisted transfer, the caller ID shows the transferring extension rather than the connected call. Unattended transfers work fine. Is there a reasonable fix for this?

Bump... any new information?

We are experiencing the same behavior on our Snom 320 phones. Very odd LDAP parsing behavior. Any ideas on a fix that doesn't involve disabling LDAP access for our company directory?

Very odd... this was persisting even after phone reboots on Friday, but now today I experimented by leaving test messages from an internal phone, and it seems that leaving a message to a mailbox from another internal extension, and then retrieving and deleting the test message from the user's phone, works to "unstick" whatever was causing the system not to update the MWI data on the phone. This was not working on voicemail left by external callers, causing the "phantom" message counts, but now that it's unstuck, it seems to be working correctly for both external and internal calls. Leaving an "internal" voicemail seems to have straightened it out, for some reason. I'll experiment further to see if this is related to messages left by Hunt Group overflow (which is most of our VM from external callers), or if it was just a temporary glitch.

In the voicemail system, 7 to delete after listening to a message. The message counts drop to zero on the PBX, and the message counts change correctly in the Accounts list view, but the PBX doesn't seem to be updating the phone with the new data.

Hi all, I'm having some difficulty with the new message waiting indications on 4.2.0.3981. We are using Snom 370, Snom 320, and Snom 870, all on firmware 8.4.18 (latest stable). The MWI comes on when the phone receives first notification of a waiting message, but after checking and deleting voicemails, the message count on the phone never drops and the MWI light continues to illuminate or blink (depending on phone). Any ideas? Thanks, Jason Porter

Really? That is bizarre. There is an existing bug report on http://bugzilla.mozilla.org/ that may be relevant, bug 194231. They have a workaround for the behavior but it's apparently a known issue. It's probably worth chiming in on the bug report, though. Thanks!

Hi Matt, The new version is successfully provisioning the 821 here. The phone was already on 8.4.18.