[VoiceOps] SDWAN for VOIP

Wed Oct 4 19:46:13 EDT 2017

What sizes are the companies you're using this with, and what sort of costs
are we looking at?  (Velocloud has no pricing online, so I assume it must
be crazy expensive?) We have medium-size customers (100-600 employees) with
MPLS for the primary locations but most have some remote sites with wild
internet that could stand some improvement.  Though it may be cost
prohibitive for sites that have very few issues as it is.

On Tue, Oct 3, 2017 at 5:59 PM, Hiers, David <David.Hiers at cdk.com> wrote:

> We sell it.  That’s the only way we can really tweak it for our apps and
> architecture.
>
>
>
> There is some goodness to be had from a generic solution, but owning the
> entire path is the only way to get the kind of control that we really need.
>
>
>
> David
>
>
>
>
>
> *From:* Darin Steffl [mailto:darin.steffl at mnwifi.com]
> *Sent:* Tuesday, October 03, 2017 3:53 PM
> *To:* Hiers, David <David.Hiers at cdk.com>
> *Cc:* Paul Stamoulis <paul at everestbroadband.com>; voiceops at voiceops.org
> *Subject:* Re: [VoiceOps] SDWAN for VOIP
>
>
>
> Do you resell VeloCloud with a voice solution or just refer your voice
> customers to them to purchase the service?
>
>
>
> On Tue, Oct 3, 2017 at 4:47 PM, Hiers, David <David.Hiers at cdk.com> wrote:
>
> Hi guys,
>
> The voice requirements that were used were pretty simple-sounding,
> something like:
>
>
>
> 1.      Move a call multiple times between multiple links in response to
> multiple link failures without losing audio quality or signaling
>
> 2.      Conceal up to 5% packet loss from SIP and RTP on a single link
>
> 3.      Simultaneously meet requirements 1 and 2 for any combination of
> links
>
>
>
> The requirements sound simple, but you folks know how hard it would be to
> implement something like this.  We had other requirements to deal with our
> core application and data-center oddities, but those voice ones can pretty
> much stand alone.
>
>
>
> In retrospect, we might have phrased #2 in terms of “MOS per unit loss”.
> Something like “Calculated MOS score on a g.711 call can drop no more than
> 0.1 with 5% packet loss” would have been more measureable than a subjective
> ‘can you hear me now’ kind of opinion.
>
>
>
> We wound up going with VeloCloud.
>
>
>
> Best advice is to shoot for the moon on your requirements, and test the
> living daylights out of it.
>
>
>
> Staying away from all the NDA-breaking geeky stuff, here are warning signs
> to keep an eye out for:
>
>
>
> 1.      Vendors that don’t let you run your own pilot.  If they insist in
> being right there with you, their stuff isn’t ready for production.
>
> 2.      Over-reliance on fancypants graphs.  Amazing graphs are great and
> all, but not even close to being as important as actually fixing problems.
>
> 3.      Scoping assertions.  One vendor asserts that “an SDWAN can only
> be as good as the underlay network” because they simply can’t do error
> CORRECTION.  If you buy off on their assertion, you’re doomed.
>
> 4.      Hiding behind “best effort”.  Can’t tell you how many times we
> heard “oh, that feature is just best-effort, it might not work all the
> time” when we pressed them.  For EVERY feature that is important, be sure
> that you nail them down what actually works 100% of the time and what they
> implement as some kind of throw-away ‘best-effort’ slideware feature.
>
>
>
>
>
> David
>
>
>
>
>
>
>
> *From:* Paul Stamoulis [mailto:paul at everestbroadband.com]
> *Sent:* Tuesday, October 03, 2017 2:05 PM
> *To:* Hiers, David <David.Hiers at cdk.com>; voiceops at voiceops.org
> *Subject:* RE: SDWAN for VOIP
>
>
>
> David, thanks for the info – we are currently looking at this technology
> as well for services to remote locations and redundancy of network – can
> you share which carrier you are using and with whom you are satisfied? Have
> you looked at any of the other carriers offering same? how about any other
> pros or cons between them?
>
>
>
> Everest Broadband - Your Local Voice & Data Network Experts – we’re always
> nearby
>
>
>
> Paul Stamoulis          1 212 444 3003 <(212)%20444-3003>
> www.EverestBroadband.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__t.sidekickopen16.com_e1t_c_5_f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs5w6vTbVdD-2DFY7dKXNRW8qlRZx56dLX3f4fbXk602-3Ft-3Dhttp-253A-252F-252Fwww.everestbroadband.com-252F-26si-3D5992006913097728-26pi-3D1d0f87e6-2Da797-2D43e8-2Db66d-2D034c045bc663&d=DwMFAg&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ&m=izAmTbT9C20gHgUDya0H06r8yOS8p-AXQJ_EmhcYpNo&s=AHhRpyMCK2g4uzsU0ecTvykfvAdUSEYkz4AqUJ6yXR4&e=>
>
>
>
> for technical support:    call 800-918-1900 <(800)%20918-1900> option
> 1      email Tickets at EverestBroadband.com
>
>
>
> *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org
> <voiceops-bounces at voiceops.org>] *On Behalf Of *Hiers, David
> *Sent:* Tuesday, October 03, 2017 4:57 PM
> *To:* voiceops at voiceops.org
> *Subject:* [VoiceOps] SDWAN for VOIP
>
>
>
> Hi,
>
> Is anyone else using SDWAN for VOIP?
>
>
>
> We can move a call between links and impose 10% packet loss and the users
> pretty much don’t notice anything.  No loss of call control or mid-call
> signaling, barely detectable impact on audio quality.
>
>
>
> This is pretty much the only way we’ve found to deliver the quality that
> our (very demanding) customers require using a ‘bring your own bandwidth’
> model.
>
>
>
> It has been such a game-changer for us that I’m being sent to SIPNOC to
> give a talk about it.
>
>
>
> David
>
>
> ------------------------------
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, notify the sender immediately by
> return email and delete the message and any attachments from your system.
>
> [image:
> http://t.sidekickopen16.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v5dr0PW2z8MG45w02vYN5wM2WgQFLCHW4TkRz91k1H6H0?si=5992006913097728&pi=1d0f87e6-a797-43e8-b66d-034c045bc663]
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_voiceops&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ&m=s6pk8j_qB7GpJfZYr1BBzPk-Pvf2reeSMlApRLHUvkE&s=cuzZVcDA39JaRygkMLncWBqJUPzg506GPQLrNvfCb-w&e=>
>
>
>
>
>
> --
>
> Darin Steffl
>
> Minnesota WiFi
>
> www.mnwifi.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mnwifi.com_&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ&m=s6pk8j_qB7GpJfZYr1BBzPk-Pvf2reeSMlApRLHUvkE&s=q5c3dEn9XA2L1fPeOjU1HwPJQuZ9G01nMge0m4ytryM&e=>
>
> 507-634-WiFi
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_minnesotawifi&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ&m=s6pk8j_qB7GpJfZYr1BBzPk-Pvf2reeSMlApRLHUvkE&s=Eyu8rF5d7BCni9LG0To3UoqvUI3etuwZYM1zq75hEEM&e=>
>  Like us on Facebook
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_minnesotawifi&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ&m=s6pk8j_qB7GpJfZYr1BBzPk-Pvf2reeSMlApRLHUvkE&s=Eyu8rF5d7BCni9LG0To3UoqvUI3etuwZYM1zq75hEEM&e=>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20171004/2220d3ac/attachment.html>