Summary:ASTERISK-22661: Unable to exit ChanSpy if spied channel does not have a call in progress
Reporter:Chris Hillman (chillman)Labels:
Date Opened:2013-10-04 16:04:51Date Closed:2014-02-21 09:41:18.000-0600
Versions: Frequency of
Environment:Running Asterisk Version = on CentOS release 6.4 Kernel 2.6.32-358.6.2.el6.i686 - 32 Bit Attachments:( 0) asterisk-22661-doc-clarify-chan_spy.diff
( 1) debug_output.txt
( 2) dialplan_example.txt
( 3) issue_22661_full_log
Description:I have a context in the dialplan where I want to be able to ChanSpy on SIP/361-SIP/364, and use the 'x' option to exit the ChanSpy application and select a new Channel to spy on. If the Channel I'm spying on is not in a call I can not exit the ChanSpy application.

I have attached my dialplan code as well as console verbose output and SIP debug info.

Option I'm trying to use:

   digit - Specify a DTMF digit that can be used to exit the application.

The digit will not be recognized if the spied party is not in a call at the time.
Comments:By: Chris Hillman (chillman) 2013-10-04 16:05:40.998-0500

My dialplan code that will reproduce issue.

By: Chris Hillman (chillman) 2013-10-04 16:06:03.126-0500

Console debug output.

By: Michael L. Young (elguero) 2013-10-08 16:15:16.915-0500

Thanks for the debug log and dialplan example... can you attach a full debug?  https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

That would be helpful.


By: Chris Hillman (chillman) 2013-10-08 17:07:25.003-0500

Dialed chanspy from ext 360 to monitor 361. Collected debugging info.

By: Michael L. Young (elguero) 2013-10-11 12:00:40.108-0500

Chris, have you tried using a different DTMF digit?  I have a suspicion that since you are only overriding the default DTMF for exiting, that the default value for cycling is causing this to be ignored.  The default value for cycling between channels is "#".

Can you test a different value, like 6, just for testing?  If that helps to prove my theory, then I think we could do something to warn the user that they are selecting a duplicated DTMF option or not allow a DTMF digit to be duplicated for the cycle, volume and exit DTMF options.

By: Michael L. Young (elguero) 2013-10-11 12:03:07.138-0500

Oh and... I just re-read the description above and now I have another question.

I have a context in the dialplan where I want to be able to ChanSpy on SIP/361-SIP/364, and use the 'x' option to exit the ChanSpy application and select a new Channel to spy on. If the Channel I'm spying on is not in a call I can not exit the ChanSpy application.

Are you just trying to cycle between channels?  If you are just trying to cycle, there is no need to exit.  Just use the default setting of "#" to cycle between channels.

By: Chris Hillman (chillman) 2013-10-11 12:13:03.731-0500

Thank you Michael, I have tried it with numeric DTMF digits and the behavior is the same. Just tested with x(6). We need to be able to specify an extension to observe. In production this will be spanning about 260 extensions and cycling between all of them will be unpractical.

By: Michael L. Young (elguero) 2013-10-23 13:29:10.102-0500


I just played around with this and it seems that you might want to use the "S" option OR the "X" option.

What is happening is that when you dial in and the sip device that you choose to spy on is not on a call, we never enter into the part of the code that handles spying on a channel and responding to DTMF commands.  That part of the code is what responds to the DTMF digit set for exiting.  Since, you never enter that part of the code, the # DTMF is being received by Asterisk but nothing is being done because there is nothing is running to react to that digit.

With the "S" option in place, if the channel you are trying to spy on is not active, it will immediately kick you out and then your StartMenu label is used, asking for an extension again.


With the "X" option, you can add to the context "[custom-myspy]" the extension "exten => #,1,Goto(456,StartMenu)". That also seems to produce the desired results.

Otherwise, I am not sure if there is a bug here... this is one of those areas where a workaround is available and the code seems to be working as it was intended.  Could it be improved upon?  Probably.  But for now, this configuration change seems to be the way to resolve your issue.

By: Chris Hillman (chillman) 2013-10-29 11:15:26.141-0500

Thanks Michael, the X option makes a good workaround for my purpose. I'd still consider it a bug since the x feature doesn't behave as documented, but I'm glad I can work around it. Cheers!

By: Michael L. Young (elguero) 2013-10-29 23:23:54.845-0500

Chris, thanks for the feedback.

I think that maybe clarifying the documentation will help for future users looking at this option.

By: Matt Jordan (mjordan) 2013-10-30 08:27:00.051-0500

My 2 cents:

You could probably view this as a bug or as a documentation improvement. Since this is a relatively rarely used feature and there is a valid workaround available, I'd prefer to just update the documentation for the {{x}} option that the DTMF is only accepted while spying is actually taking place.

By: Michael L. Young (elguero) 2013-10-30 09:16:57.968-0500

Matt, thanks for chiming in.  I was going to ask for some thoughts later and you beat me to it.

Yes, in looking at the code, I would prefer the documentation change as well since according to the code, it looks like that was not the intention while the documentation clearly leads one to believe otherwise.

I will post the patch to update the documentation that I have here on the issue tracker up on review board and work on getting it in.