Call Status

QueueMetrics > Running QueueMetrics

Call Status

<< < (3/4) > >>

QueueMetrics:
Yes the database is populated via qloaderd (I guess) but qloaderd does not create records. So I guess they come from somewhere else.....

gopal2k:
Hi,

We explored little bit and found Asterisk is populating data correctly. For example, a particular record is updated in CEL table, where CEL table has detailed information about a call.

Let's consider the following example from queue_log table,
mysql> select * from queue_log where call_id ='1375644053.1307271';
+-----------+---------------------+------------+--------------------+-----------+-----------+----------------+-------+--------------------+-------+-------+-------+----------+------------------+
| partition | EntryTime | time_id | call_id | queue | agent | verb | data1 | data2 | data3 | data4 | data5 | serverid | unique_row_count |
+-----------+---------------------+------------+--------------------+-----------+-----------+----------------+-------+--------------------+-------+-------+-------+----------+------------------+
| P001 | 2013-08-04 12:38:06 | 1375645085 | 1375644053.1307271 | NONE | SIP/10857 | CALLSTATUS | dc | | | | | | 2 |
| P001 | 2013-08-04 12:33:41 | 1375644060 | 1375644053.1307271 | XSS_SALES | SIP/10857 | COMPLETEAGENT | 1 | 5 | | | | | 1 |
| P001 | 2013-08-04 12:41:34 | 1375645293 | 1375644053.1307271 | XSS_SALES | SIP/10857 | COMPLETECALLER | 1 | 1238 | 1 | | | | 2 |
| P001 | 2013-08-04 12:20:55 | 1375644055 | 1375644053.1307271 | XSS_SALES | SIP/10857 | CONNECT | 1 | 1375644054.1307273 | 0 | | | | 1 |
| P001 | 2013-08-04 12:20:55 | 1375644054 | 1375644053.1307271 | XSS_SALES | NONE | ENTERQUEUE | | 7135763000 | 1 | | | | 1 |
+-----------+---------------------+------------+--------------------+-----------+-----------+----------------+-------+--------------------+-------+-------+-------+----------+------------------+
5 rows in set (0.03 sec)

and for the same unique ID, if we see in the CEL table,
mysql> select * from cel where uniqueid like '1375644053.1307271%' or linkedid like '1375644053.1307271%';
+----------+--------------+---------------------+-------------+------------+------------+------------+-----------+------------+------------+---------------+--------------------+----------+----------------------------------------------+----------+-------------+-------------+--------------------+--------------------+-----------+--------------------+
| id | eventtype | eventtime | userdeftype | cid_name | cid_num | cid_ani | cid_rdnis | cid_dnid | exten | context | channame | appname | appdata | amaflags | accountcode | peeraccount | uniqueid | linkedid | userfield | peer |
+----------+--------------+---------------------+-------------+------------+------------+------------+-----------+------------+------------+---------------+--------------------+----------+----------------------------------------------+----------+-------------+-------------+--------------------+--------------------+-----------+--------------------+
| 32798068 | CHAN_START | 2013-08-04 12:20:53 | | HOUSTON TX | 7135763000 | | | | 5108242149 | trunk-inbound | SIP/US-000b6368 | | | 3 | | | 1375644053.1307271 | 1375644053.1307271 | | |
| 32798069 | ANSWER | 2013-08-04 12:20:53 | | HOUSTON TX | 7135763000 | 7135763000 | | 5108242149 | 5108242149 | project | SIP/US-000b6368 | Answer | | 3 | | | 1375644053.1307271 | 1375644053.1307271 | | |
| 32798078 | CHAN_START | 2013-08-04 12:20:54 | | ComCast | 5108242149 | | | | s | xss-call-out | SIP/10857-000b636a | | | 3 | 10857 | 10857 | 1375644054.1307273 | 1375644053.1307271 | | |
| 32798079 | ANSWER | 2013-08-04 12:20:54 | | ComCast | 5108242149 | 5108242149 | | | 5108242149 | xss-call-out | SIP/10857-000b636a | AppQueue | (Outgoing Line) | 3 | 10857 | 10857 | 1375644054.1307273 | 1375644053.1307271 | | |
| 32798082 | BRIDGE_START | 2013-08-04 12:20:55 | | HOUSTON TX | 7135763000 | 7135763000 | | 5108242149 | 5108242149 | project | SIP/US-000b6368 | Queue | XSS_SALES,t,,,3600,queue_log.agi,macro(beep) | 3 | | | 1375644053.1307271 | 1375644053.1307271 | | SIP/10857-000b636a |
| 32803212 | BRIDGE_END | 2013-08-04 12:41:33 | | HOUSTON TX | 7135763000 | 7135763000 | | 5108242149 | 5108242149 | project | SIP/US-000b6368 | Queue | XSS_SALES,t,,,3600,queue_log.agi,macro(beep) | 3 | | | 1375644053.1307271 | 1375644053.1307271 | | SIP/10857-000b636a |
| 32803213 | HANGUP | 2013-08-04 12:41:33 | | ComCast | 5108242149 | 5108242149 | | | 5108242149 | xss-call-out | SIP/10857-000b636a | AppQueue | (Outgoing Line) | 3 | | | 1375644054.1307273 | 1375644053.1307271 | | |
| 32803214 | CHAN_END | 2013-08-04 12:41:33 | | ComCast | 5108242149 | 5108242149 | | | 5108242149 | xss-call-out | SIP/10857-000b636a | AppQueue | (Outgoing Line) | 3 | | | 1375644054.1307273 | 1375644053.1307271 | | |
| 32803215 | HANGUP | 2013-08-04 12:41:33 | | HOUSTON TX | 7135763000 | 7135763000 | | 5108242149 | 5108242149 | project | SIP/US-000b6368 | | | 3 | | | 1375644053.1307271 | 1375644053.1307271 | | |
| 32803216 | CHAN_END | 2013-08-04 12:41:33 | | HOUSTON TX | 7135763000 | 7135763000 | | 5108242149 | 5108242149 | project | SIP/US-000b6368 | | | 3 | | | 1375644053.1307271 | 1375644053.1307271 | | |
| 32803217 | LINKEDID_END | 2013-08-04 12:41:33 | | HOUSTON TX | 7135763000 | 7135763000 | | 5108242149 | 5108242149 | project | SIP/US-000b6368 | | | 3 | | | 1375644053.1307271 | 1375644053.1307271 | | |
+----------+--------------+---------------------+-------------+------------+------------+------------+-----------+------------+------------+---------------+--------------------+----------+----------------------------------------------+----------+-------------+-------------+--------------------+--------------------+-----------+--------------------+
11 rows in set (54.81 sec)

