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