vicidial.org

Hello,

let me start by saying I have my version information posted to my signature if any other information is required I can update.

Here is my Scenerio

2 seperate server clusters

cluster A running survey with press 1 option sending calls from this cluster
cluster B running agents receiving calls on this cluster

Survey is configured to transfer to EXTENSION 1234 and is operated by remote agents with on-hook disabled.

Carrier settings configured with direct connection to receiving cluster and dialplan entry for 1234 to dial over this connection with correponding DID on second cluster to capture call into IN-GROUP.

Issue

Every call comes in with the campaigns CID changing survey method to agents and allowing the remote agent be the place of transfer then gives me a session id of sorts as a CID. Also chaning the ACTION CID in the INgroup and 3way call CID have no affect. Changing 3 way call CID in the campaign results in a completely differetn CID starting with a V ex. V0000328491278459

I have been reading testing and beating my head on the wall trying to correct this but what i need is for the CALLERS CID to pass through and be displayed on the receiving end.

any help is much appriciated.

So the number starting with the V looks to be the call_code when pulling the call reports.

Anyone else dealt with this before?

You have, truth be told, posted the technical minimum required to access support on the board. But it would be nice if you posted more ... so ...:

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) Why are you not merely having the agent log in to or be members of the primary cluster? (Seriously, not being a smart@ss, the answer to this question often helps figure out some of your other problems/restrictions/goals.) Otherwise, since we have no idea why you have chosen to build your four-masted schooner inside a tiny bottle, we may all watch curiously while sailing ours on the open seas happily ...

4) CallerID is often changed by the Carrier dialplan entry that has the AGI line in it. If you make sure your call TO THE AGENT uses a carrier that does not pass through a dialplan with the agi line ... you may get your wish.

5) You would do even better, of course, to use an inter-asterisk account schema that would allow a call to an agent on the primary cluster to pass to the sub-cluster if/when appropriate. We used to set this up all the time for clients that had multiple FreePBX servers and even those that had Vicidial and FreePBX (where the agents would have FreePBX connected phones that they wanted to accept their agent calls on). This need not (in any way) pass through a carrier dialplan entry.

PS: "Revision 2015" may be best changed to SVN Rev 2015 to avoid misunderstandings.

I was waiting for your infamous canned response lol thanks for the input william you are always a help, I've actually been around for a long time just do more reading then posting.

I have updated my signature specs

In response to your questions:

3) Why are you not merely having the agent log in to or be members of the primary cluster? (Seriously, not being a smart@ss, the answer to this question often helps figure out some of your other problems/restrictions/goals.) Otherwise, since we have no idea why you have chosen to build your four-masted schooner inside a tiny bottle, we may all watch curiously while sailing ours on the open seas happily ...

There are several reasons for this but my biggest intent is load balancing the systems that agents are handling live calls on are also recording every call and handling other db functions. I have had issues with recordings missing or being inaccurate (right file wrong person?) along with choppy voice quality etc, my testing and research has lead me to this being load related. So i am assentially seperating the dialing servers from the agent servers also lighting the db input on the agent server, there are also other client reasons for this configuration. I have multiple clusters in my network I am just referencing one.


4) CallerID is often changed by the Carrier dialplan entry that has the AGI line in it. If you make sure your call TO THE AGENT uses a carrier that does not pass through a dialplan with the agi line ... you may get your wish.

I have been looking into this issure for a few days now and came accross what you are referencing in other posts and places online. I have removed all AGI lines from any dialplans involving this call but i am not getting the results i wish.

The campaign it self although automatically uses /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi. I am almost certain that this is where the caller ID is being changed as you can see it in the scripting and one small part it Prints which says CALLERID CHANGED

I am not agi fluent enough to alter this script properly. I have even tried changing the dialplan for 8373 in the extensions.conf with other variables from the agi script but some changes have just caused the survey to fail completely. ex.

# ; - SURVEY - For survery question then on to agent
# ; - SURVEYCAMP - For survery question using campaign settings


changing from survey camp to survey in the dail plan entry causes it to wet the bed not sure what the difference in these settings are anyway except for one says campaign settings i was hoping maybe this would bypass campaign configurations.


I am not sure how to respond to your last question as I felt it was referring to sending calls directly to an agent. I am attempting to send these calls to a DID configured in vici to route to an Ingroup

Currenty dialplan entry which is sending the call in question.

exten => 4700,1,Dial(SIP/trunk-d1/600201,,To)
exten => 4700,n,Hangup


Once again i appreciate any insight.

Thank you!

