VICIDIAL doesn't hang up sometimes

[Wintermute]

I've done a scratch install of VICIDIAL and it seems to run okay. Currently there are only two agents using the system.

The VICIDIAL version is 2.0.2 and Asterisk is 1.2.13. Running on an Athlon 64 3000+ processor, nVidia chipset and 2 Gb of RAM. Four HFC-S cards are being used to connect to the ISDN (BRI) net, but only one card is actually connectet to the ISDN net (Due to the lack of lines.). Locally we are using pure SIP clients (ALaw).

Zaptel Version is 1.2.9.1.

Load average is about 0.10

But it seems that reportings are not working correctly and sometimes the the dialer doesn't hang up.

Hopper Level is at 10, and the dialer is set to manual dialing.


From the asterisk*CLI:

Code: Select all

    -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
    -- Executing SetCallerPres("Local/8600051@SIP-6677,1", "prohib") in new stack
    -- Executing Set("Local/8600051@SIP-6677,1", "DYNAMIC_FEATURES=automon") in new stack
    -- Executing Dial("Local/8600051@SIP-6677,1", "Zap/g5/030XXXXXXX|55|WT") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called g5/030XXXXXXX
    -- Zap/1-1 is proceeding passing it to Local/8600051@SIP-6677,1
    -- Channel 0/1, span 1 got hangup request
    -- Channel 0/1, span 1 received AOC-E charging 0 units
Jan 29 18:44:55 WARNING[27103]: app_dial.c:733 wait_for_answer: Unable to forward voice
    -- Hungup 'Zap/1-1'
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing Hangup("Local/8600051@SIP-6677,1", "") in new stack
  == Spawn extension (SIP, 9030XXXXXXX, 5) exited non-zero on 'Local/8600051@SIP-6677,1'
    -- Executing DeadAGI("Local/8600051@SIP-6677,1", "agi://127.0.0.1:4577/call_log") in new stack

ASTfastlog seems to die sometimes.

Code: Select all

asterisk ~ # screen -r
There are several suitable screens on:
        4628.ASTupdate  (Detached)
        4630.ASTsend    (Detached)
        4632.ASTlisten  (Detached)
        4634.ASTVDauto  (Detached)
        4636.ASTVDremote        (Detached)
        4638.ASTVDadapt (Detached)
        4583.ASTfastlog (Dead ???)
        4650.ASTfastlog (Dead ???)
        4640.ASTfastlog (Attached)
Remove dead screens with 'screen -wipe'.
Type "screen [-d] -r [pid.]tty.host" to resume one of them.

The dial extension in /etc/asterisk/extensions.conf:

Code: Select all

exten => _9X.,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _9X.,n,SetCallerPres(prohib)
exten => _9X.,n,Set(DYNAMIC_FEATURES=automon)
exten => _9X.,n,Dial(${TRUNK5}/${EXTEN:1},55,WT)
exten => _9X.,n,Hangup()

Some more errors from the asterisk*CLI i get:

Code: Select all

  == Spawn extension (SIP, 90554XXXXXXX, 5) exited non-zero on 'Local/8600051@SIP-a5fc,1'

Code: Select all

Jan 29 17:12:30 WARNING[4295]: chan_zap.c:8461 pri_fixup_principle: Call specified, but not found?

Code: Select all

Jan 29 17:50:55 WARNING[10482]: app_meetme.c:1555 conf_run: Unable to write frame to channel: Success
Jan 29 17:50:55 WARNING[10482]: app_meetme.c:1555 conf_run: Unable to write frame to channel: Success
Jan 29 17:50:55 WARNING[10482]: app_meetme.c:1555 conf_run: Unable to write frame to channel: Success
Jan 29 17:50:55 WARNING[10482]: app_meetme.c:1555 conf_run: Unable to write frame to channel: Success
Jan 29 17:50:55 WARNING[10482]: app_meetme.c:1555 conf_run: Unable to write frame to channel: Success
Jan 29 17:50:55 WARNING[10482]: app_meetme.c:1555 conf_run: Unable to write frame to channel: Success
Jan 29 17:50:55 WARNING[10482]: app_meetme.c:1555 conf_run: Unable to write frame to channel: Success
.....

