George Williams
2008-Sep-17 23:49 UTC
[asterisk-users] strategy for measuring conference audio delay
Hi, 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? Thanx! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080917/afca0518/attachment.htm
Steve Edwards
2008-Sep-18 00:22 UTC
[asterisk-users] strategy for measuring conference audio delay
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