[VoiceOps] High Quality, Reliable Voice via the Internet / SIPNOC

Ryan Delgrosso ryandelgrosso at gmail.com
Tue Jun 10 02:02:34 EDT 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20140609/6c23b6ff/attachment-0001.html>


More information about the VoiceOps mailing list