Whats wrong?

Regards
Henrik

[mflorell]

I don't really have any experience with BRI circuits, and I don't know what these two lines do:
exten => _9X.,n,SetCallerPres(prohib)
exten => _9X.,n,Set(DYNAMIC_FEATURES=automon)

Have you tried just using a SIP or IAX termination provider to make sure everything is running properly so you know if it is VICIDIAL that is causing the probelms?

Also, 1.2.14 is more stable than 1.2.13. You should upgrade if possible.

[Wintermute]

I don't really have any experience with BRI circuits, and I don't know what these two lines do:
exten => _9X.,n,SetCallerPres(prohib)
exten => _9X.,n,Set(DYNAMIC_FEATURES=automon)

The "SetCallerPres" function changes presentation for the callerid. It is commen practice in Germany to supress the caller id for any call center.

The next line enables the automon feature, which is used for on demand voice recordings.

Have you tried just using a SIP or IAX termination provider to make sure everything is running properly so you know if it is VICIDIAL that is causing the probelms?

Since the server is not connected to the internet (mainly for security reasons) a SIP or IAX termination provider is not an option. But i tested the _9X. extension manually, but i didn't encountered any problems.

Also, 1.2.14 is more stable than 1.2.13. You should upgrade if possible.

This seems to be the last option. But it doesn't explain, why the reportings don't work..

In VDAD REPORT i see no call times and

Code: Select all

Warning:  Division by zero in /var/www/localhost/htdocs/vicidial/AST_VDADstats.php on line 262

Full output:

Code: Select all

VICIDIAL: Auto-dial Stats                             2007-01-30 18:33:16

---------- TOTALS
Total Calls placed from this Campaign:                 7
Average Call Length for all Calls in seconds:          1

---------- DROPS
Total DROP Calls:                                      0  0%
Percent of DROP Calls taken out of Answers:            0 / 0  0%
Average Length for DROP Calls in seconds:              0

---------- AUTO-DIAL NO ANSWERS
Total NA calls -Busy,Disconnect,RingNoAnswer:          7  100%
Average Call Length for NA Calls in seconds:           1

---------- AGENT STATS
+--------------------------+------------+----------+--------+
| AGENT                    | CALLS      | TIME M   | AVRG M |
+--------------------------+------------+----------+--------+


Warning:  Division by zero in /var/www/localhost/htdocs/vicidial/AST_VDADstats.php on line 262

+--------------------------+------------+----------+--------+
| TOTAL Agents:          0 |          0 |     0:00 |   0:00 |
+--------------------------+------------+----------+--------+
| Average Wait time between calls                      0:00 |
+-----------------------------------------------------------+

---------- TIME STATS


GRAPH IN 15 MINUTE INCREMENTS OF TOTAL CALLS PLACED FROM THIS CAMPAIGN
+------+-------------------------------------------------------------------------------------------------------+-------+-------+
| HOUR |0     0     0     1     1     1     1     1     1     2     2     2     2     2     3     3     3     3| DROPS | TOTAL |
+------+-------------------------------------------------------------------------------------------------------+-------+-------+
|   15 |***********************************X                                                                   | 0     | 1     |
|   30 |                                                                                                       | 0     |
|   45 |                                                                                                       | 0     |
|+1500+|                                                                                                       | 0     |
|   15 |******************************************************************************************************X| 0     | 3     |
|   30 |                                                                                                       | 0     |
|   45 |                                                                                                       | 0     |
|+1600+|***********************************X                                                                   | 0     | 1     |
|   15 |                                                                                                       | 0     |
|   30 |                                                                                                       | 0     |
|   45 |********************************************************************X                                  | 0     | 2     |
+------+-------------------------------------------------------------------------------------------------------+-------+-------+

Same in Agent Performance Detail

