Page 1 of 1
Caller ID with FXO (Continuing)
Posted:
Tue Aug 29, 2006 8:53 am
by mtancoff
Ok. But it works fine with 4 digits caller ID. I have a sipura simulating an incoming analogic line conected to Zaptel interface in vicidial.
This sipura is registered in another asterisk (FreePBX), so I can call from any extension of mi FreePBX to this sipura, simulating an incoming call in vicidial.
In this case, I can see the CID just fine, 4 digits corresponding to the extension of FreePBX originating the call.
Another question:
Could Vicidial look-up CID in a table and show the agent the name of the person calling?
Thanx a lot
Posted:
Tue Aug 29, 2006 9:25 am
by mflorell
The test one you are receiving is probably working because it is formatted as <1234> "cidname" and the one you are receiving from your telco is just sending a number 1234.
To do a lookup to try to find an existing name in your vicidial_list table, just use the inboundCIDlookup AGI script.
Posted:
Tue Aug 29, 2006 11:29 am
by mtancoff
Ok this would be my Goal:
When an agent receives a call, if the CID exists in vicidial_list, the agent should see all available info.
If the records doesn't exist, the agent should see only CID, and vicidial should insert a record in vicidial_list when the call is finished.
Is that the way agi-VDADCloser_inboundCIDlookup works?
Can this be implemented?
Thanx Again
Posted:
Tue Aug 29, 2006 11:33 am
by mflorell
That is the way that script works. You just need to tinker with the script to get it to accept the way CallerID is being sent to you from your telco.
Posted:
Tue Aug 29, 2006 12:42 pm
by mtancoff
Im experimenting with the inboundCIDlookup.agi, but calling from sipura, don't want to break my head with TELCO problems yet, I'd like to solve the CIDlookup first, then move on.
I can't get records inserted if the CID doens't exists in vicidial_list. Post You the results:
Executing Verbose("Zap/1-1", "Incoming call from BT line . CallerID="2600" <2600>") in new stack
Incoming call from BT line . CallerID="2600" <2600>
-- Executing AGI("Zap/1-1", "agi-VDADcloser_inboundCIDlookup.agi|CL_ENTRANTES-----7275555134-----Closer-----park----------999-----1") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDADcloser_inboundCIDlookup.agi
Perl Environment Dump:
0|CL_ENTRANTES-----7275555134-----Closer-----park----------999-----1|
AGI Environment Dump:
-- accountcode =
-- callerid = 2600
-- calleridname = 2600
-- callingani2 = 0
-- callingpres = 0
-- callingtns = 0
-- callington = 0
-- channel = Zap/1-1
-- context = default
-- dnid = unknown
-- enhanced = 0.0
-- extension = s
-- language = en
-- priority = 3
-- rdnis = unknown
-- request = agi-VDADcloser_inboundCIDlookup.agi
-- type = Zap
-- uniqueid = 1156872897.7
INBOUND CALL VDCL STARTED
+++++ INBOUND CALL VDCL STARTED : |1156872897.7|CL_ENTRANTES|Zap/1-1|s|Zap|Closer-7275555134|2006-08-29 14:34:58
AGI Environment Dump: |1156872897.7|Zap/1-1|s|Zap|Closer|
INBOUND CALL RECEIVED IN FROM VDCL: Closer Zap/1-1
+++++ INBOUND VDCL START : |1156872897.7|Zap/1-1|s|Zap|2006-08-29 14:34:58
|SELECT lead_id from vicidial_list where list_id='999' and phone_number='2600' order by modify_date limit 1;||
FAIL (unexpected result '')
callerID changed: Y0829143458000000000
|INSERT INTO vicidial_auto_calls values('','127.0.0.1','CL_ENTRANTES','LIVE','','1156872897.7','Y0829143458000000000','Zap/1-1','1','2600','2006-08-29 14:34:58','IN')|
Posted:
Tue Aug 29, 2006 12:52 pm
by mflorell
"FAIL (unexpected result '') " is not related to the INSERT query, it is related to the altering of the callerIDname(and it's not actually an error)
Is the record not showing up in the vicidial_list wher you do a SELECT for it in mysql?
Posted:
Tue Aug 29, 2006 3:02 pm
by mtancoff
When I select from vicidial_list, I can see that no record was inserted. But inserts fine when using closer_inboudCID.agi
Looks like the INSERT never gets executed.
Strange, eh?
Posted:
Tue Aug 29, 2006 3:36 pm
by mflorell
That is quite strange. Could you try using the 2.0 codebase?
I'm about to release a beta 2.0.1 later today which has many fixes to it and I will no longer be fixing 1.1.X code when 2.0.1 is officially released.
Look for more details on the Developer Forum here in an hour or so.