1:51 PM
To: voiceops@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 be
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 fl
On 9 Jun 2014 19:57, "Mark R Lindsey" 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: overri
oun...@voiceops.org] On Behalf Of PE
Sent: Monday, June 09, 2014 5:30 PM
To: Mark R Lindsey
Cc: voiceops@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
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 actu
On 06/09/2014 09:45 PM, Mark R Lindsey, ECG wrote:
On Mon, Jun 9, 2014 at 4:14 PM, Alex Balashov mailto:abalas...@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 do
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 t
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.
Ag
Mark,
On Mon, Jun 9, 2014 at 2:50 PM, Mark R Lindsey
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
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"
> wrote:
>
>
>
>
>> On Mon, Jun 9, 2014 a
On Mon, Jun 9, 2014 at 4:14 PM, Alex Balashov
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 sc
14 PM
To: voiceops@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? O
; 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 fe
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
> 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
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 pack
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 rout
17 matches
Mail list logo