Code: Select all

VICIDIAL: Agent Performance Detail                        2007-01-30 18:36:40
Time range: 2007-01-30 15:15:00 to 2007-01-30 23:15:00

---------- AGENTS Details -------------

+-----------------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+------+------+------+------+------+------+------+------+
| USER NAME       | ID     | CALLS  | TIME   | PAUSE  | PAUSAVG| WAIT   | WAITAVG| TALK   | TALKAVG| DISPO  | DISPAVG| A    | B    | DC   | DNC  | N    | NI   | CB   | SALE |
+-----------------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+------+------+------+------+------+------+------+------+
| Christian XXXXX | 103    | 245    |    0:00|   0:00 |   0:00 |   0:00 |   0:00 |   0:00 |   0:00 |   0:00 |   0:00 | 38   | 2    | 3    | 9    | 171  | 3    | 0    | 0    |
| Ercan XXXX      | 102    | 239    |    0:00|   0:00 |   0:00 |   0:00 |   0:00 |   0:00 |   0:00 |   0:00 |   0:00 | 26   | 1    | 0    | 5    | 188  | 1    | 1    | 0    |
+-----------------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+------+------+------+------+------+------+------+------+
|  TOTALS                  | 484    |    0:00|    0:00|   0:00 |    0:00|   0:00 |    0:00|   0:00 |    0:00|   0:00 | 64   | 3    | 3    | 14   | 359  | 4    | 1    |      |
+--------------------------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+------+------+------+------+------+------+------+------+

Regards
Henrik

[mflorell]

I haven't seen that problem before for an outbound call center. What dial level are you dialing at?

Are there records in the vicidial_log table that appear to be for this campaign for this day?

[Wintermute]

I haven't seen that problem before for an outbound call center. What dial level are you dialing at?

As mentioned above, we are still in manual dialing mode. Hopper Level is at 10.

Are there records in the vicidial_log table that appear to be for this campaign for this day?

Well, sort of. According to the astGUIclient FAQ i'd to alter the primary key and the index. As far as i can see, there are only records in the vicidial_log table which are in the status 'B'.

Code: Select all

+-------------------------------+---------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+--------------+------+----------+-----------+
| uniqueid                      | lead_id | list_id | campaign_id | call_date           | start_epoch | end_epoch  | length_in_sec | status | phone_code | phone_number | user | comments | processed |
+-------------------------------+---------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+--------------+------+----------+-----------+
| asterisk-4265-1170163743.3015 |    5708 |    NULL | VERSA       | 2007-01-30 14:29:06 |  1170163746 | 1170163747 |             1 | B      | 030        | XXXXXXXX     | VDAD | NULL     | N         |
| asterisk-4265-1170166855.3583 |    5766 |    NULL | VERSA       | 2007-01-30 15:20:59 |  1170166859 | 1170166860 |             1 | B      | 030        | XXXXXXXX     | VDAD | NULL     | N         |
| asterisk-4265-1170166848.3579 |    5772 |    NULL | VERSA       | 2007-01-30 15:21:21 |  1170166881 | 1170166882 |             1 | B      | 030        | XXXXXXXX     | VDAD | NULL     | N         |
| asterisk-4265-1170167150.3647 |    3145 |    NULL | VERSA       | 2007-01-30 15:26:30 |  1170167190 | 1170167191 |             1 | B      | 0          | XXXXXXXX     | VDAD | NULL     | N         |
| asterisk-4265-1170169854.4183 |    5708 |    NULL | VERSA       | 2007-01-30 16:10:57 |  1170169857 | 1170169858 |             1 | B      | 030        | XXXXXXXX     | VDAD | NULL     | N         |
| asterisk-4265-1170172230.4592 |    5945 |    NULL | VERSA       | 2007-01-30 16:50:38 |  1170172238 | 1170172239 |             1 | B      | 030        | XXXXXXXX     | VDAD | NULL     | N         |
| asterisk-4265-1170172243.4596 |    5944 |    NULL | VERSA       | 2007-01-30 16:50:58 |  1170172258 | 1170172259 |             1 | B      | 030        | XXXXXXXX     | VDAD | NULL     | N         |
| asterisk-4265-1170179440.5594 |    6027 |    NULL | VERSA       | 2007-01-30 18:51:39 |  1170179499 | 1170179500 |             1 | B      | 030        | XXXXXXXX     | VDAD | NULL     | N         |
+-------------------------------+---------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+--------------+------+----------+-----------+
8 rows in set (0.00 sec)


