Listen and Transfer to Conference

I have a question about a use case that I have not tried (scared of what might go wrong).

Wondering if I have chosen all of the right parts and if I have the pattern down, or if anyone else has done this before. I learned to transfer calls which was fairly easy to do. I would like to "Listen" and then transfer my listen into a conference bridge, so that an outside caller can participate in Listen without having any control (or minimal control) themselves. Don't want to test too hard, because I only have a production call center.

It's very easy to do what I'm describing using two lines, and a two line phone that can bridge. I was trying to do without that extra piece of hardware, it should be possible within Asterisk without being clunky.

Here is the scenario:
[list:p1jtbl50][*:p1jtbl50]Remote user is on the phone[/*:m:p1jtbl50]
[*:p1jtbl50]Local user has permission to listen to several call center workers[/*:m:p1jtbl50]
[*:p1jtbl50]Remote user is blind transferred to conference (MeetMe options are set to: no announcement, for example.)[/*:m:p1jtbl50]
[*:p1jtbl50]Local user initiates a Listen with the fop2 panel[/*:m:p1jtbl50]
[*:p1jtbl50]Local user bridges his channel with the conference[/*:m:p1jtbl50][/list:u:p1jtbl50]
That last step is what I'm having trouble thinking out. I think that what I want is an attended transfer, where the local user just doesn't hang up, but I'm not sure. If the remote user is left listening to a fast-busy while (until? after?) the local user is looking for another active call center station to connect back to the conference, that's going to be bad. If the Listen session is not automatically disconnected from the conference when it's over, that will also be bad.

Not sure if I just said two different things or just repeating myself. Ideally the remote user stays in the conference and goes back to music on hold until another Listen session is bridged into the conference, which should be pretty quick.

If the local user has to dial into the conference after transferring the Listen session in, that will be bad also. If any dialing tones or listen-user conversation were to leak into the listened call because of the transferring, that would be bad too. If the workflow is not perfectly fluid, I think we could live with it, but if there's something else I should be using other than blind transfer or attended transfer (or fop2 panel-based transfer), I was hoping you could suggest a path to try.

Hopefully I've made it clear what I'm trying to do.

Also worried that when I set permissions to 'spy' only, the action buttons available include both 'Listen' and 'Listen and Whisper'. How do I properly disable whisper? It seems to be a separate permission and I have not included it, like this:
user=100:9999:spy
... but the button for Listen and Whisper persists in the user interface.

If nobody has tried this type of monitoring at all, I will be surprised, but in that case I could be the first and report back on what works. Other features I've heard of, but had problems with:

You can press '*' in Spy mode to 'look for another channel to spy' -- doesn't work for me. Not sure if Listen uses ChanSpy, ExtenSpy, or something else.
You can create dialing groups so that if your call center is working on 3 projects and only one client wants monitoring, pressing '*' to cycle brings you to another active channel in the same group.

I have never used 'persistent_spy' config option but with this * cycle feature, it might be very useful.

I believe these channel/spy groups are not the same as the groups in fop2.conf. Just tried populating those for the first time. I appreciate any help you can give me!

Comments

  • Hi,

    I do not think that you could transfer a chanspy session at all, as it is not a real bridged call. Also, what you read about chanspy cycling works if you setup all those groups and tidbits in your asterisk dialplan. FOP2 does not mess with your dialplan, so those features will not be available unless you tweak your dialplan for it, setting the spygroup variable for your relevant channels (and then you will have to set the relevant g() in fop2.cfg's spy_options or whisper_options to pass the corresponding/needed/wanted chanspy modifiers when invoking a spy session).

    The listen and listen and whisper are now using only the spy permission.

    I have not tried, but perhaps (ab)using local channels you could add the chanspy application into a confbridge/meetme room. But most probably thing will go bonkers or act funny. Having a custom extension that will launch chanspy and then inviting that extension into a meetme via fop2, by clicking the meetme button and typing the extension. consider this:

    [from-internal-custom]
    exten => _556XXX,1,Answer
    exten => _556XXX,n,Wait(1)
    exten => _556XXX,n,ChanSpy(SIP/${EXTEN:3})
    exten => _556XXX,n,Hangup

    If you dial 556100 it should launch chanspy on SIP/100. Now, from fop2 invite that extension to a conference and see what happens.

    Best regards,
Sign In or Register to comment.