Janky wrote:There are several reasons for this but my biggest intent is load balancing the systems that agents are handling live calls on are also recording every call and handling other db functions. I have had issues with recordings missing or being inaccurate (right file wrong person?) along with choppy voice quality etc, my testing and research has lead me to this being load related. So i am assentially seperating the dialing servers from the agent servers also lighting the db input on the agent server, there are also other client reasons for this configuration. I have multiple clusters in my network I am just referencing one.

From this I am getting "this is a test configuration, attempting Smooth Clean Reliable operations on all fronts ... separating the roles to allow each role to be independently troubleshot.

Note: Your primary server will still be handling the same load. Your agents will not have screens (no client data). Viable. You may succeed. Interesting approach.

Janky wrote:4) CallerID is often changed by the Carrier dialplan entry that has the AGI line in it. If you make sure your call TO THE AGENT uses a carrier that does not pass through a dialplan with the agi line ... you may get your wish.

I have been looking into this issure for a few days now and came accross what you are referencing in other posts and places online. I have removed all AGI lines from any dialplans involving this call but i am not getting the results i wish.

The campaign it self although automatically uses /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi. I am almost certain that this is where the caller ID is being changed as you can see it in the scripting and one small part it Prints which says CALLERID CHANGED

That would seem to be contradictory. Your "outbound" agi script should NOT be fired up on the leg of the call being sent to the AGENT. That call should be pure asterisk. If an agi script is indeed being invoked, it should not be related to this leg of the call ... if it is: it would be because the agi line in the carrier being used to call the agent was invoked. Which is what I was saying to avoid. Look at it this way: If the agent were local (using a phone registered to the vicidial server), the system would just call "100" which would immediately translate to "SIP/gs100" and the call would connect. No callerid change, the only line on the local dialplan that would execute would be to dial the sip channel. But if you send the call "off-box", you risk invoking more dialplan lines. Your goal here is to avoid any extraneous ones. Happy Hunting

