[Home]

Summary:ASTERISK-12176: [patch] Chanspy audio is delayed or lost
Reporter:Paul Mathews (pmathews)Labels:
Date Opened:2008-06-11 16:49:53Date Closed:2011-06-07 14:03:05
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_chanspy
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 12837.patch
( 1) adhoc.wav
( 2) adhoc-oos.wav
Description:If extension (A) is being monitored via chanspy on extension (C) and (A) places a call (B) on hold, the audio from the other side of the call (B) is either delayed or lost to station (C) when the extension being monitored (A) returns from placing a call on hold. This does not happen if extension (C) is monitoring extension (B) and extension (A) places extension (B) on hold.

****** ADDITIONAL INFORMATION ******

This occurred upon upgrading to 1.4.20.1 from 1.4.19.1 (with the 12296.diff file at http://bugs.digium.com/view.php?id=12296)
Comments:By: Paul Mathews (pmathews) 2008-06-13 14:51:54

I have attached two recordings from a ChanSpy operation, one showing no audio after hold; the other is an example of the audio being out of sync after hold.
By: mitchbcn (mitchbcn) 2008-06-16 08:27:11

I can confirm it in 1.4.19.1.
By: Paul Mathews (pmathews) 2008-06-16 12:53:38

Just to clarify, we also had this problem in 1.4.19.1, but the 12296.diff patch (see http://bugs.digium.com/view.php?id=12296 ) resolved the problem. It looks like some of the code from that patch has been applied in 1.4.20.1, but the problem is still present.


By: Martin Vit (festr) 2008-06-26 05:39:23

I've looked at the patch from 12296 and source of the 1.4.20.1. Maybe the problem is that in 1.4.20.1 there is test in audiohook:

ast_test_flag(audiohook, AST_AUDIOHOOK_TRIGGER_SYNC)

and AST_AUDIOHOOK_TRIGGER_SYNC is set only in apps/app_mixmonitor.c (in function launch_monitor_thread)

So maybe this FLAG should be also set somewhere in apps/app_chanspy.c?

I've problem with out of sync chanspy on rev SVN-branch-1.4-r114299 (mixmonitor is OK)


By: Eduardo Gomes Santos (edugs15) 2008-06-27 12:21:12

I can confirm this bug in Asterisk 1.4.21 as well.

Mixmonitor is ok, but chanspy Audio is delayed, no matter extension being monitored places a call on hold or not.


Thanks.
By: Eduardo Gomes Santos (edugs15) 2008-07-04 08:50:34

Hello,

has this issue been fixed by someone ?



Thanks
By: Martin Vit (festr) 2008-07-12 05:51:46

Look at main/audiogook.c "$Revision: 130236 $" at function ast_audiohook_write_frame (line 132)

there is assign

       struct timeval *time = (direction == AST_AUDIOHOOK_DIRECTION_READ ? &audiohook->read_time : &audiohook->write_time), previous_time = *time;

followed immediately by "*time = ast_tvnow();"

this mean, that previous_time could be different than the actual time. Is this ok?
By: Mark Michelson (mmichelson) 2008-07-14 16:24:44

I've been looking into audiohook code based on issue 13005. I can address some of the concerns raised here.

1. I'm not sure if the AST_AUDIOHOOK_TRIGGER_SYNC flag is necessary for chanspy.

2. The fact that the "time" and "previous_time" variables are different is intentional. If you look below, you'll see that there is a call to ast_tvdiff that uses those two values.

What makes this and other audiohook-related problems difficult to fix is that I never can seem to reproduce the problem locally, so I can't be sure if the patch I'm writing will necessarily fix the issue.

Here's what I suggest. Look at issue ASTERISK-12324. Patch your source with 13005.patch. That was a fix for a typo that was in audiohook.c. If that helps, then let me know. If it doesn't, then I will work on making a trigger-related audiohook patch for chanspy.
By: Paul Mathews (pmathews) 2008-07-15 10:26:59

I have applied both the 13005.patch and 13005_try2.patch to one of my lesser used production systems (1.4.20.1) and it seems to fix the problem, and not cause any problems of it's own. I'll monitor it throughout the day, and if there are no problems, I'll also apply it on my main box tonight and report results.
By: Mark Michelson (mmichelson) 2008-07-15 10:28:54

Excellent! While the 13005_try2.patch won't have adverse effects, it's really a mixmonitor-specific patch and so I wouldn't expect it to have much bearing on chanspy operation.
By: Eduard M. (callmewind) 2008-07-17 11:54:49

Hi! I have the same problem in 1.4.20.1. I've tried with the 13005 patches but spying is still out of sync when spying for more than 30 seconds. Mixmonitor recordings are ok.
By: Eduardo Gomes Santos (edugs15) 2008-07-17 12:51:44

I have applied both patches 13005.patch and 13005_try2.patch , for Asterisk 1.4.21, but didn't fix this issue.

For example :

- An agent makes an outgoing call. Using Chanspy to listen in on this call, Agent's audio is ok, but audio from customer called is delayed, about 3 seconds.


This makes impossible to listen in the call, because it's out of sync.
By: Mark Michelson (mmichelson) 2008-07-17 13:28:00

Okay, I'm going to work on a patch for chanspy which incorporates a sync trigger as well as changing the sync-triggering logic in audiohooks. I will be making this patch against 1.4.21.1 without any modifications.
By: Paul Mathews (pmathews) 2008-07-17 13:50:59

This is working for us. The 13005 and 13005_try2 patches have been applied to our core machine, and ChanSpy works without issue - however, customer audio (ZAP -> SIP) previous to this patch was in sync with occasional sporadic sync problems - the one thing that would either delay the audio, or lose it completely 100% of the time was if the agent placed the customer on hold while the agent's phone was being ChanSpy'd (SIP -> SIP). Disconnecting/reconecting via ChanSpy would resolve the sync problem, and the mixmonitor recordings never had any corruption or sync problems (unless it was a mixmonitor of the ChanSpy operation). This happened on 1.4.20.1 (unpatched), but the 13005 and 13005_try2 patches recommended resolve the sync problems in ChanSpy.


By: Eduardo Gomes Santos (edugs15) 2008-07-17 14:08:16

In my production server, the problem always occurs, no matter place customer on hold, or not.

Mixmonitor is ok.
By: Eduardo Gomes Santos (edugs15) 2008-07-29 15:04:06

Hello putnopvut,

could you please inform if you have managed to work on a patch for this issue ?

If you did, I can test it in my system, where this problem is always happening.

Thanks.
By: Mark Michelson (mmichelson) 2008-07-29 15:10:01

Sorry, I've been working on other things. I will set aside time tomorrow to work more on this and the MixMonitor speed-up issues. Thanks for the prod.
By: Eduardo Gomes Santos (edugs15) 2008-07-30 09:09:39

ok,

Thanks.
By: Eduardo Gomes Santos (edugs15) 2008-08-01 08:41:36

Hello putnopvut,

just to add information about this issue :

An agent starts listening in on a call, and audio is out of sync.

Although, sometimes disconnecting and reconecting via ChanSpy, resolves the sync problem, and audio is ok.

From this moment on, if this agent keeps listening in the same agent that it was, audio is always ok.

If the agent starts listening in on a call from another agent, then sync problems occurs again.


Thanks.
By: Mark Michelson (mmichelson) 2008-08-01 09:08:24

Thanks for the information, edugs15. I looked at this some more yesterday, but still didn't make any progress. I'll try to get some work done on this today, too, but my recent IMAP work has been eating up more time than I had originally thought.
By: Eduardo Gomes Santos (edugs15) 2008-08-01 09:12:50

ok,

Thanks.
By: Mark Michelson (mmichelson) 2008-08-01 13:15:03

I have uploaded a patch made against the 1.4.21.2 tag of Asterisk which adds a sync trigger to chanspy. This won't actually have any "triggering" affect, but it will hopefully cause the two audio streams to be in sync properly. Please test this out.
By: Martin Vit (festr) 2008-08-01 13:31:14

Isn't this patch in contrast with http://bugs.digium.com/view.php?id=13005 => file http://bugs.digium.com/file_download.php?file_id=19508&type=bug?  

I'm seeing both problems. Spying is out of sync and mixmonitor is recording fast and bad quality audio.
By: Eduardo Gomes Santos (edugs15) 2008-08-01 13:54:26

Hello putnopvut,

I will test it, and report results.

Thanks.
By: Mark Michelson (mmichelson) 2008-08-01 14:19:40

festr, it's not really in contrast, it's a patch for a different problem. This patch focuses just on the chanspy problem. The typo in audiohooks.c definitely needs fixing, and I decided to try adding a sync trigger for chanspy, as well. The other trigger modification patch in ASTERISK-12324 (called 13005try2.patch) are not necessary for chanspy operation because there is no actual "triggering" going on in chanspy.
By: Eduardo Gomes Santos (edugs15) 2008-08-02 07:02:34

Hello putnopvut,

bellow follow test's results :

The two audio streams are in sync properly now, but there is a new problem, and I describe an example bellow :

- An agent makes an outgoing call. Using Chanspy to listen in on this call, Agent's audio is ok, but audio from customer called fails, with many words being cutted in half. For many words said, we can just listen half the word.
By: Eduardo Gomes Santos (edugs15) 2008-08-04 12:14:43

Hello putnopvut,

just to add information :

The problem I have reported always occurs, no matter in outgoing or incoming calls.

Audio streams are in sync, but audio is sometimes cutted.


Thanks.
By: Eduardo Gomes Santos (edugs15) 2008-08-07 11:41:10

putnopvut :

I'd like to know, if you allow me to, if you will be working on this issue again this week, or just next week.

I could downgrade, from Asterisk 1.4.21.1 to 1.4.17, in order to resolve chanspy issue, but in Asterisk 1.4.17 we have an issue related to slinfactory.c, that happens when recording calls via Mixmonitor.

So there is nothing I can do by now.


Thanks.
By: Mark Michelson (mmichelson) 2008-08-07 12:17:03

Well, today I have other matters I need to get to first. If there is time, I can look more.

Just as an FYI, blitzrage had a customer who was experiencing this issue. I was able to look at that person's dialplan and settings and replicate them on my test box. At first, I was baffled because I could not reproduce the issue. I tried using a checkout of the 1.4.21.1 tag and all of a sudden, the delay was there and it was horrible, especially if the spied-upon channel put the other caller on hold (like the issue describes). When I moved up to an svn checkout of the 1.4 branch, the issue didn't happen.

This could mean that the issue has been fixed in 1.4 by this point, but I'd rather hear confirmation from those who have been experiencing this issue first.
1.4.22-rc1 will be released *very* soon, so when it is, you may wish to upgrade to that to see if the problem is still there.

If the issue still is present, it will be a while before I can work on it again because I am on vacation next week (Aug 11-15). If this issue still isn't resolved before then, I will try to get another developer to take a look at this to see if maybe another set of eyes can see something I have been missing.
By: Eduardo Gomes Santos (edugs15) 2008-08-07 12:46:17

ok,

I appreciate attention from you.

I will try 1.4.22-rc1, when it's released, and report results.

Thanks
By: Leif Madsen (lmadsen) 2008-08-07 17:13:17

Also as an FYI, the customer in question found the 13005.patch file in bug 13005 to have resolved the issue on his test box. We have just installed the patch to the production server and should hear back tomorrow whether the issue is resolved for him.

If you would like to try the 13005.patch against your 1.4.21.1 Asterisk (as I have done with this client), then you can perform the following:

* Obtain patch and put into your Asterisk source directory (I used lynx to obtain the patch from the 13005 bug)
* Copy existing 1.4.21.1 directory to another location so you can easily revert if necessary:  # cp -r /usr/src/asterisk-1.4.21.1 /usr/src/asterisk-1.4.21.1-with-13005-patch
* Patch Asterisk: # cd /usr/src/asterisk-1.4.21.1-with-13005-patch ; patch -p0 < 13005.patch
* Install: # make install
* Test and report results!

Happy testing!
Leif.
By: Eduardo Gomes Santos (edugs15) 2008-08-11 07:51:35

blitzrage :

Thanks for your instructions.

I will follow your instructions and report results tomorrow.
By: Eduardo Gomes Santos (edugs15) 2008-08-13 09:34:38

Hello blitzrage  :

Patch 13005 against 1.4.21.1 didn't fix this issue for me.

I will try an svn checkout of 1.4 branch, and report results.


Thanks.
By: Leif Madsen (lmadsen) 2008-08-13 15:18:00

OK, thanks for the update edugs15. Let me know how it goes!
By: c0rnoTa (c0rnota) 2008-09-13 13:34:56

I'v tried this patch on my debian x86 asterisk 1.4.21.1, but there is no results: while listening talking peoples via chanspy application, one of audio flows is slow. Connected channels are SIP. So, guys, the main question still warring me: why some of servers are affected by this issue (and "mixmonitor out of sync" issue), and some of them healthy? i'v tried several kernels on different linux systems, but delaying problems does not go away.

Sorry for my English again ;)
By: Leif Madsen (lmadsen) 2008-11-20 16:20:09.000-0600

Dropping the status on this down to Confirmed as it appears the patch provided here does not solve the issue unfortunately.
By: Mark Michelson (mmichelson) 2008-11-26 14:35:32.000-0600

I'm beginning to think that this issue may have been fixed by now.

I started a test on the current tip of 1.4 exactly as described in the summary of this report. When I placed B on hold, the spy could hear what B was saying even when B was on hold. When A took B off hold, audio from both sides were heard properly and in sync.

I then ran the same test on 1.4.21.1, which was a release said to have this problem. The difference here was that when B was placed on hold, the spy could not hear anything B said. When A took B off hold, everything B said while he was on hold was then played back for the spy. This meant that there was a horrible desyncing of the audio.

I then ran the same test on 1.4.22 and it performed the same as the tip of 1.4.

I can't point to any specific revision which fixed this, but I would like it if someone can confirm that this is still a problem in 1.4.22
By: Leif Madsen (lmadsen) 2008-11-26 20:50:15.000-0600

Changing status to feedback since, well, putnopvut wants some feedback! :)
By: Leif Madsen (lmadsen) 2009-01-15 16:50:30.000-0600

