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.
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 www.EverestBroadband.com<http://t.sidekickopen16.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs5w...> for technical support: call 800-918-1900 option 1 email 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 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.
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 www.EverestBroadband.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__t.sidekickopen16.com_e1t...> for technical support: call 800-918-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.
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...>
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/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v5d...]
_______________________________________________ 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>
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<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...> 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...> 507-634-WiFi [http://www.snoitulosten.com/wp-content/uploads/2010/01/facebook-small.jpg]<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_minneso...>
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...>
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/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v5d...]
_______________________________________________ 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...>
--
Darin Steffl
Minnesota WiFi
www.mnwifi.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mnwifi.com_&d=DwMFaQ...>
507-634-WiFi
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_minneso...> Like us on Facebook <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_minneso...>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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...> 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...> 507-634-WiFi Like us on Facebook<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_minneso...> _______________________________________________ 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_minneso...>
Gotta limit myself to what you could find on www.cdkglobal.com here? We sell only to automotive dealerships, so our customers range anywhere from a single lot dealership in the middle of corn country to a huge national chain. I can?t go into pricing more than to say that it works for our market, and car dealers aren?t known for throwing away money. David From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alvarez Sent: Wednesday, October 04, 2017 4: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...> 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...> 507-634-WiFi Like us on Facebook<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_minneso...> _______________________________________________ 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_minneso...>
participants (5)
-
bmurray＠transbeam.com -
caalvarez＠gmail.com -
darin.steffl＠mnwifi.com -
David.Hiers＠cdk.com -
paul＠everestbroadband.com