Hi Nicolas,

Could it just be that the ODBC session is stale and the FOP server isn't doing a retry?

If I run a similar test with 2 different browsers (B1 and B2) connected with the same user and then:

bounce mysqld.
open the VM dialog with B1 I see the same failure being reported by wcolling.
But if I then immediately open the same VM dialog in B2 after B1 failing, B2 displays the New folder ok

Can you confirm that error handling behavior if when you try and connect to an ODBC resource and you receive some sort of exception?

Thanks,

JPS

Regarding deprecating the granular permission behavior of spy: listen vs listen+whisper. Is there any technical limitation/reason that this was changed? Any chance of getting the old behavior back?

If you must use asterisk voicemail passwords, this works really well:

In /etc/asterisk/voicemail.conf set:

externpassnotify = /usr/local/fop2/tickle_fop2.sh

And then have a script like this:

# cat > /usr/local/fop2/tickle_fop2.sh 
#!/bin/bash
sudo /usr/bin/killall -HUP fop2_server
exit 0;
<CTRL><d>

# chown asterisk.asterisk /usr/local/fop2/tickle_fop2.sh
# chmod u+x /usr/local/fop2/tickle_fop2.sh

Don't forget to add user asterisk to /etc/sudoers (using visudo):

asterisk ALL=(ALL) NOPASSWD: /usr/bin/killall -HUP fop2_server

Cheers,

JPS

Do you have any explanation as to why then when I manually send just a "prefix" of the channel from AMI as opposed to the complete channel id then the channel is never spied upon but if I send a complete channel id it works just fine?

Hi,

We are using * 1.6.2.10 with the latest FOP2 (2.20). When using Listen from FOP2 we see ringback to the Listening station but after its answered we never hear the spied on channel (just hear silence) and no Spy is logged on the console.

Our fop2.cfg uses spy options "bq" and our AMI connection as read/write = all.

When running packet capture with ngrep we see the AMI command issued by the fop2_server as:

T 2011/02/23 16:51:52.533770 127.0.0.1:51161 -> 127.0.0.1:5038 [AP]
Action: Originate.


T 2011/02/23 16:51:52.572979 127.0.0.1:51161 -> 127.0.0.1:5038 [AP]
Channel: SIP/0004F22F774A.
CallerID: 5001.
Application: ChanSpy.
Data: SIP/0004F22CF7E2,bq.
ActionID: fop2spy!SIP/0004F22CF7E2.
Async: True.
.


T 2011/02/23 16:51:52.573160 127.0.0.1:5038 -> 127.0.0.1:51161 [AP]
Response: Success.

Notice how the Data portion only contains the SIP peer name and not the complete Channel ID (which in this case was SIP/0004F22CF7E2-000038f0 via core show channels).

If I manually connect to AMI and issue the exact same Originate Action with the complete Channel ID (i.e. Data: SIP/0004F22CF7E2-000038f0,bq the Spy works correctly (the Spying station gets rung, then Spies on the channel listed in the Data).

That all said, should the fop2_server send the complete Channel ID in the Data portion of the Originate Action or is sending the partial Channel ID (the sip peer name) supposed to be sufficient?

Thanks,

JPS