[Mar 9 22:54:01] -- Executing [917275551212@default:1] Dial("Local/917275551212@default-00000004;2", "SIP/carrier-d1/17275551212,,To") in new stack
[Mar 9 22:54:01] == Using SIP RTP CoS mark 5
[Mar 9 22:54:01] -- Called SIP/carrier-d1/17275551212
[Mar 9 22:54:12] -- SIP/carrier-d1-00000009 answered Local/917275551212@default-00000004;2
[Mar 9 22:54:12] > Channel Local/917275551212@default-00000004;1 was answered.
[Mar 9 22:54:12] -- Executing [8373@default:1] Playback("Local/917275551212@default-00000004;1", "sip-silence") in new stack
[Mar 9 22:54:12] -- <Local/917275551212@default-00000004;1> Playing 'sip-silence.gsm' (language 'en')
[Mar 9 22:54:12] -- Executing [h@default:1] AGI("Local/917275551212@default-00000004;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----11-----0") in new stack
[Mar 9 22:54:12] -- Executing [8373@default:2] AGI("SIP/carrier-d1-00000009", "agi://127.0.0.1:4577/call_log") in new stack
[Mar 9 22:54:12] -- AGI Script Executing Application: (EXEC) Options: (Set(_CAMPCUST=1000))
[Mar 9 22:54:12] -- <SIP/carrier-d1-00000009>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Mar 9 22:54:12] -- Executing [8373@default:3] AMD("SIP/carrier-d1-00000009", "2000,2000,1000,5000,120,50,4,256") in new stack
[Mar 9 22:54:12] -- AMD: SIP/carrier-d1-00000009 7402223333 (N/A) (Fmt: slin)
[Mar 9 22:54:12] -- AMD: initialSilence [2000] greeting [2000] afterGreetingSilence [1000] totalAnalysisTime [5000] minimumWordLength [120] betweenWordsSilence [50] maximumNumberOfWords [4] silenceThreshold [256] maximumWordLength [5000]
[Mar 9 22:54:12] -- AMD: Channel [SIP/carrier-d1-00000009]. Changed state to STATE_IN_SILENCE
[Mar 9 22:54:13] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 9 22:54:13] -- <Local/917275551212@default-00000004;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... --11-----0 completed, returning 0
[Mar 9 22:54:13] == Spawn extension (default, 917275551212, 1) exited non-zero on 'Local/917275551212@default-00000004;2'
[Mar 9 22:54:14] -- AMD: Channel [SIP/carrier-d1-00000009]. ANSWERING MACHINE: silenceDuration:2000 initialSilence:2000
[Mar 9 22:54:14] -- Executing [8373@default:4] AGI("SIP/carrier-d1-00000009", "VD_amd.agi,8373") in new stack
[Mar 9 22:54:14] -- Launched AGI Script /usr/share/asterisk/agi-bin/VD_amd.agi
[Mar 9 22:54:14] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Mar 9 22:54:14] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Mar 9 22:54:14] -- <SIP/carrier-d1-00000009>AGI Script VD_amd.agi completed, returning 0
[Mar 9 22:54:14] -- Executing [8373@default:5] AGI("SIP/carrier-d1-00000009", "agi-VDAD_ALL_outbound.agi,SURVEYCAMP-----LB") in new stack
[Mar 9 22:54:14] -- Launched AGI Script /usr/share/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi
[Mar 9 22:54:15] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Mar 9 22:54:15] -- Playing 'AUDIOFILE' (escape_digits=18) (sample_offset 0)
[Mar 9 22:54:22] DTMF[11109]: channel.c:4151 __ast_read: DTMF begin '1' received on SIP/carrier-d1-00000009
[Mar 9 22:54:22] DTMF[11109]: channel.c:4155 __ast_read: DTMF begin ignored '1' on SIP/carrier-d1-00000009
[Mar 9 22:54:22] DTMF[11109]: channel.c:4066 __ast_read: DTMF end '1' received on SIP/carrier-d1-00000009, duration 118 ms
[Mar 9 22:54:22] DTMF[11109]: channel.c:4135 __ast_read: DTMF end passthrough '1' on SIP/carrier-d1-00000009
[Mar 9 22:54:22] -- <SIP/carrier-d1-00000009>AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0
[Mar 9 22:54:22] -- Executing [4700@default:1] Dial("SIP/carrier-d1-00000009", "SIP/trunk-d1/600201,,To") in new stack
[Mar 9 22:54:22] == Using SIP RTP CoS mark 5
[Mar 9 22:54:22] -- Called SIP/trunk-d1/600201
[Mar 9 22:54:22] -- SIP/trunk-d1-0000000a answered SIP/carrier-d1-00000009
[Mar 9 22:54:24] -- Executing [h@default:1] AGI("SIP/carrier-d1-00000009", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----11-----2") in new stack
[Mar 9 22:54:24] -- <SIP/carrier-d1-00000009>AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... --11-----2 completed, returning 0
[Mar 9 22:54:24] == Spawn extension (default, 4700, 1) exited non-zero on 'SIP/carrier-d1-00000009'

I think it is changing the CID before that leg of the call is made hence placing that leg of the call with the wrong callerid

I think you should test this first with a logged in on-hook agent ... get it working the way you want ... then work on how to move it (slowly) to the external patchwork you've chosen.

Baby steps.

I was really hoping this would be one of those man your stupid all you gotta do is click this option issues lol.

I am going to test that now.

Remote Agent with dialplan extension to route to primary cluster set on-hook active. Changed survey to agent-transfer. Call comes through with call_code as CID. basically the same as ive tested before. It appears that no matter what the outbound.agi is placing a CID on the call before it is placed to the second cluster

Was this an on-hook logged in agent attached to the primary cluster with a REGISTERED phone to the primary dialer?

No this was from the secondary cluster (the one sending call)

If you are referring to setting this up on the primary cluster only I already have that working with out issue.

which is making this some what confusing what is the difference in the survey sending straight to the agent/Ingroup or sending to another server if there is no dialplan affecting it. Similar to what you mentioned previously

agent vs ingroup are HUGELY different. you cannot put those in the same category.

specify the path of the call that works ON the server. make minor changes as you go. you'll find your issue. note that Ingroup has a setting for on-hook CID. calls to agents do not.

how does the primary server send the call to the subserver? what path does it take? this would be dialplan and account ... likely sip. the extensions.conf and sip.conf entries are both capable of altering the CID.

the calling cluster is sending the call to the agent cluster via an IP Authenticated sip connection. with the dial plan i posted above. I am finding it hard to believe that this is not a common configuration with the amount of vici applications being used for lead based call transfers

this isn't about hard to believe. it's about making it work in SOME fashion, then bringing that forward to find the break and handling the break.

unless you don't like hair (or are already bald like the rest of us). if you want to fix it, do it in baby steps. find a method that works and slowly convert it to what you want. with each step TEST and if it breaks, fix it before moving to the next step. Just like getting a survey working in the first place. don't tell me you just tried that and it worked the first time. LOL

do you know of anyway to run the survey and bypassing the configurations of the AGI script. I am assuming that if the script is not invoked the survey functionality will not work would this be a valid assumption?

# 81104-0255 - Changed code to alter callerIDnumber for remote agents to the number of the caller


looking at tha outbound agi i see this in the revisions

where is that because i dont think its working lol

Would i need to pull the lead phone number to have it placed as the callerID as im thinking about this the call is originating as an outbound call. so is there any point where it would actually pick up the called party as the CID?

what syntax would i need to add to my dialplan to attached the CALLED PARTY CID to the call before it is sent to the next server?

syntax to add cid name or cid number is part of the asterisk protocol and can be managed in several ways based on how you intend to implement. for instance, sip accounts can have cid defined for them in the sip context and individual calls can have the parameters SET during the execution of the dialplan. it is handy, of course, to have the CID in a variable so you can assign the cid differently for each call.

vicidial, of course, handles all of this already. but if you want to try your hand at it, this would be a good place to start:

http://bit.ly/1gnB6Q0

do you really think i would be asking here if I did not already summon the google. do you give anyone credit or are you just that kind of punt master lol.

williamconley wrote:individual calls can have the parameters SET during the execution of the dialplan

This is the dialplan syntax I am looking for my research has led me in many directions and my trials have not resulted in a resolution. If anyone has any helpful input it is much appreciated.

Thank you!

Ive managed to get response on the CLI of the attempt in changing the CID from my dialplan entry but once the call is received it still has the incorrect number.

anyone have any experience with DIALEDPEERNUMBER

Any idea on how i would go about referencing the called lead to pull the correct callerid to be placed on the second outbound call?

There are multiple methods. All of which are "stepping outside Vicidial" which already does this.

However, if you do not feel as though you are able to make it work like everyone else and want to "dive in" (no fear of the learning curve!):

Your challenge is that you will be generating a fresh call that is actually in NO WAY linked to the lead in question. Getting the callerid from a lead requires some link to the lead. The ONLY link is the conference room generating the call. You'll need to use an AGI script to gather whatever information is available and see if any of it will lead you to the conference room, then find the appropriate data in the vicidial tables and ultimately bounce through a few sql calls to get all the way back to the lead table.

Not the way I'd go, but ...

yea that was kind of my thought process on it also. I think safest route is figuring out which of the vici agi script im going to need to alter to make this work the way i need it to.

I was really expecting to get some more insight on this seems like you are the only one that has responded to this thread at all

ive been making attempts at this in so many ways im not even certain why it is changing the CID at all there is not really much difference in what is happening in my call process than there is in passing a call to an agent the only difference is the extension is on a external server.

DIALEDPEERNUMBER in my dialplan actually reflected the carrier string and correct DID number in my CLI but still resulted in the camp CID when the call arrived at the second cluster which really did not make sense

and yes i even tryed sending the call to a valid extension on the same server with the same result which is what gets me even more why would sending a Survey to a Method of Extension result in the Campaigns CID being used. Further more if it was sent to the remote agent then transfered to an extension or external phone (hence the purpose of the remote agent feature) you would think it would be best practice to receive the remote party CID otherwise if i were just receiving these calls to a POTS line or something I would never know the difference of who is calling???

any reason survey can't send to in-group?

as far as i know, survey CAN send to ingroup. are you saying it can't? haven't looked. LOL (if it can't, you can still send it to a menu and have the menu immediately send it to an ingroup based on calltimes).

Nope in-group is not an option in the survey settings. I have tryed running it through menus but have not really got the results I wanted I am also assuming it causes additional load and ive noticed it can make the call process take a bit longer.

If done properly, with calltimes causing the call to "fail the calltime check" the bounce to ingroup is immediate. I doubt you'd be able to measure the time taken. I also doubt you'd be able to measure the CPU power taken to decide to bounce the call to the ingroup. I suspect both are negligible.

Of course, you can also send the call to an Extension and write your own app for "what to do now" which would be executed by the chosen extension. Likely take more time than call menu -> ingroup, but certainly an option if you're feelin' like writing some code.

I got the same problem also, i tried the same changes as he has, Once the call goes to Call Menu it will show caller_code (name) not the caller id itself. which affects all reporting/correct number of customer etc. Any quick turnaround on this?

I tested this:

CUSTOMER->DID->CALLMENU->PRESS1->INGROUPS = WORKING! It will show the correct caller id of the customer.

However this is what I need and it is not working.

CAMPAIGN LEADS -> DIAL CUSTOMER-> PLAY SURVEY -> PRESS1 -> CALL MENU1-PRESS1->IGROUPS = NOT working, show CName(V6000000XXXXX) rather than CID.

Help will be much appreciated.

This looks familiar. Are you double-posting the same problem?

sorry about that. that is just the latest result that I got. Working when it is inbound call to Call Menu. Not working when using survey to call menu.

Probably a million years late, but I resolved a similar issue on a single server by setting the call menu handle method to CLOSER. Hopefully that helps someone down the line.