Suspended due to lack of activity. Please request a bug marshall on #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional issue requested. Thanks!
By: Leif Madsen (lmadsen) 2009-03-24 11:43:26

Reopened at the request of rene- on IRC.
By: Rene Mendoza (renemendoza) 2009-03-24 11:51:34

Hello. This is happening to me on 1.6.0.3, outbound calls from sip extension to sip trunk, without putting any party ever on hold, delay while using chanspy is present and eventually will grow to a point where conversation can not be followed, i see that even patch 13005.tolerance fixed the problem of out of sync recordings it does not do anything to help in case of out of sync chan spy. i see that code from patch 13005 is present in the sources for 1.6.0.3  my sip calls are cristal clear but monitoring is just not usable as it is
By: Rene Mendoza (renemendoza) 2009-03-24 13:36:13

also, 1.6.0.3  includes this patch http://bugs.digium.com/file_download.php?file_id=19468&type=bug that some people here claim it would mitigate the problem. that code is also present in patch http://bugs.digium.com/file_download.php?file_id=19747&type=bug but this patch also adds a line currently not present in either 1.6.0.3 or 1.6.0.6, specifically this line in app_chanspy.c ast_set_flag(&csth.spy_audiohook, AST_AUDIOHOOK_TRIGGER_SYNC);
i will add it and compile to see if it helps
By: Rene Mendoza (renemendoza) 2009-03-24 13:37:35

by the way i am not using mix monitor here
By: David Vossel (dvossel) 2009-03-25 11:40:27

The original report was for audio becoming out of sync as result of putting a channel on hold.  After reading through the long list of notes associated with this bug it appears that this was a problem and it was very specific to using hold.  Apparently this was resolved by updating to the latest 1.4 branch code.

The new issue noted that does not involve putting someone on hold should be opened in a new bug report as it is separate from the initial report.