Remote provisioning of Grandstream phones is a nightmare. While you can do some of it by a DHCP option, to do everything (phone book, set browser homepage, set timezone, etc,etc), we spent a lot of time writing a perl based system to "watch" for Grandstream phones (by polling the DHCP server looking for the MAC OID), then logging in via HTTP, and basically emulating a human. Would never again do that by choice. Also, we have found they often "go to sleep", it's like the SIP timers are broken, such that when the registration timer expires it **sometimes** doesn't re-register, and if the registrar is restarted it never re-registers. Lastly, when they update firmware, lots of things change, there is little consistency, so we have to re-write Regards....Graeme. http://www.dbroute.com On Fri, 2012-08-17 at 22:34 -0400, voiceops-request at voiceops.org wrote:
Send VoiceOps mailing list submissions to voiceops at voiceops.org
To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/voiceops or, via email, send a message with subject or body 'help' to voiceops-request at voiceops.org
You can reach the person managing the list at voiceops-owner at voiceops.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Re: Grandstream VoIP phones (Matthew S. Crocker) 2. Re: Grandstream VoIP phones (Nathan Anderson) 3. Re: Grandstream VoIP phones (Oren Yehezkely) 4. Re: Grandstream VoIP phones (Eric Wieling) 5. Re: Grandstream VoIP phones (Jason Baugher)
----------------------------------------------------------------------
Message: 1 Date: Fri, 17 Aug 2012 17:06:01 -0400 (EDT) From: "Matthew S. Crocker" <matthew at corp.crocker.com> To: "ryandelgrosso at gmail.com" <ryandelgrosso at gmail.com> Cc: "voiceops at voiceops.org" <voiceops at voiceops.org> Subject: Re: [VoiceOps] Grandstream VoIP phones Message-ID: <B0580C6C-992B-490A-87C2-E26B6DCC9A49 at corp.crocker.com> Content-Type: text/plain; charset=us-ascii
On Aug 17, 2012, at 4:31 PM, Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
I agree with polycom on the speakerphone quality front, BUT they are an absolute nightmare in most other aspects.
The time required to reboot a polycom is measured on a calendar, which can be infuriating when your support team is working remotely with a non-savvy customer.
Not with 4.0.1 firmware
Their web interface is notoriously riddled with security holes (customers do, against our advice place their polycoms bare to the internet and are always surprised when the sip credentials are harvested
All new web interface with 4.0.1 don't know f the wholes have been fixed
The provisioning settings for them are ONLY configurable from the device dialpad, meaning remote configuration is nightmarish. If you have ever listened to a support engineer try to talk someone non-technical through typing out a provisioning URL on that device dialpad you know that it is most certainly one of Dantes levels of hell.
4.0.1 can be set via the web interface. The have also supported DHCP options for quite a while
I will sacrifice some speakerphone functionality to not place my support engineers in that kind of purgatory, especially compared to devices with reasonably decent management like the Cisco devices. Now if only they could get on board with a solution like Innomedia's DMS product which provides out of band management that punches through NAT, THEN you would have a slam-dunk.
Have you looked at Polycom zero touch provisioning? It is DMS in the cloud
-Ryan
From a support perspective On 08/17/2012 11:26 AM, Scott Berkman wrote:
If you care about speakerphone quality and clarity, you should be using Polycom as they destroy everyone else, especially on the models that support HD voice and therefore have the big speaker baffle and better microphones. This is pretty clear when you see that all of Cisco's conference models are just rebranded Polycom's with SCCP firmwares. I'm a big Polycom fan in general, but the Cisco 7940/60 is a close second (just wish it supported more features like subscribe on the 3rd party SIP images). The Cisco's do have some problems with the speakerphone (and handset) at high volume, such as sound still coming out the handset when it shouldn't and clipping.
It's been a long while since I touched a Grandstream, but I like using the feel and weight of the handset as an indicator of build quality, and the older Grandstreams failed that test miserably.
-Scott
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Friday, August 17, 2012 1:06 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Grandstream VoIP phones
It's been a while, but my issue with Grandstream has always been:
1) SIP interoperability & stack problems.
2) Low-end speaker phone hardware, thus bad echo cancellation and duplex handling.
I mainly judge phone hardware by the quality of its speakerphone, since I'm a very heavy user, so it may be a personal bias. However, by that metric, the Cisco 79xx's and Polycoms win, and Grandstreams, Snoms and Aastras lose.
On 08/16/2012 08:07 PM, Carlos Alvarez wrote:
Who else on the list is using them, particularly in a hosted environment? We've just decided to transition to them as our primary recommendation instead of the Cisco SPA series. We did it because of the value and feature set, like having an inexpensive phone with a small BLF, which a lot of customers asked for. I'm wondering if others have tips they've learned along the way, or any advice they want to offer. Also anyone using the advanced features like the browser for anything useful?
For those who haven't tried them, or who like us, didn't like their older models, take another look. We have been surprised at the value they give us. The prices are low, but the functionality and quality are high. They aren't Polycom 600s to be sure, but they are nice phones that have a huge set of features for a great price. Customers are liking them a lot.
Has anyone used the new DECT phone? We currently use the Panasonic DECT phones but they are a nightmare to configure.
If anyone wants to get in touch with them, our Grandstream contact is Dennis Ryan, dryan at grandstream.com <mailto:dryan at grandstream.com> .
-- Carlos Alvarez TelEvolve 602-889-3003
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
Message: 2 Date: Fri, 17 Aug 2012 13:53:14 -0700 From: Nathan Anderson <nathana at fsr.com> To: "'voiceops at voiceops.org'" <voiceops at voiceops.org> Subject: Re: [VoiceOps] Grandstream VoIP phones Message-ID: <C12CA40900F4E0448A2D4E66DFA6A59B17D8873A3D at Demekin.FSI.local> Content-Type: text/plain; charset="us-ascii"
On Friday, August 17, 2012 1:31 PM, Ryan Delgrosso <> wrote:
I agree with polycom on the speakerphone quality front, BUT they are an absolute nightmare in most other aspects.
[snip]
If you haven't used it yet, a lot of your complaints have been address in UCS 4.0, *especially* the boot-up time, which is MUCH improved. Many configuration options which previously required a reboot of the phone after being changed no longer do. The web management interface got a complete overhaul, too, although I haven't become intimately familiar with the new one since I tend to shy away from using the web management anyway and generally stick to central provisioning.
In an office environment, you can use DHCP to set the provisioning URL of the phone so that it doesn't have to be entered in manually on the phone itself, although I understand that for hosted PBX service providers, this isn't really an option. What we have ended up doing for telecommuters is to put the phones behind a small, cheap, L2VPN-capable router (MikroTik RB750), have the router tunnel back to the office, and L2-bridge the phone over the VPN so that it can talk to the same DHCP server as all the phones in the office do. Kills many birds with a single stone: phone traffic is encrypted, the office phone switch doesn't need to have a publicly-routable IP assigned to it, the phones themselves aren't behind a NAT from the perspective of the office phone switch, and all phones -- local and remote -- are provisioned the same way. Win, win, win, win.