Page 1 of 1

Caller ID issue when transferring call in survey camp

PostPosted: Tue Aug 06, 2019 2:04 am
by Jitin
Hello Sir

Asterisk version : 11.22.0
VERSION: 2.14-588a
BUILD: 170211-1041
OS : centos 6.9
It is a scratch install.


I am using a survey camp on which I tried 2 methods :

1) servery method : extension : there the number to be dialed and transferred
2) servey method : call menu : then ingroup : from there in after-hours, transferring call via extension and trying to pass customer caller ID

In camp : 3-way caller ID is chosen as customer

Still caller id is going as
agi_callerid: V8060241070002360953
agi_calleridname: V8060241070002360953

it should go as the lead which was dialed during the server (the customer number)

Please help me out on this and provide a immediate solution

thanks...........

Re: Caller ID issue when transferring call in survey camp

PostPosted: Tue Aug 06, 2019 3:03 am
by bourneshell
The 3-way caller ID will only be used when the agent who received the call transfers a call.

I guess the best solution is to use your 2nd Survey Method. And set "Handle Method" on the ingroup to CLOSER

Re: Caller ID issue when transferring call in survey camp

PostPosted: Tue Aug 06, 2019 4:17 am
by Jitin
tried that as well but customer caller ID is not going
agi_callerid: V8060241070002360953
agi_calleridname: V8060241070002360953

it sends something like this and not the number

Re: Caller ID issue when transferring call in survey camp

PostPosted: Tue Aug 06, 2019 4:22 am
by bourneshell
when you have an agent available does the caller ID show the customer number?

also for after hours what do you had set on "Action Transfer CID" inside the ingroup settings?

Re: Caller ID issue when transferring call in survey camp

PostPosted: Tue Aug 06, 2019 4:29 am
by Jitin
when you have an agent available does the caller ID show the customer number?
yes

also for after hours what do you had set on "Action Transfer CID" inside the ingroup settings?
Action Transfer CID : CUSTOMER

Re: Caller ID issue when transferring call in survey camp

PostPosted: Tue Aug 06, 2019 5:03 am
by bourneshell
Please try setting Action Transfer CID to "CUSTOMERCLOSER" and see if after hours pass the caller ID correctly

Re: Caller ID issue when transferring call in survey camp

PostPosted: Tue Aug 06, 2019 5:25 am
by Jitin
Still the same thing
no good

Re: Caller ID issue when transferring call in survey camp

PostPosted: Wed Aug 07, 2019 12:29 am
by ed123
use ingroup and set the CID as customer.

Re: Caller ID issue when transferring call in survey camp

PostPosted: Tue Aug 13, 2019 11:41 pm
by williamconley
Try creating a special carrier just for this transfer. It can use the same telephone company, and in fact can be a copy of the original carrier entry but with a different dial prefix. The only other change (besides the dial prefix, used to select this carrier entry) would be to leave off the "agi" line.

So if you have dial 9 prefix like this:
Code: Select all
exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,n,Dial(${CARRIER1}/${EXTEN:1},,tTor)
exten => _91NXXNXXXXXX,n,Hangup


You could create dial 8 prefix for transfers only (with 8 in the 3-way-call-dial-prefix field):
Code: Select all
exten => _81NXXNXXXXXX,1,Dial(${CARRIER1}/${EXTEN:1},,tTor)
exten => _81NXXNXXXXXX,n,Hangup


The only two changes, missing the agi line and 8 instead of 9 for the dial prefix. That MAY solve your problem.

Also verify your Asterisk version in the astguiclient.conf file and in admin->servers. If you make any changes, you *may* need to run install.pl again (carefully, since you'll need to use "copy sample conf files" which will overwrite any previously edited conf files and you'll need to re-edit them, especially externip in sip.conf, which *should* be the only changed file if you are Vicidialing Correctly, lol 8-) )

If you DO copy the carrier: delete the "account entry" section since there can only be one sip.conf context with each name (so having a second copy could create a problem some day). Carriers CAN use each other's account entry information, though, so deleting the second one is the proper solution.