 Review by rchandra 
Posted: 5 years ago
member for 8.6 years, 1864 visits, last login: 23 days ago
 Buffalo,Erie,NY
 $15 per month (month by month)
 about 5 days
 "extensive feature set not really matched by anyone else"
 "abysmal, pathetic, horrid, (insert negative adjective here) support"
 "can't really recommend them to anyone"
| Web-site:
Ease of Installation:
Call Quality:
Reliability:
Tech Support:
Value for money:
(ratings below consensus)
|
I had been considering telling Verizon to stick their $47/mo. for flat rate local (not regional) calling and CND w/ name where the Sun doesn't shine for a couple of months after finding out there were many more VoIP to PSTN players for a lot less than Vonage. Late one Thursday afternoon (19-Feb-2004), I finally settled on VoicePulse because they had a flat rate regional calling plan for less than other providers. One of the most attractive features was the ability to do caller-based routing/handling; what they call Filters. I also noticed that VP was at the top of the BBR ratings. So I spent some time reading through their terms of service to make sure there was nothing in them to which I did not want to subject myself, and completed an order. I asked for them to sell me hardware since I expected to be a customer of theirs for a long time. I also dislike shifting costs around. I'd rather pay a fair price for things instead of being told I get a "free" phone when initiating cellular service for example. Unfortunately, I did not see the Voxilla.com SPA-2000/VoicePulse offer until days after my order was completed. Since I make about an hour and a half or less in long distance calls per month, I chose the Local Unlimited +200 service plan. (That's 3:20 for those keeping their own score card  .) Unfortunately, I knew I could not totally shake Verizon since I would be connecting to VP through Verizon DSL. They require one to subscribe to Verizon POTS service on Verizon DSL lines. I was intending to keep it anyway, as I knew modems often work very poorly if at all over "standard" VoIP. (On occasion I have to dial into modems connected to misbehaving routers and such.) I also like being able to dial up my computer and receive faxes with that line.
Still, I had some reservations. For one thing, they don't offer LNP, so I would have to change phone numbers. For another, I always ask myself, if they can't write correct English on their publicly-accessible Web site, what are they going to miscommunicate? And then subsequently, are they going to claim some action I did was counter to their ToS for example? I realize that more and more there are trends in contemporary English that are becoming more and more acceptable, such as splitting infinitives, ending sentences in prepositions, and using "setup" and "login" as a verbs (they're really nouns). But gosh, I had to have learned somewhere around the eighth grade that "it's" is a contraction and "its" is a possessive pronoun. "It's" is used incorrectly in virtually every place on VP's site. One would hope that a business would have someone competent review and correct any such errors in their Web site content. I also had a more fundamental problem with their terms stating there could be charges for not returning the device upon cancellation of service. As presently written, that would depend totally upon what is written in the instructions sent upon cancellation. It seems obvious that this was never changed from the days in which they lent, leased, or rented (but never sold) their CPE (the Cisco ATA-186). I will gladly sell my SPA-2000 back to them for the full price I paid for it if they want, but I would think a change to their ToS would be more in order. Novus/Discover will definitely be asked not to pay them if they demand my CPE back without compensation.
Not too long after placing the order, just for grins and giggles, I went to the "My Account" section of their Web site, and attempted to log in. I was impressed that the Web server immediately recognized that the credentials were valid, but there was nothing to administer because the account had not been provisioned. I was also impressed the next day when I could log in and start administering the features for my account, such as turning on voicemail so that if anyone called my new number they could leave a message. Moreover, since I run ISC dhcpd (as part of RHL9), I could find out the CPE MAC address so I could set up static IP addressing via a host { } entry and adjust iptables rules accordingly.
The CPE arrived in the late morning of the following Tuesday. I plugged in a phone, power, and Ethernet, and bammo! ...nearly instant alternative phone service. I immediately called from my POTS line to my VP number, and was very pleased. The first thing I noticed was the end-to-end delay was perceptible but something under 1/4 second. 250ms is the accepted benchmark for live voice. I later measured it by calling with a USR Courier and displaying the estimated RTT with ATI11, which indicated around 200ms. Initially I thought this was due to the time it might take for packets to reach NJ and return to Buffalo (via ATM?). (It can't go faster than the speed of light, eh? It's extremely fast but not instantaneous.) I found out through experimentation with Line 2 and IP dialing that a significant fraction (if not the majority) of this delay is inherent in Sipura's G711u codec implementation and VP's settings.
I would say the voice quality was comparable to traditional Verizon service. All callers and callees reported to me that everything sounded comparable to the POTS service on their end. Some trouble made itself evident as I tried my first 3-way call. It became choppy, similar to conversing via a PCS phone with marginal signal strength, and had some unsuppressed echoes. Verizon do not sell residential-grade DSL (meaning, affordable for me) with any faster than 128Kbits/s upstream, and after surmising that the SPA (and not the VP end) was handling two audio streams, it was perfectly understandable that two G7111u streams were more than consuming all my upstream bandwidth. Perhaps VoicePulse should make clear on their Web site that 3-way calling will require approximately double the (upstream) bandwidth as a normal call, and that there is considerably more required than just the stated rate of the coded (64kbit/s for just the G711u codec).
The next disappointment was that I noticed for most PSTN callers, there was poor echo cancellation/suppression. Its prominence on most calls amounted to actually enhancing the sound a little, akin to speaking in the middle of a brick courtyard, thus adding ambiance. Callers have reported to me that they do not hear themselves echo, and they have not heard me echo. Had there been any effect noticeable on their end, I would have immediately exercised my 30-day guarantee and searched elsewhere. But there were very few calls where the echo was so prominent that it was distracting to me, and oddly enough, most calls INITIATED by me are echo-free. So in such cases, I just asked to call them back. And it's not all inbound calls; when my friend calls me from his Verizon Wireless phone, I haven't noticed much echo, if any at all. I submitted a support request, and the (non-automated, human) reply was that QoS issues can be difficult to pinpoint and correct, and it would take some time (around two weeks) to correlate other users' experiences in my area, which was perfectly understandable.
I decided after about a week that the service seemed good enough (I could usually ignore or actually enjoyed the echo), and scheduled Verizon to discontinue service for my main POTS line for the end of the week.
The next issue I had was lack of proper repeat dialing functionality. Their Web pages simply state that I should press "5" until I hear a confirmation tone. I found out through a BBR VoIP Forum posting dialog that this was a deprecated Cisco ATA-186 feature, so it's definitely not implemented on either current ATA-186's or my SPA. I also tried the *66 vertical service code (VSC). VP's current configuration (and possibly interoperation with subcontractors such as Broadview Networks) does not seem to send true call supervision (calls unconditionally "complete" on the SIP level and start feeding RTP packets to and from at least the Buffalo PSTN, and any call progress is experienced through RTP-transported call progress tones, presumably from the Buffalo PSTN). Since the SPA almost assuredly operates on SIP messages (and does not perform call progress tone analysis) for repeat dialing, the *66 immediately "succeeds," and repeat dialing degenerates into automated redial instead of its expected behavior.
I sent an email (I can't remember if it was via Mutt or their Web site at this point) to support, got the usual automated reply, and within a reasonable amount of time, I got what seems to be a human's reply. It stated a few important points: they are aware of the repeat dialing problem, their engineers are working to fix it, and most confusingly, if I had anything to add to this case to reply to the email leaving the subject the same (so that their systems can track it I suppose). The issue enlarged to unacceptable proportions from here. My reply queried whether there was an ETR, and if that ETR was on the order of hours, days or weeks. I wrote "confusingly" because at the time I had been a customer of theirs for a little over a month, had submitted around 8 requests (three of which had followups of some sort), and I have yet to have one of these 3 replies show any sign of unprompted (or even automated!) consideration.
This is absolutely, positively, presently the very worst (and most egregious) aspect of VoicePulse. I realize they're very explicit in the Web site knowledgebase that they do not offer inbound support telephonically. Their reasoning sounds perfectly...well...reasonable: we customers really don't want to sit in call queues, they do not want to waste bandwidth usage (VoIP) or telecomm charges (PSTN) for support, and it would be much more efficient simply to send an email. And ordinarily, I would agree with this paradigm. BUT WE NEVER, EVER KNOW WHICH VOICEPULSE REPRESENTATIVES WILL SHOW UP ON ANY GIVEN DAY!! It MAY be the ones that reply within an hour and get things done, or it MAY be the ones that feel perfectly free to ignore their customers indefinitely. If we follow their very own instructions and reply as they ask, we are in effect absolutely, positively ignored. I even re-sent my first reply a couple of days later, thinking some system somewhere had a failure along the way which could not be reported to me, and a re-attempt might be in order. I almost don't really care whether it's a trouble ticket tracking (TTT) system problem or not; it's a problem beyond any ability of mine to diagnose or repair, and as such, all I experience is the end result of being ignored. One could even expect that the SMTP logs are audited (as any competent sysadmin should be doing on a regular basis) and the sysadmin could see that some email transactions have no corresponding TTT activity. Making the big assumption that they might do this, the only conclusion that I feel can be drawn is that they CHOOSE to ignore their customers. Isn't this utterly amazing in a service business? This is allowing SEVERAL DAYS between submission of issues and a reply, and a reply ONLY happens after prompting them for an answer...AGAIN.
After prompting them via another, new message sent via their Web server on the status of two outstanding queries (about the ETR of repeat dialing and the source of CND names), they FINALLY answered that they were continuing to work on repeat dialing and there was no ETR, and that they don't guarantee the accuracy of CND names. But unfortunately for the customer, there also seems to be a bit of what I call CDD, or Comprehension Deficit Disorder. The question posed was the source of name data, not whether they were going to guarantee the accuracy of the data. As far as I'm concerned, the issue is still open.
Another query was the DN (directory number, e.g. a number that is dialed) for voicemail. While the reply had a helpful suggestion that I use the DND (do not disturb) feature to accomplish what I suggested, it didn't actually answer the question. The scenario I posed, simulating the send-all-calls of Avaya et. al., was really only meant as an example. A proper answer should have been one of a limited number of possibilities: 1.) sure, and here it is; 2.) yes, there is one but it is our policy not to disclose it; 3.) no, there isn't one accessible to the customer; or 4.) no, no such thing exists. (I would not be inclined to believe the last one because the Web server shows calls with a destination of "100" in the call detail display. The trouble is 100 cannot be successfully dialed...which is apparent if one tries to forward by dialing *72 100.) I might attempt to ask them again, but at this time it seems like an UTTER waste of time. Are we all to be reduced to one sentence emails, where no detail whatsoever is given, in the hopes of getting explicit answers, no matter how related some questions might be? In this sense, if extraterrestrials visited VoicePulse seeking intelligent life, they'd be well-served by sticking to the engineers, since MOST of their telephony features and their Web site work very well indeed.
As I submit this review, it's now the end of May 2004. I've been a customer of theirs for over three months. I have submitted in the neighborhood of 3 dozen requests, about a third of them with followups submitted as per the instructions in the replies. Precisely ONE of these followups has shown any consideration from a human. Unfortunately, my reply was that I wanted to make sure the replies I was writing are being received, else it didn't make much sense to proceed. The ONE human reply was that yes, it was just fine, and to proceed. So this doesn't SEEM to be a technical problem. This doesn't SEEM to be a problem in protocol on my part. The only way I can possibly see it is they CHOOSE to have abysmal support.
I also notice they are big fans of the Jeopardy! reply. I loathe this, although with the understanding that this is another evolving trend in text-based Internet media. English is SUPPOSED to read top-to-bottom, and not the other way around! I **WISH** VP would follow the time-honored Internet traditions, and either intersperse attribution and quoting with new commentary, or don't include anything at all. Seriously, dear reader...have you ever tried quickly parsing more than a message and one reply in a message thread, and actually follow the discussion? IMHO, it's positively maddening (and utterly stupid). But as stated, I guess I've yet to see anything more than one message and one reply, so I guess this problem at this time is only theoretical (as in, if they actually seemed to give a damn about customer service).
VP also needs to clarify some things in their knowledgebase. For example, telling me to turn on my cable modem and wait 60 seconds is simply not good enough. What if by some quirk I don't have block sync in 60 seconds? Don't you think it's far more reasonable to tell me to power up my cable modem and wait until its indicator LEDs indicate normal operation? If I get block sync in 10 or 15 seconds (hypothetically), why are you wasting the better part of a minute of my time? And it might help to copy-n-paste lines you've actually executed successfully into your KB articles; the iptables line there was not functional (syntactically incorrect). Admittedly, even the correction I suggested was not complete either...which is why you should copy-n-paste from a working system !!
Echo cancellation and suppression issues aside, the sound quality is fairly decent. It does get a little choppy at times. Some of the time it may be attributable to lack of any traffic prioritization on my border system. It's very tough to pinpoint the true cause of any problems, because it may be VP's fault, it may be Verizon Internet Services' fault, it may be one of Verizon's peers fault, it may be Broadview Networks' fault. I'm not willing just yet to brand choppiness all on VoicePulse's hide. If you're contemplating VoIP as a landline replacement, just be aware that with today's Internet it can be a lot more akin to using PCS than anything else. Most of the time, you're probably going to hear and be heard just fine, but other perturbations in the system can affect this.
Then there was the time within the expanse of a week that people could not reach me for few hourse each on three days. Anyone who called only got a busy signal. The correct behavior would have been the ability of the caller to leave a voice mail. Of course, when I asked to have it corrected, it eventually became fixed each time. But when asked about an explanation for it, (you probably saw this coming from a kilometer away), VP just ignore you.
Customer service quality issues aside, the features available via VoicePulse are outstanding.
IMHO, the features not activated via SPA VSC's (that are instead controlled in the VP softswitch) are misfeatures. I would much rather affirmatively set a particular feature to a specific state. As-is, in-switch-only features are all toggles followed by an announcement of the current state of the feature. For the example of DND, instead of dialing something to activate it affirmatively, one must dial *140, then listen to make sure it's on. If you didn't know that it was already on, and you just turned it off, you must dial *140 AGAIN. This is why I do not use VP DND and instead use the SPA DND VSCs *78 (activate) and *79 (deactivate). Using the SPA for this function also has the added benefit that the SPA firmware throws a slowly stuttered dialtone when DND is active (but is overridden by a quickly stuttering dialtone if a message waiting indicator (MWI) SIP message comes in). Programming a forwarding number is only possible "in-switch" via the Web interface, whereas the SPA VSC *72 (and its *73 counterpart) is still left functional by the VP-supplied dial plan settings. Also, it's not apparent (since one does not get another dialtone from the VP switch), after dialing most of the feature access codes (FACs), the switch says in a state ready for more dialing, including additional FACs, or indeed a DN to call. So for example, one only needs to pick up once to toggle DND and then call someone.
As of 30-May-2004, two of the toggle announcements, DND prompting and Anon Call Blocking prompting, sound broken, because they announce " (bong tone) is now {activated, deactivated} ".
Almost every single inbound event can trigger an email to be sent. Each event trigger can have its own email address! Most users will probably enter the same address for every single trigger, but I hope for at LEAST a default address to be added some time to the user's profile. Even better, it looks like customer-supplied lists are already stored all over the profile, and are selected in certain places by drop down lists. An "Email Addr Manager" section could be added to edit this list of email addresses.
Another EXTREMELY ANNOYING quirk to their current implementation is, in order to present certain fields in forms (and hide them when they do not apply), JavaScript is employed, and another form submit is done for each selection! Since the email notification setting is the last item on most (if not all) of these forms, it causes (at least) Mozilla to display the top of the fetched page, and therefore one must scroll the window in order to complete the operation! VP should instead make use of dynamic visibility, as Sipura does on its administration and status page of their CPE.
To keep pace with many of the other VoIP service providers (VSPs? ), VP also have something called Bandwidth Saver, which behind the scenes simply selects from three different codecs: the usual G711u (requiring 64kbps just for the audio), and two G726 varieties, one requiring 32K and another 16K. I barely notice the difference between the 64K and the 32K codecs, so in light of my limited upstream situation, I regularly operate with the G726-32 codec. I'm not 100% sure of the capabilities of an SPA-2000, but VP's implementation does not seem optimal. VP appear to choose to implement this by changing the preferred codec, because once one chooses the desired setting via their Web site, it appears as if VP's servers must assemble and post a new SPA configuration profile to their servers. Then it looks like the SPA must download this new profile (which it can be "encouraged" to do so via rebooting it). Maybe they've tried provisioning with "Use Pref Codec Only: no" and it cannot be coerced via SIP/SDP or whatever into using one preferred by the VP end.
Call Waiting is similarly altered. When deactivated via the Web site, it does not take effect until the SPA downloads an updated profile. If this is selected, dialing the VSCs related to call waiting result in hearing reorder tone, which leads me to believe that the dial plan string is also altered simultaneously. When activated, the Call waiting VSCs do not seem to be included in the dial plan, thus the SPA acts on them. My present suggestion for those wishing to disable Call Waiting for all calls is actually to ENABLE it on the Web, and after the SPA picks up the new config, dial the *57 VSC to disable it. If you ever want to re-enable it, it can be activated for a single call by prefixing your dialing with *71, or re-enable it for all calls with *56. In this case, you have the convenience of changing your state quickly. The downside is that on next SPA reboot you may revert to it being on, plus there is no apparent way to glean its present state.
Another feature is Call Hunting, which is the same concept as coverage paths in Avaya et. al. Along each point of the path, up to three DNs can be rung, with an answering timeout for each step, in 5 second increments in a reasonable range. (Explicitly setting a destination of voicemail in a hunting group is another reason why I wanted to know the inbound VM DN, but, oh, well...) The true power of the Filters feature is that multiple hunting groups may be defined, and separate filters can be applied with the "action target" of a named hunting group.
One of the best advantages of VoicePulse is that anonymous call rejection actually means...well...anonymous call rejection. With Verizon service, if *77 is dialed, it does not preclude some callers from ringing your phone anyway. Verizon's weak excuse is that there is some problem obtaining the data, and thus the call is passed through. I have yet to see this behavior through VP. ACR can be activated both at the VP level and the SPA VSC (*77) level. The advantage at the VP level is that if activated, it's also your call (pun intended ) whether you want VP to collect 10 digits from the caller. Such calls are passed through with a name of "Privacy Manager" and the number that was keyed in.
Another feature is the ability in effect to influence the content of the dial plan string, and take advantage of Sipura's implied digits notation. Called "7-Digit Dialing," the Web interface allows the customer to choose 11 and 7, or 10, 11, and 7-digit dialing. I would think the vast majority of customers want VP to be a replacement for their POTS service, and would like it to behave as much like it as possible. This implies selecting a default area code and dialing only 7 digits to contact numbers within that area code. It appears as if one can choose any area code that VP serves on an inbound basis as the default area code, but most users will probably choose the area code in which they live. Unfortunately, as you may have guessed if you are familiar from setting up SPA-2000's, this requires the same profile post/download as Call Waiting and codec selection, so it can be quite a while before this actually takes effect on your CPE.
The stated turnaround time for these profile-related changes is 5 minutes. I have seen it take a LOT longer. One time I waited about 20 minutes for a Call Waiting update, and it still hadn't happened, so I just gave up and went away for a while. Although in the past I would have eagerly offered to assist them in getting this working properly, my experience with their email support indicates I would be wasting a lot of my time.
The voicemail is pretty generic and not too full of features. One can establish an email address which will be notified when a caller leaves a voice message. Optionally, one can have a MS WAV representation of the message sent as a MIME attachment. Since the VM system will not pronounce the date/time the message was left accurately, notification is almost mandatory, and the WAV attachment is very convenient. (It would be more difficult to correlate notifications with VMs otherwise.) Unless VP and Sipura implement S-RTP, you might as well send the WAV, since third parties will have the ability to intercept the audio either way. The clock skew was about 10 minutes behind at the time I wrote this, and further confusion is added by pronouncing the time the message was left in GMT (rather than ET as my profile specifies). Additionally, VP VM does NOT provide any overt way (if any at all) to skip backwards or forwards within messages while playing them. If you have the WAV sent to you, you can use any means you wish to play it. Most popular WAV players support playing arbitrary parts of the file, especially with a slider in graphical environments (XMMS for example).
One cutesy but not particularly personally useful VM feature is multiple pre-labeled "folders" into which one can file messages. The default new and old folders get used all the time, but others exist for "work," "family," and "friends." There is also a feature that will be handy for people with multiple lines to forward a message to anther mailbox (mailbox == DN). The event loop is a simple previous/repeat/next/file-it/delete/i-am-done affair.
There are many practical reasons to enable VM at all times. I recommend that all users enable VM just in case you get knocked off the Internet. Alternately, VP provide a feature, Line Unavailable Forwarding, which specifies a DN to which to forward calls should VP not be able to contact your CPE. This could be a subscriber's cell phone for example, and can be distinct from the forward all number ("Absolute Forwarding"). It will also be there to take a message should your SPA indicate "busy" for any reason, be it DND, call blocking, { already on a call with another call on Call Waiting, and third, fourth, etc. call comes in }, etc.
I personally use a voice modem attached to my SPA and vgetty to have more control over VM handling. I keep VM turned on should that not be up for any reason.
Also, VP's system records three audio segments: VM greeting, busy message, and name. I could not find any instance where anything but the first one was used. I'm not aware of any way (a la Avaya Audix) to revert to system default prompts (e.g., {play-subscribers-name-file} "...is busy", or "extension..."{pronounce-subscribers-DN} "...is busy"). Also lacking is the ability to review, record, append, and many other features. I don't know how it would impact the "bottom line," but if they really want to call their VM "advanced," they should buy some Avaya Audix systems for that.
So if you feel you're less technically inclined, and could possibly need average to above average support from your VoIP-to-PSTN provider, I currently cannot at ALL recommend VoicePulse. If they choose to ignore someone with my level of expertise, IMHO one can reasonably assume even worse treatment of an average or non-technical customer. If you can forgo typical customer service levels, I *can* recommend VoicePulse, because their current feature set is AMAZING and has been showing CONSTANT improvement. Now...if they only expended as much energy in attending to their customer service as they do in new feature development and deployment, they'd really have something.
Followup comments: | Forums » comments on review of VoicePulse |
|
VoicePulse
(15)
(29)