[VoiceOps] SDWAN for VOIP

Tue Oct 3 18:53:03 EDT 2017

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
>
>

-- 
Darin Steffl
Minnesota WiFi
www.mnwifi.com
507-634-WiFi
<http://www.facebook.com/minnesotawifi> Like us on Facebook
<http://www.facebook.com/minnesotawifi>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20171003/3cf51f6a/attachment.html>