[asterisk-bugs] [Asterisk 0013745]: Recordings out of sync when using chanspy

Thu Mar 26 17:55:31 CDT 2009

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13745 
====================================================================== 
Reported By:                geoffs
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   13745
Category:                   Applications/app_mixmonitor
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-10-20 09:31 CDT
Last Modified:              2009-03-26 17:55 CDT
====================================================================== 
Summary:                    Recordings out of sync when using chanspy
Description: 
Inbound and outbound tracks will get out of sync by several seconds when a
call is monitored using chanspy.  
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012837 [patch] Chanspy audio is delayed or lost
related to          0011945 MixMonitor - Out Of Sync Audio With Zap...
====================================================================== 

---------------------------------------------------------------------- 
 (0102276) mmichelson (administrator) - 2009-03-26 17:55
 http://bugs.digium.com/view.php?id=13745#c102276 
---------------------------------------------------------------------- 
I'm starting to get a bit confused about what the actual issue is here. It
seems that earlier we were talking about files saved by mixmonitor having
out-of-sync audio, but now the discussion seems to be centered on the spy
himself hearing out-of-sync audio when listening to a conversation. I think
this confusion is what has led to this issue being open for so long.

I've probably spent two hours today trying to make the conversation seem
out-of-sync to the spy, and it just hasn't happened. I'm trying to find
what factor could be causing this issue. The latest notes added on issue
http://bugs.digium.com/view.php?id=12837 (which has been closed again) indicate
that this problem can be
experienced using nothing but SIP devices, and this report mentions the use
of Zaptel and libPRI, so I don't think the channel type has a bearing on
this issue. Furthermore, I've tried reproducing this with internal timing
enabled and disabled and that didn't change the outcome. I've also tried
using the various bridging methods (generic, packet2packet, and native) and
that didn't make a difference.

I've been thinking of the other factors that may contribute to the
problem. Here's a list things I have thought of.

1. Packetization of audio at each endpoint.
2. Which party is being spied on.
3. Whether Local channels (especially ones with /n) are in use.

The problem with (1) is that it takes a huge amount of testing since there
are so many codecs supported and packetization can vary widely on any codec
which is not frame-based. As far as (2) goes, I really don't think it
should make a difference, but I have listed it anyway. Plus I highly doubt
that a call-center environment would be set up to try to spy on the caller,
but I thought I'd list this just in case. (3) is something that I came up
with, but I can't actually tell if it would really be a problem or not. I
see from the provided extensions.conf file here that Local//n channels are
in use, so I may need to revisit this idea.

As far as (1) goes, for anyone experiencing this problem, what codecs are
in use on the calls, and if packetization is explicitly set to a certain
value, what is it? I'm going to test out number (3) now, but after that I
think I'm calling it quits for the day, or at least until I can think of
something else which may be causing this to happen. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-26 17:55 mmichelson     Note Added: 0102276                          
======================================================================