High Quality, Reliable Voice via the Internet / SIPNOC
At SIPNOC this week, we're having a "Birds of a Feather" session on delivering quality voice services across the public Internet. A few techniques to make voice across the Internet better: 1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route 2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure 3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice. So what OTHER techniques are there? Which techniques don't work? Yeah, it's the Internet. It's going to have failures. You're going to have bad days. But surely there are ways to improve the odds.
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
On 06/09/2014 02:50 PM, Mark R Lindsey wrote:
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Question: does this actually reduce packet-drop exposure? One would think that with a longer duration of audio captured in a given packet, the loss of any individual packet would have more negative impact upon voice quality as subjectively experienced. Or does this thesis lean on countervailing tendencies, such as overall reduced PPS in a higher ptime scenario? -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906
In a previous life my $PARTIME_JOB did some VoIP testing and found that VoIP testing through a VPN tunnel resulted in a higher MOS. What we eventually realized is that undelivered packets over the WAN were automatically re-transmitted by the VPN. This only works if the missing packet can be re-transmitted before the far side's jitter buffer is drained. So raising the jitter buffer to 60 or 80 msec can help if the RTT is less than 60 msec. Frank -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Monday, June 09, 2014 3:14 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] High Quality, Reliable Voice via the Internet / SIPNOC On 06/09/2014 02:50 PM, Mark R Lindsey wrote:
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Question: does this actually reduce packet-drop exposure? One would think that with a longer duration of audio captured in a given packet, the loss of any individual packet would have more negative impact upon voice quality as subjectively experienced. Or does this thesis lean on countervailing tendencies, such as overall reduced PPS in a higher ptime scenario? -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Mon, Jun 9, 2014 at 4:14 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 06/09/2014 02:50 PM, Mark R Lindsey wrote:
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Or does this thesis lean on countervailing tendencies, such as overall reduced PPS in a higher ptime scenario?
You're on the right track with ptime. The theory idea is that: (A) Most packet loss is due to congestion (B) When congestion occurs the router selects a packet to drop (C) The routers pick a packet to discard more-or-less at random (D) Therefore, A 180 byte packet is just as likely to be dropped as a 1500 byte packet. (E) A ptime=20 generates twice the packets as ptime=40, and therefore ptime=20 has twice the exposure to the discards (F) You can reduce your exposure to discards by reducing the number of packets you have in the queue. (G) Reduced discards mean better audio quality.
One problem with that theory. At 40ms you have more samples per packet making it more difficult for a PLC algorithm to interpolate . Bigger chunks of audio are now missing. Sent from my iPhone
On Jun 9, 2014, at 9:45 PM, "Mark R Lindsey, ECG" <lindsey at e-c-group.com> wrote:
On Mon, Jun 9, 2014 at 4:14 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 06/09/2014 02:50 PM, Mark R Lindsey wrote: 2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Or does this thesis lean on countervailing tendencies, such as overall reduced PPS in a higher ptime scenario?
You're on the right track with ptime. The theory idea is that:
(A) Most packet loss is due to congestion
(B) When congestion occurs the router selects a packet to drop
(C) The routers pick a packet to discard more-or-less at random
(D) Therefore, A 180 byte packet is just as likely to be dropped as a 1500 byte packet.
(E) A ptime=20 generates twice the packets as ptime=40, and therefore ptime=20 has twice the exposure to the discards
(F) You can reduce your exposure to discards by reducing the number of packets you have in the queue.
(G) Reduced discards mean better audio quality.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
But isn't congestion caused by bytes and not number of packets? So, by that argument, larger packets will fill the queue faster than smaller and thus have a higher propensity to drop? And when it does, it is a bigger chunk of audio so it could actually reduce quality rather than improve it. Again, it's all theoretical unless someone has the tools, time, and motivation to publish an article with empirical data. On Jun 9, 2014, at 9:45 PM, "Mark R Lindsey, ECG" <lindsey at e-c-group.com> wrote:
On Mon, Jun 9, 2014 at 4:14 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 06/09/2014 02:50 PM, Mark R Lindsey wrote: 2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Or does this thesis lean on countervailing tendencies, such as overall reduced PPS in a higher ptime scenario?
You're on the right track with ptime. The theory idea is that: (A) Most packet loss is due to congestion (B) When congestion occurs the router selects a packet to drop (C) The routers pick a packet to discard more-or-less at random (D) Therefore, A 180 byte packet is just as likely to be dropped as a 1500 byte packet. (E) A ptime=20 generates twice the packets as ptime=40, and therefore ptime=20 has twice the exposure to the discards (F) You can reduce your exposure to discards by reducing the number of packets you have in the queue. (G) Reduced discards mean better audio quality. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Jun 9, 2014, at 9:00 PM, PE wrote:
But isn't congestion caused by bytes and not number of packets? So, by that argument, larger packets will fill the queue faster than smaller and thus have a higher propensity to drop? And when it does, it is a bigger chunk of audio so it could actually reduce quality rather than improve it.
Not always..... If you look at the details of a lot of the hardware and software forwarding setups on network gear, you'll find that there's an outgoing buffer that packets go into if the port is already busy transmitting a frame. Those buffers are typically sized such that they can hold a certain number of packets of MAX MTU for the device or interface, and it doesn't matter if it's 80 bytes of voice frame or an 8Kbyte jumbo frame going into the TX queue. Of course QoS rules, congestion control mechanisms, WRED, and all sorts of other things can muck with the way a queue is serviced or filled, so YMMV, RTFM, etc. --Chris
Looking at it from the wrong viewpoint. In this situation we are assuming that VOIP traffic is sharing a whole series of transmit queues with no VOIP traffic, specifically general Internet traffic. VOIP and similar is relativly high PPS for the data rate, but is in comparison to general data flows low volume (octets wise) and constant (VBR action in codecs can cause a flow to vary in B/W by > 50% in short time windows but the actual variance is small, generally single or double digit kbps, not double or triple digit mbps. If all the traffic in a queue was VOIP or equiv, than in the aggregate of tens to thousands of calls the rate is very, very smooth and you can go ahead and load that pipe to 95% or better on a 30 second average without burst drop. General data usage... Very, very bursty. These days a $350 laptop is easily capable of generating 200KB bursts at 600 - 800 Mbit without even trying. Unless the core links handling bulk traffic are a large multiple of the customer interface rates (real or emulated by a very granular shaper) and on average have a good multiple of the largest customer service rate free you are going to see burst drop On 6/9/14, 6:00 PM, PE wrote:
But isn't congestion caused by bytes and not number of packets? So, by that argument, larger packets will fill the queue faster than smaller and thus have a higher propensity to drop? And when it does, it is a bigger chunk of audio so it could actually reduce quality rather than improve it.
Again, it's all theoretical unless someone has the tools, time, and motivation to publish an article with empirical data.
On Jun 9, 2014, at 9:45 PM, "Mark R Lindsey, ECG" <lindsey at e-c-group.com <mailto:lindsey at e-c-group.com>> wrote:
On Mon, Jun 9, 2014 at 4:14 PM, Alex Balashov <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote:
On 06/09/2014 02:50 PM, Mark R Lindsey wrote:
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Or does this thesis lean on countervailing tendencies, such as overall reduced PPS in a higher ptime scenario?
You're on the right track with ptime. The theory idea is that:
(A) Most packet loss is due to congestion
(B) When congestion occurs the router selects a packet to drop
(C) The routers pick a packet to discard more-or-less at random
(D) Therefore, A 180 byte packet is just as likely to be dropped as a 1500 byte packet.
(E) A ptime=20 generates twice the packets as ptime=40, and therefore ptime=20 has twice the exposure to the discards
(F) You can reduce your exposure to discards by reducing the number of packets you have in the queue.
(G) Reduced discards mean better audio quality.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- ------------------------------------------------------------------------ Christopher E. Brown <chris.brown at acsalaska.net> desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ------------------------------------------------------------------------
On 06/09/2014 09:45 PM, Mark R Lindsey, ECG wrote:
On Mon, Jun 9, 2014 at 4:14 PM, Alex Balashov <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote:
On 06/09/2014 02:50 PM, Mark R Lindsey wrote:
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Or does this thesis lean on countervailing tendencies, such as overall reduced PPS in a higher ptime scenario?
You're on the right track with ptime. The theory idea is that:
(A) Most packet loss is due to congestion
(B) When congestion occurs the router selects a packet to drop
(C) The routers pick a packet to discard more-or-less at random
(D) Therefore, A 180 byte packet is just as likely to be dropped as a 1500 byte packet.
(E) A ptime=20 generates twice the packets as ptime=40, and therefore ptime=20 has twice the exposure to the discards
(F) You can reduce your exposure to discards by reducing the number of packets you have in the queue.
(G) Reduced discards mean better audio quality.
That makes sense. But: 1) No matter which packet duration you use, a VoIP conversation is still going to generate far more PPS than, say, HTTP, which is the sort of application that typically traffics in packets close to the MTU, i.e. 1500. 2) That still means RTP packets are one of the more likely things to be discarded. 3) Given that this is the case, a discard of a longer packet would affect the conversation more than a discard of a shorter one. Or not? -- Alex -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906
1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route Interesting idea. Who's doing this and how is it working for you? Are you using static routes or altering BGP? Other?
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure Alex B may be right on this. Hard to speculate without hard evidence with lots of volume to back it up. I do know, however, that some carriers (Verizon comes to mind) will not support anything other than 20ms, so it is easier to standardize on a single ptime rather than try to customize each install.
3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice. Are they suggesting SIP over TCP or some other out-of-band TCP to help manage quality to the endpoint. While we have a small amount of SIP/TCP going on to support older BLF integrations, I am not a fan. It adds overhead to the core (SBC) and also means that an SBC switch from active to standby will drop the device.
On Mon, Jun 9, 2014 at 2:50 PM, Mark R Lindsey <lindsey at e-c-group.com> wrote:
At SIPNOC this week, we're having a "Birds of a Feather" session on delivering quality voice services across the public Internet.
A few techniques to make voice across the Internet better:
1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice.
So what OTHER techniques are there? Which techniques don't work?
Yeah, it's the Internet. It's going to have failures. You're going to have bad days. But surely there are ways to improve the odds.
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 06/09/2014 05:30 PM, PE wrote:
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Alex B may be right on this. Hard to speculate without hard evidence with lots of volume to back it up. I do know, however, that some carriers (Verizon comes to mind) will not support anything other than 20ms, so it is easier to standardize on a single ptime rather than try to customize each install.
Yeah, it's hard to say. There are lots of variables that could potentially pull this in different directions, and possibly still render it good advice. For instance, with fewer packets and a constant amount of packet loss, a small absolute number of packets get lost. and maybe that leads to more reasonable adaptive jitter buffer behaviour that introduces less perceived artifacts or loss into the speech path than does the loss of a larger amount of packets. Still, my instinct is that more packets with a smaller payload is better in a scenario with packet loss. It certainly seems that online games take this view as well, given the enormous amount of position updates that first-person shooters send, for instance. The idea is that even if some of them don't get there, all is not wholly lost. -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906
1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route
Interesting idea. Who's doing this and how is it working for you? Are you using static routes or altering BGP? Other?
At my full time job we see a measurable difference in MOS based upon the routing preferences out of and in to our AS? I can?t count how many times a simple change in routing policy has improved perceived quality. This is one of the many reasons my office stresses carrier diversity. From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of PE Sent: Monday, June 09, 2014 5:30 PM To: Mark R Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] High Quality, Reliable Voice via the Internet / SIPNOC
1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route
Interesting idea. Who's doing this and how is it working for you? Are you using static routes or altering BGP? Other?
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
Alex B may be right on this. Hard to speculate without hard evidence with lots of volume to back it up. I do know, however, that some carriers (Verizon comes to mind) will not support anything other than 20ms, so it is easier to standardize on a single ptime rather than try to customize each install.
3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice.
Are they suggesting SIP over TCP or some other out-of-band TCP to help manage quality to the endpoint. While we have a small amount of SIP/TCP going on to support older BLF integrations, I am not a fan. It adds overhead to the core (SBC) and also means that an SBC switch from active to standby will drop the device. On Mon, Jun 9, 2014 at 2:50 PM, Mark R Lindsey <lindsey at e-c-group.com> wrote: At SIPNOC this week, we're having a "Birds of a Feather" session on delivering quality voice services across the public Internet. A few techniques to make voice across the Internet better: 1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route 2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure 3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice. So what OTHER techniques are there? Which techniques don't work? Yeah, it's the Internet. It's going to have failures. You're going to have bad days. But surely there are ways to improve the odds.
mark at ecg.co +1-229-316-0013 <tel:%2B1-229-316-0013> http://ecg.co/lindsey
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Test, Please ignore. Faisal Imtiaz ----- Original Message -----
From: "Mark R Lindsey" <lindsey at e-c-group.com> To: voiceops at voiceops.org Sent: Monday, June 9, 2014 2:50:57 PM Subject: [VoiceOps] High Quality, Reliable Voice via the Internet / SIPNOC
At SIPNOC this week, we're having a "Birds of a Feather" session on delivering quality voice services across the public Internet.
A few techniques to make voice across the Internet better:
1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice.
So what OTHER techniques are there? Which techniques don't work?
Yeah, it's the Internet. It's going to have failures. You're going to have bad days. But surely there are ways to improve the odds.
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Based on what we have seen.... # 1. Yes having better connectivity to is a given must, having the ability to change routes via multiple inbound IP Transit peers is a pre-requisite for this. # 2. Not sure about this, it is more likely to break stuff than reduce exposure to packet drop. # 3. I would say this differently ,( see below). Our Experience are as follows:- ..... Avoid Messing with the MEDIA, as much as possible.... Less number of Codec Conversions the better the quality. Packet Loss is always a big culprit, but identifying the source of it is a bit more challenging than doing the face value troubleshooting. (Source of Media can be different than the perceived ITSP's network .... ) And using devices on the Edge (customer premises, facing the provider), it is very important to have devices that will respect the DSCP/TOS tags and follow them..... Lots of device do a good job of it, and many other don't. (There is no correlation on less expensive device is not as good as a more expensive device). The key to good quality Audio is.... Avoid Congested Network Paths. Avoid Media Conversion / Codec Conversions ... Avoid packet drops at Customer Edge. It is rather simple, but gets complicated in tracking down the source of the problem... Which becomes a whole different topic ! Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----
From: "Mark R Lindsey" <lindsey at e-c-group.com> To: voiceops at voiceops.org Sent: Monday, June 9, 2014 2:50:57 PM Subject: [VoiceOps] High Quality, Reliable Voice via the Internet / SIPNOC
At SIPNOC this week, we're having a "Birds of a Feather" session on delivering quality voice services across the public Internet.
A few techniques to make voice across the Internet better:
1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice.
So what OTHER techniques are there? Which techniques don't work?
Yeah, it's the Internet. It's going to have failures. You're going to have bad days. But surely there are ways to improve the odds.
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Mark, On Mon, Jun 9, 2014 at 2:50 PM, Mark R Lindsey <lindsey at e-c-group.com> wrote:
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
A good number of years ago (it shocks me to realize it was probably about 10!) I was a product manager for SIP products at one of the IP-PBX vendors. I thought that we ought to be able to do better than having a ptime of only 20 ms and so I did some digging. I was very surprised to see the sheer number of places where there were assumptions made that the ptime would always be 20 ms. In software... in hardware... in applications... not just from the vendor I was with but in the products of other vendors as well. It seemed like most everywhere SIP was deployed there was an assumption of a 20ms ptime - and in many cases no way to use any other value. Now, obviously a great amount can change in 10 years - or not. (This *is* telecom we're talking about!) My point is really that this one might be extremely hard to change in a way that would be widely useful and interoperable. I realize others have raised technical concerns... mine is more on the deployment side. While I think it is interesting to explore, I think part of that exploration should include whether changing the ptime is something that can actually be done on any kind of realistic timeframe. Just my 2 cents, Dan -- Dan York dyork at lodestar2.com +1-802-735-1624 Skype:danyork My writing -> http://www.danyork.me/ http://www.danyork.com/ http://twitter.com/danyork
Ill side with Dan on this one. its absolutely interesting to do a 10,20,40ms packet test out over dirty internet with only a few endpoints involved but then to make that work with the whole ecosystem and out to PSTN means you need to either: 1: perform transrating at the edge on all calls to turn your 40ms access side stream into 20ms that all your app servers will digest inside the network and the PSTN will accept. This will require DSP or transcoding resources of some kind for every stream or 2: You will need to make sure anything the endpoint might want to have a conversation with will support this 40ms stream. Good luck when so much of this gear seems to be "write once, run forever, patch never" I think the real answer here is in encapsulation and media redundancy. On 6/9/2014 7:00 PM, Dan York wrote:
Mark,
On Mon, Jun 9, 2014 at 2:50 PM, Mark R Lindsey <lindsey at e-c-group.com <mailto:lindsey at e-c-group.com>> wrote:
2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure
A good number of years ago (it shocks me to realize it was probably about 10!) I was a product manager for SIP products at one of the IP-PBX vendors. I thought that we ought to be able to do better than having a ptime of only 20 ms and so I did some digging. I was very surprised to see the sheer number of places where there were assumptions made that the ptime would always be 20 ms. In software... in hardware... in applications... not just from the vendor I was with but in the products of other vendors as well. It seemed like most everywhere SIP was deployed there was an assumption of a 20ms ptime - and in many cases no way to use any other value.
Now, obviously a great amount can change in 10 years - or not. (This *is* telecom we're talking about!) My point is really that this one might be extremely hard to change in a way that would be widely useful and interoperable. I realize others have raised technical concerns... mine is more on the deployment side. While I think it is interesting to explore, I think part of that exploration should include whether changing the ptime is something that can actually be done on any kind of realistic timeframe.
Just my 2 cents, Dan
--
Dan York dyork at lodestar2.com <mailto:dyork at lodestar2.com> +1-802-735-1624 Skype:danyork My writing -> http://www.danyork.me/ http://www.danyork.com/ http://twitter.com/danyork <http://twitter.com/danyork>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 9 Jun 2014 19:57, "Mark R Lindsey" <lindsey at e-c-group.com> wrote:
At SIPNOC this week, we're having a "Birds of a Feather" session on
delivering quality voice services across the public Internet.
A few techniques to make voice across the Internet better:
1. For packets from the ITSP to the customer: override the default BGP
routing to choose an alternate route Don't forget that if you're a network operator you should be on as many Internet Peering Exchange Points as possible. Easier for us in the UK and Europe as it's a different model to the US. Keeps routes as short as possible and mostly on the same switching kit. We've also found that cpe kit lies and 20ms is sometimes the only option. Thanks, Gavin. http://www.surevoip.co.uk/about/our-network
"3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice." I think this refers to items this post lists: http://www.voip-info.org/wiki/view/VOIP+and+VPN There are some merits to this where congestion isn't the problem but instead more nefarious things like throttling by an ISP. When *heavy* congestion is the problem, TCP is the enemy of RTP. Specifically you *want* packets to drop when there is congestion and not get re-transmitted or hold up transmission of the rest of the payload. Dropping 1,2 or 5 packets per second isn't likely going to be much of an issue depending on how dense or sparse the drops are in a particular sequence. This little blurb has always been helpful in explaining the concept to people: http://www.voiptroubleshooter.com/problems/packetloss.html In my opinion however the future of net neutrality becomes more of a major discussion point for VoIP over the public internet and ITSPs who want to support customers who bring their own bandwidth. Jesse -----Original Message----- From: Mark R Lindsey [mailto:lindsey at e-c-group.com] Sent: Monday, June 09, 2014 1:51 PM To: voiceops at voiceops.org Subject: [VoiceOps] High Quality, Reliable Voice via the Internet / SIPNOC At SIPNOC this week, we're having a "Birds of a Feather" session on delivering quality voice services across the public Internet. A few techniques to make voice across the Internet better: 1. For packets from the ITSP to the customer: override the default BGP routing to choose an alternate route 2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop exposure 3. EdgeWater brings us this one: actively manage TCP streams from Internet to CPE to provide better quality for Voice. So what OTHER techniques are there? Which techniques don't work? Yeah, it's the Internet. It's going to have failures. You're going to have bad days. But surely there are ways to improve the odds.
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents.
participants (13)
-
abalashov＠evaristesys.com -
avorlando＠yahoo.com -
brandon＠bitradius.com -
cboyd＠gizmopartners.com -
chris.brown＠acsalaska.net -
dyork＠lodestar2.com -
faisal＠snappytelecom.net -
frnkblk＠iname.com -
ghenry＠suretec.co.uk -
jhoward＠ShoreTel.com -
lindsey＠e-c-group.com -
peeip989＠gmail.com -
ryandelgrosso＠gmail.com