But there are also some good news..
It seems, that the hang up problem is solved. (In a way.) According to this thread the "soft hangup" command helps hanging up properly. So i changed my dialout extension accordingly.

Code: Select all

exten => _9X.,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _9X.,n,SoftHangup(${TRUNK5})
exten => _9X.,n,SetCallerPres(prohib)
exten => _9X.,n,Set(DYNAMIC_FEATURES=automon)
exten => _9X.,n,Dial(${TRUNK5}/${EXTEN:1},25,WT)
exten => _9X.,n,SoftHangup(${TRUNK5})
exten => _9X.,n,Hangup()

Regards
Henrik

[mflorell]

So you're not running Asterisk 1.2.13, your running the BRIstuff fork?

Can you see if there are any errors in your asterisk table of MySQL(look for the .err file in your mysql data directory)?

[Wintermute]

So you're not running Asterisk 1.2.13, your running the BRIstuff fork?

I patched libpri, zaptel and asterisk with the BRIstuff patches initiated by Junghanns. This is unfortunatly mandatory for the HFC-S cards.

Can you see if there are any errors in your asterisk table of MySQL(look for the .err file in your mysql data directory)?

Checked the logs, and there is one warning every time the database starts.

Code: Select all

070201 14:14:18 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=asterisk-bin' to avoid this problem.

Regards
Henrik

[enjay]

I was having these hangup issues as well 1.2.14 appears to have resolved them..

[Wintermute]

I was having these hangup issues as well 1.2.14 appears to have resolved them..

Thats a valuable information. I've just upgraded to version 1.2.14. Its 8 PM now, and we'll see tomorrow, if the behavior has changed.

Thanks again!

Regards
Henrik

[Wintermute]

I was having these hangup issues as well 1.2.14 appears to have resolved them..

Well... The Upgrade didn't help.
I'm still having these hangup problems.

Code: Select all

Feb  5 15:00:24 WARNING[27796]: app_dial.c:733 wait_for_answer: Unable to forward voice
Feb  5 15:00:25 WARNING[26403]: chan_zap.c:8485 pri_fixup_principle: Call specified, but not found?

Code: Select all

asterisk*CLI> show channels
Channel              Location             State   Application(Data)             
Zap/1-1              s@ISDN:1             Ringing AppDial((Outgoing Line))     
Local/8600052@SIP-a4 8600052@SIP:1        Up      MeetMe(8600052)               
Local/8600052@SIP-a4 903050184662@SIP:5   Up      Dial(Zap/g5/030XXXXXXXX|25|WT)
Zap/pseudo-166863842 s@ISDN:1             Rsrvd   (None)                       
SIP/102-081addf8     8600052@SIP:1        Up      MeetMe(8600052)               
Zap/pseudo-182635211 s@ISDN:1             Rsrvd   (None)                       
SIP/103-08193578     8600051@SIP:1        Up      MeetMe(8600051)               
7 active channels
4 active calls

This one is new:

Code: Select all

Feb  5 15:02:23 WARNING[26403]: chan_zap.c:8552 zt_pri_error: 1 updating callstate, peercallstate 8 to 11
Feb  5 15:02:36 ERROR[28704]: chan_zap.c:2773 zt_hangup: What is wrong with you? You cannot use cause 1 number when in state 6!


What does that mean?

Regards
Henrik

[mflorell]

I can't say that I know what that error is. I have dozens of US PRI circuits and I've never seen that one. Does BRIstuff have a forum or some other kind of support available?