Re: Cost-effectivenesss of highly-accurate clocks for NTP

[Mel Beckman <mel () beckman org>]

Lamar,

Although VoIP has different technical challenges than TDM, they are all surmountable. Usually VoIP problems result from 
poor network design (e.g., mixed traffic with no QoS, Internet transport with no guarantees, etc). Public safety 
networks are generally well designed, don’t use the Internet, and support a single type of traffic: audio streams. I’ve 
done demonstrations of VoIP that works well in this environment, and you get the advantages of IP routing for 
redundancy, as opposed to clunky T1 failover mechanisms usually based on hardware switches.

But public safety customers are not swayed. TDM works, and it’s the gold standard. They don’t want to change, and you 
can’t make them. They only see risk, no reward. BTW, in the TDM model, remote data and audio are usually two different 
systems, which is probably a good idea for redundancy: you might lose audio or data, but rarely both.

In any event, I’m only proposing that public safety upgrade their audio systems to VoIP (or cellular-style private GSM, 
which is in essence VoIP). But nobody is willing.

 -mel

> On May 16, 2016, at 9:02 AM, Lamar Owen <lowen () pari edu> wrote:
>
> On 05/15/2016 01:05 PM, Eric S. Raymond wrote:
> > I'm not used to thinking of IT as a relatively low-challenge environment! 
>
> I actually changed careers from broadcast engineering to IT to lower my stress level and 'personal bandwidth 
> challenge.'  And, yes, it worked.  In my case, I'm doing IT for radio and optical astronomy, and at least the timing 
> aspect is higher-challenge that most IT environments.
>
> > You're implicitly suggesting there might be a technical case for replacing these T1/T3 trunks with some kind of VOIP 
> > provisioning less dependent on accurate time synch. Do you think that's true? 
>
> While I know the question was directed at Mel specifically, I'll just say from the point of view of a T1 voice trunk 
> customer that I hope to never see it go to a VoIP solution.  VoIP codecs can have some serious latency issues; I 
> already notice the round-trip delay if I try to carry on a conversation between our internal VoIP system and someone 
> on a cell phone.  And this is before codec artifacting (and cascaded codec scrambling) is counted.  Can we please 
> keep straight μ-law (A-law if relevant) lossless DS0 PCM timeslices for trunklines so we get at least one less lossy 
> codec cascade?  Or have you never experimented with what happens when you cascade G.722 with G.729 with G.726 and 
> then G.711 and back?  Calls become mangled gibberish.
>
> I would find it interesting to see how many carriers are still doing large amounts of SONET, as that is the biggest 
> use-case for high-stability timing.