FOP2 produces no audio when listening in on calls.

[nbains]

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

[nicolas]

Fop2 just starts the chanspy application, once your phone rings and starts chanspy, it is up to asterisk to pass audio or not.

What you might want to check is if the command launched from fop2 is correct (matching channel names for chanspy), you can start fop2 in debug level 3 to find out

cd /usr/local/fop2
service fop2 stop
script capture.log
./fop2_server -X 3
(do your spy test)
ctrl-C
exit

Then check your capture.log file and search for "spy" to see the command being sent to asterisk.

[nbains]

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

[nbains]

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.

[nicolas]

Hi Neil,

FOP2 uses the device that is attached to the abstraction "user" as the channel to listen for, if you have serveral devices attached to an extension you will have problems. Chanspy does not listen to users, that abstraction is made up by the freepbx user&device mode. Chanspy can listen to devices. Anyways, try to catch me on the live help again and we can make some tests.

Best regards,

[nicolas]

For posterity and other users, I was working yesterday on this user server and we were able to fix the problem of spying/whispering on user&device mode for users with one or more devices attached to their extension.

If tests todays shows that the patch is stable, I will introduce this fix on FOP version 2.25.

This fixes spy/whisper on device and user mode in FreePPBX, normal extensions mode was always working fine.

[londony]

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!

[nicolas]

It is kind of complex, you have to query the astdb to find the device based on the extension number, I do not recall exactly but it was a two step process, involving consulting AMPUSER/{$EXTENSION}/device and then DEVICE/{PREVIOUSRESULT}/dial. The user&device mode in FreePBX is complex/convoluted in itself.

[londony]

Thanx. Even that was already very helpful!