Summary:	ASTERISK-04412: Monitor of two bridged Zap channels only records -in audio stream
Reporter:	Matt Florell (mflorell)	Labels:
Date Opened:	2005-06-14 13:24:28	Date Closed:	2011-06-07 14:02:50
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I had not used Monitor on two bridged Zap channels in about a year, then we had a need to do it again only to find that it did not work in Stable releases(1.0.X) or CVS_HEAD. Here's the example: 1. User dials into Zap/1-1 2. Asterisk then dials out aonther number over Zap/25-1 3. Through the manager interface user sends Monitor command for Zap/1-1 4. only the -in file is capturing audio data, the -out file remains at 44 bytes if you Monitor the other Zap channel(Zap/25-1) you get only the other side of the converstion (the -in stream) Here's the Manager command used: Action: Monitor Channel: Zap/1-1 Filename: INCOMINGLINE-01-1 Looking at the /var/log/asterisk/messages file it looks like Asterisk is sending both Zap channels to a conference to bridge them. This makes sense because this is the same behaviour exibited in Monitor if you try to send the Monitor command to a Zap channel in a meetme conference(it only records the -in stream). Zap to SIP and Zap to IAX conversations do not seem to be affected. When did this change occur? Is there another simple way to record both sides of a Zap to Zap conversation on the fly? We have reproduced this bug on 3 separate Asterisk servers all with Digium TE405P quad T1 cards running CVS_HEAD and releases 1.0.6 and 1.0.7. I apologize if this bug is not supposed to be major, but it is a function that used to work(I last used it on CVS-HEAD-07/28/04) and now does not work and it has no workaround.
Comments:	By: Brian West (bkw918) 2005-06-15 00:59:21 turn off the jitter buffer! By: Matt Florell (mflorell) 2005-06-15 07:13:06 I'll try setting jitterbuffer=no later today, but why would a jitterbuffer on zapata not allow recording of the other side of the conversation? Especially when you can have a jitterbuffer active on IAX channels yet there is no problem with recording on them. This would still be a bug even if turning off jitterbuffer works. Also, I've seen very little documentation on jitterbuffer in zapata.conf anywhere except that it seems to have been added in April and it is on by default set to 4. I'll post after I try turning off jitterbuffer. By: Matt Florell (mflorell) 2005-06-15 09:13:44 Set jitterbuffer=no on all trunks within zapata.conf, restarted everything and still no audio on the -out stream. Is there anything else that could be causing this? By: Mark Spencer (markster) 2005-06-18 19:54:54 try adding 't' to avoid native transfers. By: Matt Florell (mflorell) 2005-06-19 11:21:44 That worked, I added 't' to the dialstring and now the -out stream is recording. But why is this? the 't' flag is documented everywhere as being the ability for the called user to transfer the call, and I definitely don't want that, that's why I never use that flag. Is there any way to separate the functionality of native transfers from the called party transfer option since this seems to be the only way to record both sides of a bridged 2-party Zap to Zap call? By: Kevin P. Fleming (kpfleming) 2005-06-21 15:29:20 The core issue here is that starting Monitor() on a pair of bridged channels will not 'pull back' the channels from any sort of native bridge they may be involved in (Zap, IAX or SIP). Adding 't' (or 'T') to the dial string tells Asterisk to not allow the channels to be native bridged, since it has to listen for DTMF. It would be possible to add a Dial parameter that _only_ disabled native bridging but did not turn on any other features, if that is what is needed. Since you are running CVS HEAD, you may also be able to use app_chanspy to do what you need, because it knows how to break the native bridge between the channels when needed. By: Kevin P. Fleming (kpfleming) 2005-07-05 21:39:33 Closing due to lack of activity... since there is a reasonable workaround, we'll leave it this way for now. It would be good at some point in the future if invoking Monitor asynchronously would 'unbridge' a native bridge, but that will take some work to accomplish properly.