Jack Russell Racing

www.rackspace.com

It was far more sinister than I thought! When the user goes into voicemail now, the "Virtual Keys" screen appears. "7" was mapped to another extension --- so if a user tried to delete the VM message by hitting 7, it actually tried to transfer the call to that other extension. The quick fix was to simply disable the Virtual Keys altogether. Am I missing something here?

Ahh... might be the blind transfer. I'll look at it today. Thank you!

I'm struggling to get firmware 8.7.3.10 installed on Snom821 phones (we're migrating from firmware 8.4.31) in a SNOM One environment. The problem is simple, but its driving me bonkers! When a user goes into their voicemail to retrieve messages, they could normally just hit "7" to delete an ongoing message and either return to the menu or listen to the next message. Now, with 8.7.3.10, the phone seems to initiate a "HOLD" and put the voicemail connection into hold, and there's no way to even get back to the call. Any ideas on why the keypad doesn't seem to properly control the voicemail like before?

Unplug the power, press and hold the "#" key and replug the power and release the "#" key after 10 seconds. This should start up the rescue mode which helps to reset settings to factory defaults or reflash the phone.

Having lived with 'the other vendors' products for too many years, I cannot possibly imagine going back to *anything* branded with their name. I'd rather carry a SNOM hardphone in my travel kit, than deal with the other supplier's software. It was a constant refrain of: STUN this. Tunnel that. Proxy these. Update here. Downgrade this. Patch mine. Uninstall yours. It was a headache that never ended. Actually, I think the Verizon tag-line "Can you hear me now?" was the corporate mantra of the other vendor. End-to-End SNOM solutions work across our somewhat complex network -- and that's all the proof I need to stay happily in the SNOM family with 821, 320, and Bria deployed on a Windows 2008 server. Your mileage may vary.

Agreed, that will work -- but there's no telling how long it will stay on that specific IP. Until there is a better solution, we've (as I noted before) rolled back to a legacy email provider, non-Gmail.

Same issue here... we "lost" about 2 days of backed up voicemail before we realized what was going on. Rather than mess with Gmail, we switched over to a legacy non-Gmail account and it all flushed through. In the meantime, I was seeing all kinds of Gmail errors about the CNAME records.

A follow-up post, with a big THANK YOU to "pbx support" here... Using Vonage as a SIP provider, the settings that worked are (in Trunks->Number/Call Identification): Prefix: empty Trunk ANI: xxxxxxxxxxx (where xxxxxx is our 10-digit Vonage telephone number) Remote Party/Privacy Indication: Custom Headers Request-URI: Let the system decide From: Based on incoming call To: Let the system decide P-Asserted-Identity: Other "xxxxxxxxxxx" <sip:xxxxxxxxxxx@{trunk-registrar}> (where xxxxxxx is our 10 digit Vonage number) P-Preferred-Identity: Don't use header Remote-Part-ID: Don't use header P-Charging-Vector: Don't use header Privacy Indication: Don't use header All works great now.

Your PM box seems to be full, or cannot accept the message I've just tried to send.

Uggg... I've tried a bunch of different variations, but cannot seem to find the magic bullet. Our incoming caller ID's are fine.... it is simply out going ID that shows on destination (people we're calling out to) as "Unkown". We're on Vonage, if that might help anyone point us in the proper direction.

We recently upgraded to Beta Corona Austrinids, and have only SNOM 821 handsets in the organization. Since the upgrade, our outgoing caller ID seems to have been lost and external recipients of our calls simply see "unknown". Is there a setting somewhere I can reset this?

Probably just a coincidence. Not that my opinion matters, but I think naming software that is suitable for General Release with names like "Alpha" and "Beta" is extremely confusing to those of us who are (or have been) in the I.T. world.

I have a very 'newbie' question... We are running 2011-4.3.0.5021 (Win64) currently. Is 2011-4.5.1005 still considered Alpha/Beta release software, or is this production-level stable?

Were you able to get sipdroid working from 'outside' the SnomOne's network? Mine works fine within the network itself, but once I'm on another WiFi network or over the cellular network, it fails to register. (Yes, I have opened the IP access restrictions to ensure the new IP is permitted).

What happened to the 8.4.34 downloads for the Snom821? The wiki now seems to indicate .33 is only available? http://wiki.snom.com/Firmware/V8/Beta

Well, since idle hands really are the devil's playthings.... I went ahead and updated to 5021 and the new 5033. Everything works great and the LED is now dead http://<<PHONE IP>>/dummy.htm?settings=save&led_call_indicator_usage=PhoneHasCallInStateRinging%20PhoneHasCall Once again, I cannot express how great SNOM One is compared to our previous platform. Thank you.

Hmm. I wonder if I should just wait before upgrading. Am I right in reading that 8.4.33 with the 5021 release would be o.k. ? We are SNOM One 64-bit.

Has anyone tested the new beta 8.4.33 firmware on the SNOM 821 ? I'm anxious to finally kill the blinking missed call LED, but only if it works ok on BLF. (We are back on 8.4.31 because 8.4.32 while killing the LED problem seems to have messed up the BLF's).

