[VoiceOps] SDWAN for VOIP

Wed Oct 4 20:12:19 EDT 2017

Velo has two models.

  *   VAR model
  *   Service Provider model

SP’s receive a greater discount, marketing dollars, account team (sales/SE/etc…)

We like the other bigger SP’s opted for the Velo SP model to compete in the market and continue to leverage the core MPLS networks that we’ve invested heavily into over the years.

Having our own cloud gateways allows us to tie into our existing core network and thus provide existing MPLS customers a hybrid MPLS offering by way of SDWAN. Additionally it allows a far better “QOE” for our managed voice applications.

Sizing or trying to explain sizing to a customer isn’t always straight forward. by the book sizing, you’d take all the wan circuits (2 x 10Mb as an example would = 40MB SDWAN) and add up the upstream/downstream . Sizing in velos world is based off RFC2544 benchmark testing.
In my opinion any SDWAN 200Mb or above really jumps out as a significant line item.
Hence the reason Velo has so many insertion models.

[cid:image001.jpg at 01D2770D.2FC9F310]

Brian J. Murray

Director, Sales Engineering & Product Development

Transbeam

p:

212.631.8100 x230  m: 516.574.9696

a:

8 W 38th Street | 7th Fl | New York, NY 10018

e:

bmurray at transbeam.com<mailto:bmurray at transbeam.com>

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alvarez
Sent: Wednesday, October 4, 2017 7:46 PM
To: voiceops at voiceops.org
Subject: Re: [VoiceOps] SDWAN for VOIP

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<mailto: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<mailto:darin.steffl at mnwifi.com>]
Sent: Tuesday, October 03, 2017 3:53 PM
To: Hiers, David <David.Hiers at cdk.com<mailto:David.Hiers at cdk.com>>
Cc: Paul Stamoulis <paul at everestbroadband.com<mailto:paul at everestbroadband.com>>; voiceops at voiceops.org<mailto: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<mailto: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<mailto:paul at everestbroadband.com>]
Sent: Tuesday, October 03, 2017 2:05 PM
To: Hiers, David <David.Hiers at cdk.com<mailto:David.Hiers at cdk.com>>; voiceops at voiceops.org<mailto: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<tel:(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<tel:(800)%20918-1900> option 1      email Tickets at EverestBroadband.com<mailto:Tickets at EverestBroadband.com>

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Hiers, David
Sent: Tuesday, October 03, 2017 4:57 PM
To: voiceops at voiceops.org<mailto: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.

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org<mailto: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
 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<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=>
 <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=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20171005/283f0b40/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 20621 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20171005/283f0b40/attachment-0001.jpg>