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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]> +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
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