Our company switched from 3CX to SNOM One about a month ago. It has been the happiest, most stress-free month I can recall, regarding our phone system. And yes... we did have a lot of experience with 3CX, having used it for about 5 years. 3CX was constant drama between their crazy proxy/tunnel, STUN, reboots, BLF's locked up, etc. etc.... not to mention new releases that introduced new problems.

Our company is still somewhat new to SNOM One (we are ex patriots from 3CX). I have to admit, I do not understand the 821 screens, and how to use them. These two shots are from my 821 phone that auto-provisioned from SNOM One (firmware is 821-8.4.31. We are not on the .32 firmware because of BLF bugs). So.. picture #1 (below)... what is it indicating to me? And why is the layout so wonky when our BLF buttons are supposed to be over on the right side (red LEDs) Picture #2, the overlay (when another person is on a call) is very confusing to see through the transparency. Is this normal?

Can you explain this in more detail? I assume ours are configured as such, but am (candidly) unsure of what you're describing.

OK, so we have made the long awaited switch from 3CX and are happily running SNOM One now. We have all SNOM 821 phones deployed, all of which are considered 'external' to the PBX because it is hosted elsewhere. On 3CX we were obviously victims of SIP hacks on earlier releases of their software. With strong passwords, it diminished greatly, in conjunction with new releases. SNOM seems to have security considerations from the ground up. (thank you) Some basic questions about security: 1) When we bind to MAC addresses on the PBX, does that mean absolutely no other devices can register to that extension, even if they hacked through the password? The MAC is the MAC, and that's all ? Right now, all our SNOM phones are 'MAC defined' in the PBX. Is this safest practice available? 2) We use 8-digit mixed case random passwords. Sufficient? 3) Limit registrations per extension is set to "1". Right? 4) The fixed public IP address of our external phones are white-listed. Should we blacklist everyone else on earth? What is the syntax for this? 5) What else can we do to 'hide' the PBX from things like sipvicious? In playing with a sandbox deployment, I turned logging all the way to maxi-detail. Within 24 hours, that sandbox environment was pounded with sipvicious probes. I assume our production system is getting the same beating.... does the IP blacklist prevent it? Thanks in advance!

And that my friends, is how SNOM (in my use thus far) smokes 3CX. Zero fuss, zero mess. Made the modifications as shown above (thank you!) and whammo.... it works perfectly. I fully expect to relinquish our 3CX licenses in the next 30 days, based on all of our testing and beta-use. I can see a light at the end of the tunnel. The drama of our old system may soon be a distant memory. And mind you... we're not new to 3CX. We lived with it since early V3 versions as a registered/licensed account.

Can you elaborate on this a bit more? I created a button list at the domain level: NAME: 101 TYPE: BLF PARAMETER: <sip:101@nnn.nnn.nnn.nnn;user=phone> LABEL: Mary NAME: 102 TYPE: BLF PARAMETER: <sip:102@nnn.nnn.nnn.nnn;user=phone> LABEL: Steve and so on. I designated the Accounts (extension 101, 102, etc) to use that Button List. The phones are PnP (all are SNOM 821) The button list does not seem download or have any effect on the phones themselves. I suspect I am doing something incorrectly. PnP must be working properly, because the phones autoprovision fine, the firmware downloads from our server, the address book works fine, etc. etc.