Recording calls after agent has successfully left transfer

[Nefariousparity]

||Version: 2.4b0.5 || DB Schema Version: 1273 || GoautoDial ISO install || 1.4.39.1-vici||Cluster||VERSION: 2.4-309a||BUILD: 110430-1642
###############################################################
So here is my current Dialplan

exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,2,Dial(SIP/${EXTEN:1}@Connecium,,tTo)
exten => _91NXXNXXXXXX,3,Dial(SIP/${EXTEN:1}@Xcast_OutBound,,tTo)
exten => _91NXXNXXXXXX,4,Hangup

I currently would like to record calls, *After my agent* has left the conference on the live three way transfer.
I found this URL. http://www.vicidial.org/VICIDIALforum/viewtopic.php?t=19016

Bobby Bow wang writes,

exten => _71.,1,AGI(agi-NVA_recording.agi,BOTH------Y---N---Y---N)
exten => _71.,n,Goto(default,${EXTEN:2},1)
exten => _71.,n,Hangup

Seems like a plausible solution, My question would be is there a way I can combine these two?

Something like, exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log,agi-NVA_r ... -N---Y---N)?
Or is it something like?

exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,1,AGI(agi-NVA_recording.agi,BOTH------Y---N---Y---N)
exten => _91NXXNXXXXXX,2,Dial(SIP/${EXTEN:1}@Connecium,,tTo)
exten => _91NXXNXXXXXX,3,Dial(SIP/${EXTEN:1}@Xcast_OutBound,,tTo)
exten => _91NXXNXXXXXX,4,Hangup

Tl;DR; What is the proper syntax of having the best of both worlds?

Kind regards, Thank you in advance!

[williamconley]

have a look at the defaultlog context. It is already designed to do this for you. It executes the recording, and then transfers the call back to default to execute normally.

[Nefariousparity]

Hi William. I'm not sure if I understand you? Or if you don't understand me. So I will try to re-iterate what my objective is more clearly. Just in case.

I want to continue to record a call after an Agent leaves the 3 way conference.

This way, if a client says, your agent did not say this, this, or this. I can pull of the recording, and say, "No, your salesmen just suck as closers, because of this recording..."

If this is already happening? How do I locate that file?

[williamconley]

engage the 3-way call with defaultlog and the 3-way call will be recorded. with a bit of work you could even figure out how to add this new recording to the lead record (which we did for a couple clients in the past). In fact, we even have a functional 3-way call real time screen. With monitor and Barge.

[mflorell]

Just last week I added the code to allow the NVA recording AGI script to tie a 3-way call recording to a lead_id and user. If you upgrade to the latest svn/trunk you will get this feature.

[rrb555]

How do we enable this feature? And what are the brand new things we will see in the admin page after the 3-way call?

VERSION: 2.6-396a
BUILD: 130402-2322
Revision 1952

[Nefariousparity]

Mflorrel Sounds great, however last time I tried to upgrade to the latest version, I broke the dialer. As I see people walking in right now I am scared to do such actions on production server!! Dough, but it has to be done.

[williamconley]

Install the same version you have in a Virtual server (VMWare is free, Virtualbox is free, vSphere is free ...). Then back up your present system and restore the DB to the virtual one. You will need to run the IP update script from the old ip to the virtual server's IP. Then you can test it with one or two calls to be sure it works (fake calls of course so as not to annoy any real people). When you have it working ... "snapshot" the virtual server. Then practice upgrading until you are sure it will work on the Real server.

[Nefariousparity]

Hi William, I am attempting to do what you said. I have setup Vm ware, and successfully installed. http://goautodial.org/attachments/downl ... l.iso.html. Applied update for 2.2.0. Then did update for 2.2.6 My Test server looks like this.

||Version: 2.6b0.5 || DB Schema Version: 1345 || Distro Name GoAutoDial CE 2.1 || Asterisk 1.4.39.1-vici||VERSION: 2.4-309a||BUILD: 110430-1642

Now this is a VMware install, on a server, on a local class c network, behind firewall. Are the issues I am having with this connecting to carrier the result of the sip issues behind duel firewall thing? I Have port 5060 TCP\UDP forwarded, and 10000-20000 UDP forwarded to the "BRIDGED" network vmware interface ip.

[williamconley]

since you are testing "upgrade" not "carrier configuration", you could consider pointing a fresh carrier on this box to a generic carrier (any will do) or even to your live server (so you'd control both sides of the call ...).

if you are behind a firewall, it is often necessary to modify sip.conf and enable the "externip=" setting (filling in the value of your router's external IP). often this is necessary when behind a firewall for security and/or SIP firewall navigation purposes. Many systems will rely on the SIP packet to have the proper IP address and send all voice packets to that IP, and if that IP is private ... the packets never leave the local subnet for the carrier! LOL. So externip will tell that server where the "outer firewall is" to send the packets.

Ordinarily, an upgrade fail will case blanks in the administration screen and the inability of agents to log in to the agent screen, which is mostly what you are checking for. Absolutely a good idea to also validate outbound/inbound calls, though. Certainly

[Nefariousparity]

William, you are a scholar, and a saint. Thank you so much. So far everything runs fine, agents can login with no issue. Just wanted to get a active carrier running after the upgrade to verify before I go modifying our production server.

[williamconley]

for the purpose of the experiment, build a fake carrier to your other server. if the fake still works after the upgrade ... odds are quite good that the real one will too. and you won't accidentally call a real customer if your fake carrier is only capable of calling "cc101" on the other dialer