In the above said example, 'COMPLETECALLER ' date is properly updated in CEL table as "BRIDGE_END", so this states that Asterisk is pushing data fine.

Any other way that we can find out, whether qloaderd is getting any input and that is getting pushed to database? because queue_log file is also fine there is no COMPLETEAGENT, whereas in DB both resides.

Thanks in advance.

Regards

QueueMetrics:
I would be looking at the queue_log file versus the queue_log table on the database.

gopal2k:
One more example I have,

Following is the Queuelog file,
Caller Disconnected
1384520637|1384520630.119824|TEST|NONE|ENTERQUEUE||1008|1
1384520637|1384520630.119824|TEST|SIP/1007|CONNECT|0|1384520637.119825|0
1384520660|1384520630.119824|TEST|SIP/1007|COMPLETECALLER|0|23|1

Agent Disconnected
1384520675|1384520669.119826|TEST|NONE|ENTERQUEUE||1008|1
1384520676|1384520669.119826|TEST|SIP/1007|CONNECT|1|1384520675.119827|0
1384520682|1384520669.119826|TEST|SIP/1007|COMPLETECALLER|1|6|1

And below is the queue_log table,
mysql> select * from queue_log where call_id = '1384520669.119826';
+-----------+------------+-------------------+-------+----------+----------------+-------+-------------------+-------+-------+-------+----------+------------------+
| partition | time_id | call_id | queue | agent | verb | data1 | data2 | data3 | data4 | data5 | serverid | unique_row_count |
+-----------+------------+-------------------+-------+----------+----------------+-------+-------------------+-------+-------+-------+----------+------------------+
| P001 | 1384520675 | 1384520669.119826 | TEST | NONE | ENTERQUEUE | | 1008 | 1 | | | | 1 |
| P001 | 1384520676 | 1384520669.119826 | TEST | SIP/1007 | CONNECT | 1 | 1384520675.119827 | 0 | | | | 1 |
| P001 | 1384520682 | 1384520669.119826 | TEST | SIP/1007 | COMPLETECALLER | 1 | 6 | 1 | | | | 1 |
+-----------+------------+-------------------+-------+----------+----------------+-------+-------------------+-------+-------+-------+----------+------------------+
3 rows in set (2.90 sec)

mysql> select * from queue_log where call_id = '1384520630.119824';
+-----------+------------+-------------------+-------+----------+----------------+-------+-------------------+-------+-------+-------+----------+------------------+
| partition | time_id | call_id | queue | agent | verb | data1 | data2 | data3 | data4 | data5 | serverid | unique_row_count |
+-----------+------------+-------------------+-------+----------+----------------+-------+-------------------+-------+-------+-------+----------+------------------+
| P001 | 1384520637 | 1384520630.119824 | TEST | NONE | ENTERQUEUE | | 1008 | 1 | | | | 1 |
| P001 | 1384520637 | 1384520630.119824 | TEST | SIP/1007 | CONNECT | 0 | 1384520637.119825 | 0 | | | | 2 |
| P001 | 1384520660 | 1384520630.119824 | TEST | SIP/1007 | COMPLETECALLER | 0 | 23 | 1 | | | | 1 |
+-----------+------------+-------------------+-------+----------+----------------+-------+-------------------+-------+-------+-------+----------+------------------+
3 rows in set (1.28 sec)

And FYI: the calls are inbound calls... while checking in extensions_queuemetrics.conf file I see the COMPLETESTATUS is mentioned only for outbound call context. Will this be applicable for Inbound call as well?

Thanks.

QueueMetrics:
Looks like Asterisk is tracking all your calls as COMPLETECALLER.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version