vicidial.org

VERSION: 2.14-583a
BUILD: 161226-2224
Asterisk 11.25.1-vici

I posted about this issue a month ago but I'm still having the same problem.

All calls that should be disposed with a system status (B, DC, NA, etc..) except for the AA (answering machine auto) are disposed as NEW by the system. If I use an older cloud running an older Vici:

VERSION: 2.12-561a
BUILD: 160708-0745
Asterisk 1.8.32.3-vici

Everything is disposed correctly by the system ( Using the same trunk/provider).

I did a fresh install using the latest ISO and I'm having the same issue.

Where could that problem come from ? I'm unable to find any post with the same issue on the forum

Additional infos :

Account Entry:

Code: Select all

[sogetel]
disallow=all
allow=ulaw
type=friend
username=*******
secret=******
host=*******
dtmfmode=rfc2833
context=trunkinbound
qualify=yes
nat=force_rport,comedia
insecure=port,invite


Dialplan:

Code: Select all

exten => _61NXXNXXXXXX,1,Set(CALLERID(name)=${CALLERID(num)})
exten => _61NXXNXXXXXX,2,SIPAddHeader(P-ASSERTED-IDENTITY: <sip:*******@24.37.84.78>)
exten => _61NXXNXXXXXX,3,AGI(agi://127.0.0.1:4577/call_log)
exten => _61NXXNXXXXXX,4,Dial(${TRUNKSOG}/${EXTEN:1},,tTor)
exten => _61NXXNXXXXXX,5,Hangup

exten => _6NXXNXXXXXX,1,Set(CALLERID(name)=${CALLERID(num)})
exten => _6NXXNXXXXXX,2,SIPAddHeader(P-ASSERTED-IDENTITY: <sip:*******@24.37.84.78>)
exten => _6NXXNXXXXXX,3,AGI(agi://127.0.0.1:4577/call_log)
exten => _6NXXNXXXXXX,4,Dial(${TRUNKSOG}/${EXTEN:1},,tTor)
exten => _6NXXNXXXXXX,5,Hangup


Call log ( 3 calls, all disposed as NEW by the system, should have been NA)

Code: Select all

[Jan  5 02:48:22]   == Manager 'sendcron' logged on from 127.0.0.1
[Jan  5 02:48:22]     -- Executing [618197761281@default:1] Set("Local/618197761281@default-00000011;2", "CALLERID(name)=**********") in new stack
[Jan  5 02:48:22]     -- Executing [618197761281@default:2] SIPAddHeader("Local/618197761281@default-00000011;2", "P-ASSERTED-IDENTITY: <sip:**********@24.37.84.78>") in new stack
[Jan  5 02:48:22]     -- Executing [618197761281@default:3] AGI("Local/618197761281@default-00000011;2", "agi://127.0.0.1:4577/call_log") in new stack
[Jan  5 02:48:22]     -- <Local/618197761281@default-00000011;2>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jan  5 02:48:22]     -- Executing [618197761281@default:4] Dial("Local/618197761281@default-00000011;2", "SIP/sogetel/18197761281,,tTor") in new stack
[Jan  5 02:48:22]   == Using SIP RTP CoS mark 5
[Jan  5 02:48:22]     -- Called SIP/sogetel/18197761281
[Jan  5 02:48:22]   == Manager 'sendcron' logged on from 127.0.0.1
[Jan  5 02:48:22]     -- Executing [614182693138@default:1] Set("Local/614182693138@default-00000012;2", "CALLERID(name)=**********") in new stack
[Jan  5 02:48:22]     -- Executing [614182693138@default:2] SIPAddHeader("Local/614182693138@default-00000012;2", "P-ASSERTED-IDENTITY: <sip:**********@24.37.84.78>") in new stack
[Jan  5 02:48:22]     -- Executing [614182693138@default:3] AGI("Local/614182693138@default-00000012;2", "agi://127.0.0.1:4577/call_log") in new stack
[Jan  5 02:48:22]     -- <Local/614182693138@default-00000012;2>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jan  5 02:48:22]     -- Executing [614182693138@default:4] Dial("Local/614182693138@default-00000012;2", "SIP/sogetel/14182693138,,tTor") in new stack
[Jan  5 02:48:22]   == Using SIP RTP CoS mark 5
[Jan  5 02:48:22]     -- Called SIP/sogetel/14182693138
[Jan  5 02:48:23]   == Manager 'sendcron' logged on from 127.0.0.1
[Jan  5 02:48:23]     -- Executing [618196847345@default:1] Set("Local/618196847345@default-00000013;2", "CALLERID(name)=**********") in new stack
[Jan  5 02:48:23]     -- Executing [618196847345@default:2] SIPAddHeader("Local/618196847345@default-00000013;2", "P-ASSERTED-IDENTITY: <sip:**********@24.37.84.78>") in new stack
[Jan  5 02:48:23]     -- Executing [618196847345@default:3] AGI("Local/618196847345@default-00000013;2", "agi://127.0.0.1:4577/call_log") in new stack
[Jan  5 02:48:23]     -- <Local/618196847345@default-00000013;2>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jan  5 02:48:23]     -- Executing [618196847345@default:4] Dial("Local/618196847345@default-00000013;2", "SIP/sogetel/18196847345,,tTor") in new stack
[Jan  5 02:48:23]   == Using SIP RTP CoS mark 5
[Jan  5 02:48:23]     -- Called SIP/sogetel/18196847345
[Jan  5 02:48:23]     -- SIP/sogetel-00000013 is making progress passing it to Local/618197761281@default-00000011;2
[Jan  5 02:48:24]     -- SIP/sogetel-00000015 is making progress passing it to Local/618196847345@default-00000013;2
[Jan  5 02:48:25]     -- SIP/sogetel-00000014 is making progress passing it to Local/614182693138@default-00000012;2
[Jan  5 02:48:48]   == Manager 'sendcron' logged off from 127.0.0.1
[Jan  5 02:48:48]   == Spawn extension (default, 618197761281, 4) exited non-zero on 'Local/618197761281@default-00000011;2'
[Jan  5 02:48:48]     -- Executing [h@default:1] AGI("Local/618197761281@default-00000011;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Jan  5 02:48:48]     -- <Local/618197761281@default-00000011;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL---------- completed, returning 0
[Jan  5 02:48:48]   == Manager 'sendcron' logged off from 127.0.0.1
[Jan  5 02:48:48]   == Spawn extension (default, 614182693138, 4) exited non-zero on 'Local/614182693138@default-00000012;2'
[Jan  5 02:48:48]     -- Executing [h@default:1] AGI("Local/614182693138@default-00000012;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Jan  5 02:48:48]     -- <Local/614182693138@default-00000012;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL---------- completed, returning 0
[Jan  5 02:48:49]   == Manager 'sendcron' logged off from 127.0.0.1
[Jan  5 02:48:49]   == Spawn extension (default, 618196847345, 4) exited non-zero on 'Local/618196847345@default-00000013;2'
[Jan  5 02:48:49]     -- Executing [h@default:1] AGI("Local/618196847345@default-00000013;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
[Jan  5 02:48:49]     -- <Local/618196847345@default-00000013;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL---------- completed, returning 0




I found a problem in your dialplan (first line), which could cause your issue. You are not allowed to change the "CALLERID(name)" manually, because actually Vicidial uses the callerid name for call log/tracking purposes and fills this with a unique system name. In order to change the callerid it's only possible to use the callerid number. If you want that the "P-Asserted-Identity" header gets also filled with the variable callerid number, then use "SIPAddHeader(P-Asserted-Identity: <sip:${CALLERID(num)}@24.37.84.78>)". Otherwise use static SIPAddHeader(P-Asserted-Identity: <sip:*******@24.37.84.78>). So try this:

Code: Select all

exten => _61NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _61NXXNXXXXXX,2,SIPAddHeader(P-Asserted-Identity: <sip:${CALLERID(num)}@24.37.84.78>)
exten => _61NXXNXXXXXX,3,Dial(${TRUNKSOG}/${EXTEN:1},,tTor)
exten => _61NXXNXXXXXX,4,Hangup

exten => _6NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _6NXXNXXXXXX,2,SIPAddHeader(P-Asserted-Identity: <sip:${CALLERID(num)}@24.37.84.78>)
exten => _6NXXNXXXXXX,3,Dial(${TRUNKSOG}/${EXTEN:1},,tTor)
exten => _6NXXNXXXXXX,4,Hangup



Setting callerID name before the AGI script runs is acceptable because the AGI script will set the callerID name anyway. But calls made without a campaign (direct from the agent phone for instance) will then get the callerID name (possibly) as you set it.

That being said: Modifying the name is pointless within the US anyway. Carriers in the US pull the name from a shared database, regardless of what you set callerID name to.

Now for your problem: NEW generally means the Vicidial system never attached to the call for whatever reason. The AGI script in the dialplan is what causes the attachment, after that other scripts will use the callerID name to manage the call when appropriate, but start with that AGI script in the dialplan at verify that Vicidial is attaching on an example call (ie: one that remains NEW after the call is over).

You should track an individual instance from beginning to end through the Vicidial AGI logs. Turn on logging under Admin->Servers (set to Both) and you can even turn on agi logging in the Vicidial Console for direct tracing of the call's progress.

williamconly, blackbird2306

Thanks for taking the time to help me,

I created a list with a number that I know is disconnect (tested with my cellphone)

I followed the call using asterirsk -vvvvvr agi set debug on and this is the result :

Code: Select all

[Jan  8 06:46:56]     -- Executing [64504684312@default:4] Dial("Local/64504684312@default-000006ab;2", "SIP/sogetel/4504684312,,tTor") in new stack
[Jan  8 06:46:56]   == Using SIP RTP CoS mark 5
[Jan  8 06:46:56]     -- Called SIP/sogetel/4504684312
[Jan  8 06:46:57]   == Everyone is busy/congested at this time (1:0/0/1)
[Jan  8 06:46:57]     -- Executing [64504684312@default:5] Hangup("Local/64504684312@default-000006ab;2", "") in new stack
[Jan  8 06:46:57]   == Spawn extension (default, 64504684312, 5) exited non-zero on 'Local/64504684312@default-000006ab;2'
[Jan  8 06:46:57]     -- Executing [h@default:1] AGI("Local/64504684312@default-000006ab;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----1-----CHANUNAVAIL----------") in new stack
[Jan  8 06:46:57] AGI Tx >> agi_network: yes
[Jan  8 06:46:57] AGI Tx >> agi_network_script: call_log--HVcauses--PRI-----NODEBUG-----1-----CHANUNAVAIL----------
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_request: agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----1-----CHANUNAVAIL----------
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_channel: Local/64504684312@default-000006ab;2
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_language: en
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_type: Local
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_uniqueid: 1515412016.4433
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_version: 11.25.1-vici
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_callerid: 8193074448
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_calleridname: 8193074448
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_callingpres: 0
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_callingani2: 0
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_callington: 0
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_callingtns: 0
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_dnid: unknown
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_rdnis: unknown
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_context: default
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_extension: h
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_priority: 1
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_enhanced: 0.0
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_accountcode:
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> agi_threadid: 139851881273088
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >>
[Jan  8 06:46:57]     -- <Local/64504684312@default-000006ab;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----1-----CHANUNAVAIL---------- completed, returning 0
[Jan  8 06:46:57] <Local/64504684312@default-000006ab;2>AGI Tx >> HANGUP


Same problem as usual, the lead is disposed as NEW in the list.

First time I look at a agi debug but from what I understand the provider is returning a CHANUNAVAIL when I hit a disconnect number ? That would not make sense in my situation, using the same provider and trunk on an older vicidial box the lead is correctly disposed...

I will try calling the same number on the older box (who always worked with that SIP provider) and see what happen in the agi debug. Until then if you see something I don't in this debug please let me know

Have a look in /var/log/astguiclient and find out what happened. Debug mode may be needed. Logging may require "FILE" or "BOTH". You may even need to start the screen that generates the output in --debugX mode for testing. Good for you that you can reproduce the error, that's most of the battle.

Verify that your asterisk version in admin->servers matches the asterisk version returned with "asterisk -V". Note that "11" is not sufficient, it must be 11.something.

I can confirm my asumption with problem "callerid(name)" is correct. Your problem is definitely the wrong dialplan!! I made the test by myself and status won't change. Change your dialplan like I said before in my post. By the way I'v seen you are calling to Canada and somehow there is the only place, where callerid name has an effect at called party. So take a look at "agi-CANADA_PRI_CIDname.agi" and loopback dialplan (there are many posts about this topic), but just after solving your actual problem

blackbird2306 wrote:I can confirm my asumption with problem "callerid(name)" is correct. Your problem is definitely the wrong dialplan!! I made the test by myself and status won't change. Change your dialplan like I said before in my post. By the way I'v seen you are calling to Canada and somehow there is the only place, where callerid name has an effect at called party. So take a look at "agi-CANADA_PRI_CIDname.agi" and loopback dialplan (there are many posts about this topic), but just after solving your actual problem

certainly a valid experiment. if you require callerid name in canada, use the loopback dialplan method. it generates more cpu load, but it allows setting caller id name. very useful in canada.

blackbird2306,

Turn out you were 100% right.

The first line of my calling plan was the issue and making the changes that you proposed solved everything.

Thanks you and thank you williamconley for taking the time to help me on this issue.