Hi Everyone,

I've come across a new issue. The listening in on the extensions works for about 85% of the extensions in my organization. There's very odd behavior occurring, where if I try to listen in on about three extensions, there is no audio coming back to my phone of the call I'm listening in to, it's just dead air.

This happens on the same three extensions every day, but basically about all the other extensions seem to work fine. I've checked / compared configuration on these affected extensions, and cannot find anything different. These three extensions are located locally here in the office, so a ping / speed issue should not be the case, but I guess that is always possible.

A restart of FOP2 plus comparing settings on an extension that does work in accordance to an extension that doesn't work did not help.

Any ideas?

Any help would be appreciated, thanks!

- Neil

Hi,

Thanks for this suggestion.

I tried this by running FOP2 in Run Level 3 on one of my extensions that is affected, and did a search for 'spy' and did not find anything in the capture.log file.

To me, it looks like that Chanspy is not even getting initiated, as I see nothing regarding to 'spy'.

However, I did try listening in on a call on my extensions that I know works, and this is what I got the capture.log:

127.0.0.1       -> Action: Originate
127.0.0.1       -> Channel: SIP/2709
127.0.0.1       -> CallerID: 2709
127.0.0.1       -> Application: ChanSpy
127.0.0.1       -> Data: SIP/2722,bq
127.0.0.1       -> ActionID: fop2spy!SIP/2722
127.0.0.1       -> Async: True

127.0.0.1       <- Response: Success
127.0.0.1       <- ActionID: fop2spy!SIP/2722
127.0.0.1       <- Message: Originate successfully queued
127.0.0.1       <- Server: 0

127.0.0.1       <- Event: RTPReceiverStat
127.0.0.1       <- Privilege: reporting,all
127.0.0.1       <- SSRC: 0
127.0.0.1       <- ReceivedPackets: 0
127.0.0.1       <- LostPackets: 0
127.0.0.1       <- Jitter: 0.0000
127.0.0.1       <- Transit: 0.0000
127.0.0.1       <- RRCount: 0
127.0.0.1       <- Server: 0

So there is definitely a log there for when the call monitoring worked.

My guess is that Chanspy is not being initiated. I read on a couple forums that Chanspy + call recording on extensions can be an issue, but then I realized that even listening on calls that have 'call recording' enabled, work so that can't be the problem?

Any other ideas? Greatly appreciated, thanks!

Neil

Hi,

Thanks for that suggestion.

I tried this, and actually noticed something funny. When trying to listen on some of the calls, the listen in signal was being sent to different SIP extensions, like so below:

> Channel SIP/2709-0000925d was answered.
> Launching ChanSpy(SIP/609,bq) on SIP/2709-0000925d

Asterisk is saying that it is listening on channel '609', when in fact in FOP2, I listened to an extension of '2702' which is totally different. I looked at my FreePBX config, and turns out, the 609 extension is a device that is attached the 2702 user in FREEPBX.

609 is a softphone app extension that I have attached to the 2702 user, so anytime the 2702 extension rings, the 609 does as well on the users BRIA softphone app. Anyways, it looks like FOP2 is sending the listen signal to the BRIA app vs the actual phone extension.

I am going to take off all the 60x devices I have created for the affected extensions, reload FreePBX + FOP2, and check the logs again, I will keep you posted..

Thanks again!

Neil.

I have added in my dialplan the following in order to spy on channels with a code:
exten => _*222x.#,1,Authenticate(1234)
exten => _*222x.#,1,Macro(user-callerid,)
exten => _*222x.#,n,Answer
exten => _*222x.#,n,NoCDR
exten => _*222x.#,n,Wait(1)
exten => _*222x.#,n,ChanSpy(sip/${EXTEN:4},q)
exten => _*222x.#,n,Hangup

would it be very complicated to fix it so it will work like fop2 and find the correct channel in user&device mode?
Thank you!

Thanx. Even that was already very helpful!