[asterisk-users] strategy for measuring conference audio delay

[Steve Edwards]

On Wed, 17 Sep 2008, George Williams wrote:

> I have need to measure the end-to-end audio delay in the MeetMe conference
> application.
>
> Currently, I have written a python program that connects to an Asterisk
> MeetMe conference via SIP, and pumps RTP packets into the conference.
>
> Another instance of the program dials into the same conference and receives
> the mixed RTP stream.
>
> I figure I can have both python programs running on the same machine -
> essentially creating an echo test setup.  Then, all I have to do is measure
> the time delay between when I send the audio stream to when I receive it.
>
> I think I'm being a bonehead, but the trick appears to be in what kind of
> RTP packets to generate and how to analyze the mixed audio stream coming
> back from Asterisk.  Preferably, I would send one RTP packet that gets mixed
> in a predictable way and then I can look for it in the receive stream.
>
> Anyone have any suggestions on how I can do this, given my setup?

I did this using a pair of RadioShack Telephone Recording Controls. Each 
was connected to a separate handset and then to the "left" or "right" 
connector of a "mono to stereo" adapter. The adapter was plugged into the 
"line-in" of a laptop running Audacity. When I tapped one handset on the 
table, you could see and measure when the "tap" was received on the second 
handset.

While not using your setup, it was simple to set up and nobody questioned 
the results -- settling a very expensive lawsuit.

I would question whether your methodology will accurately measure your 
end-to-end delay. Are your endpoints connected via TDM interfaces or 
Ethernet? Ethernet will introduce xx ms of delay as will whatever is 
converting between analog and digital.

In my limited understanding, converting from analog to digital will take a 
bit more than 20ms, putting the frame on the wire takes about 5ms, getting 
the frame off the wire takes about 5ms and converting the frame back to 
analog takes a bit more than 20ms. I have no empirical evidence to support 
this so I welcome corrections from those that do.

Thanks in advance,
------------------------------------------------------------------------
Steve Edwards      sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                             Fax: +1-760-731-3000