[time-nuts] an interesting timing problem

[Steven Sommars]

This discussion focuses on interactive audio/data streams.  One-way streams
are treated differently, since delay is less important.

Media transport typically uses IPv4/6 networks and can often be captured at
one of the endpoints or somewhere in the network path. E.g., I captured a
Skype call today on my PC using Wireshark.  Whether this IP capture can be
converted back to audio/video depends on whether the packets have been
encrypted and requires detailed knowledge of the encoding used.  It is
common to digitize audio using a standard vocoder (for wireless, these
include EVRC, AMR, AMR-WB) and then transport it using RTP headers and
UDP/IP.   I'll describe 4G voice (voice over LTE or VoLTE), as I'm most
familiar with that technology.

There are several delay contributors in the end-to-end path:

   - (source) Collecting digitized voice for an interval.  In 2G/3G/4G
   wireless 20 msec is commonly used.
   - (source) Compressing the 20 msec of data .   This data is stuffed into
   an RTP/UDP/IP packet
   - IP transport of the compressed voice to the receiver.   This is
   unreliable: RTP packets can be dropped, duplicated, missequenced or
   corrupted.
   - (Receiver) Dejitter buffer (or jitter compensation buffer ...)
   - (Receiver) Error concealment

The dejitter buffer adds variable delay dependent on the network and
network conditions.   I've seen it add 10's to 100's msec delay in VoLTE.

One-way latency is sometimes called "mouth to ear delay" and can be
measured in the analog domain with commercial gear; we used equipment from
GL Communications.
Time-stamped IP packet captures can also be helpful, but doesn't show what
happens within the receiver.








On Wed, May 6, 2020 at 2:44 PM jimlux <jimlux at earthlink.net> wrote:

> On 5/6/20 7:33 AM, Chris Howard wrote:
> >
> > At my current job we were looking into delay timings of video systems.
> >
> > We were doing end-to-end measurement by putting a time display in front
> > of a monitor
> > and have the camera show both the time display and the monitor.
> > It looks a bit like the old infinite mirror.
> > If you arrange things right it shows two images of the time display
> > one that lags the other.  And the difference is the round-trip delay.
> >
> > When I'm on Skype and my co-worker shares his screen, I can see my own
> > camera image come back to me in a similar way.
> >
> > So if I were to point my camera at a rolling time display, he shares
> > that image back to me, I could take video (with a second camera)
> > of both the live time display and the delayed.
> >
> >
>
> OK, but this is sort of a manual measurement.
> Ditto for looping back a tone and using an oscilloscope.
>
> What I was wondering about whether there's a way to do it in an
> automated way - fire up N webex/zoom/skype "conferences" solely for the
> purpose of testing.
> For instance, this morning was a "very bad day" for Cisco's webex, and
> it would be interesting to collect performance statistics over time.
>
> And to explore the nature of the anomalies - are they "packet drops",
> "resends", random delays, etc.
>
> Much like the folks did in the early days of NTP development.
>
>
>
> Some others had suggested ways of doing it "during a call" which is
> interesting.  I wonder if there is a way to intercept the video and
> audio traffic within the OS and "tee" it off to a analyzer.
>
> Last time I looked at doing that kind of thing, I was foiled at every
> turn with Windows, because of their sensitivity to digital rights
> management - you don't want someone "tee"-ing copyrighted material to
> storage and redistributing.  I would expect that Mac OS X is no
> different.  It may well be that the conferencing applications don't
> bother to use the "protected content" capability. I know that folks at
> work have found ways to chromakey their webcam feed before feeding it
> into the Webex video input.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>