gpt4 book ai didi

mysql - 如何通过 Asterisk 1.8.5 中的 cdr_adaptive_odbc.so 模块启用 CDR 日志记录?

转载 作者:行者123 更新时间:2023-11-29 14:44:26 25 4
gpt4 key购买 nike

我在运行

  • 带有 CEL 和 CDR 的 Asterisk 1.8.5
  • ODBC(连接到 MySQL)。

CEL 工作正常(见下文),但 CDR 无法通过自适应 ODBC 工作。 (顺便说一句,标准 ODBC 和直接 MySQL 写入可用于 CDR。)

Asterisk 可以找到 CEL 的正确表和列。亲自看看:

dev-lt-tk1*CLI> core set verbose 99
Verbosity is at least 99

dev-lt-tk1*CLI> module reload cel_odbc.so
-- Reloading module 'cel_odbc.so' (ODBC CEL backend)
== Parsing '/opt/gemeinschaft/etc/asterisk/cel_odbc.conf': == Found
-- Found CEL table cel@odbc-voipstat101.
> Found id column with type 4 with len 10, octetlen 10, and numlen (0,10)
> Found eventtype column with type 12 with len 30, octetlen 30, and numlen (0,0)
> Found eventtime column with type 93 with len 19, octetlen 19, and numlen (0,10)
> Found userdeftype column with type 12 with len 255, octetlen 255, and numlen (0,0)
> Found cid_name column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found cid_num column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found cid_ani column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found cid_rdnis column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found cid_dnid column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found exten column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found context column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found channame column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found appname column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found appdata column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found accountcode column with type 12 with len 20, octetlen 20, and numlen (0,0)
> Found peeraccount column with type 12 with len 20, octetlen 20, and numlen (0,0)
> Found uniqueid column with type 12 with len 150, octetlen 150, and numlen (0,0)
> Found linkedid column with type 12 with len 150, octetlen 150, and numlen (0,0)
> Found amaflags column with type 4 with len 10, octetlen 10, and numlen (0,10)
> Found userfield column with type 12 with len 255, octetlen 255, and numlen (0,0)
> Found peer column with type 12 with len 80, octetlen 80, and numlen (0,0)

这是我的 CEL 表结构:

mysql> describe cel;
+-------------+--------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+-------------------+-----------------------------+
| id | int(30) | NO | PRI | NULL | auto_increment |
| eventtype | varchar(30) | NO | | NULL | |
| eventtime | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| userdeftype | varchar(255) | NO | | NULL | |
| cid_name | varchar(80) | NO | | NULL | |
| cid_num | varchar(80) | NO | | NULL | |
| cid_ani | varchar(80) | NO | | NULL | |
| cid_rdnis | varchar(80) | NO | | NULL | |
| cid_dnid | varchar(80) | NO | | NULL | |
| exten | varchar(80) | NO | | NULL | |
| context | varchar(80) | NO | | NULL | |
| channame | varchar(80) | NO | | NULL | |
| appname | varchar(80) | NO | | NULL | |
| appdata | varchar(80) | NO | | NULL | |
| accountcode | varchar(20) | NO | | NULL | |
| peeraccount | varchar(20) | NO | | NULL | |
| uniqueid | varchar(150) | NO | | NULL | |
| linkedid | varchar(150) | NO | | NULL | |
| amaflags | int(11) | NO | | NULL | |
| userfield | varchar(255) | NO | | NULL | |
| peer | varchar(80) | NO | | NULL | |
+-------------+--------------+------+-----+-------------------+-----------------------------+
21 rows in set (0.00 sec)

问题:

现在,当我使用 cdr_adaptive_odbc 时,加载模块时会得到这些奇怪的结果。列类型无法与 SQL 列类型匹配。

dev-lt-tk1*CLI> module reload cdr_adaptive_odbc.so 
-- Reloading module 'cdr_adaptive_odbc.so' (Adaptive ODBC CDR backend)
== Parsing '/opt/gemeinschaft/etc/asterisk/cdr_adaptive_odbc.conf': == Found
-- Found adaptive CDR table ast_cdr@odbc-voipstat101.
> Found _id column with type 4 with len 10, octetlen 10, and numlen (0,10)
> Found calldate column with type 93 with len 19, octetlen 19, and numlen (0,10)
> Found uniqueid column with type -9 with len 32, octetlen 32, and numlen (0,0)
> Found clid column with type -9 with len 80, octetlen 240, and numlen (0,0)
> Found src column with type -9 with len 30, octetlen 30, and numlen (0,0)
> Found dst column with type -9 with len 30, octetlen 30, and numlen (0,0)
> Found dcontext column with type -9 with len 50, octetlen 50, and numlen (0,0)
> Found channel column with type -9 with len 60, octetlen 60, and numlen (0,0)
> Found dstchannel column with type -9 with len 60, octetlen 60, and numlen (0,0)
> Found lastapp column with type -9 with len 30, octetlen 30, and numlen (0,0)
> Found lastdata column with type -9 with len 80, octetlen 80, and numlen (0,0)
> Found duration column with type 4 with len 8, octetlen 8, and numlen (0,10)
> Found billsec column with type 4 with len 8, octetlen 8, and numlen (0,10)
> Found disposition column with type -9 with len 15, octetlen 15, and numlen (0,0)
> Found amaflags column with type -6 with len 3, octetlen 3, and numlen (0,10)
> Found accountcode column with type -9 with len 25, octetlen 25, and numlen (0,0)
> Found userfield column with type -9 with len 255, octetlen 255, and numlen (0,0)
> Found sequence column with type -8 with len 32, octetlen 32, and numlen (0,0)
> Found linkedid column with type -8 with len 32, octetlen 32, and numlen (0,0)

这是我们的 CDR 表结构:

mysql> describe ast_cdr;
+-------------+-----------------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+-----------------------+------+-----+-------------------+----------------+
| _id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| calldate | timestamp | NO | MUL | CURRENT_TIMESTAMP | |
| uniqueid | varchar(32) | NO | MUL | NULL | |
| clid | varchar(80) | NO | | | |
| src | varchar(30) | NO | MUL | | |
| dst | varchar(30) | NO | MUL | | |
| dcontext | varchar(50) | NO | | | |
| channel | varchar(60) | NO | | | |
| dstchannel | varchar(60) | NO | | | |
| lastapp | varchar(30) | NO | | | |
| lastdata | varchar(80) | NO | | | |
| duration | mediumint(8) unsigned | NO | | 0 | |
| billsec | mediumint(8) unsigned | NO | | 0 | |
| disposition | varchar(15) | NO | | | |
| amaflags | tinyint(3) unsigned | NO | | 0 | |
| accountcode | varchar(25) | NO | MUL | | |
| userfield | varchar(255) | NO | | | |
| sequence | char(32) | YES | | NULL | |
| linkedid | char(32) | YES | | NULL | |
+-------------+-----------------------+------+-----+-------------------+----------------+
19 rows in set (0.00 sec)

有人知道为什么会发生这种情况吗?我研究了 cel_odbc.c 和 cdr_adaptive_odbc.c 源代码,它们似乎大量复制粘贴。

最佳答案

现在 CDR 自适应 ODBC 正在运行!我必须删除 SQL 表中的所有字符集:

这是旧表:

CREATE TABLE `ast_cdr` (
`_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`calldate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`uniqueid` varchar(32) NOT NULL,
`clid` varchar(80) NOT NULL DEFAULT '',
`src` varchar(30) NOT NULL DEFAULT '',
`dst` varchar(30) NOT NULL DEFAULT '',
`dcontext` varchar(50) NOT NULL DEFAULT '',
`channel` varchar(60) NOT NULL DEFAULT '',
`dstchannel` varchar(60) NOT NULL DEFAULT '',
`lastapp` varchar(30) NOT NULL DEFAULT '',
`lastdata` varchar(80) NOT NULL DEFAULT '',
`duration` mediumint(8) unsigned NOT NULL DEFAULT '0',
`billsec` mediumint(8) unsigned NOT NULL DEFAULT '0',
`disposition` varchar(15) NOT NULL DEFAULT '',
`amaflags` int(3) unsigned NOT NULL DEFAULT '0',
`accountcode` varchar(25) NOT NULL DEFAULT '',
`userfield` varchar(255) NOT NULL DEFAULT '',
`sequence` char(32) DEFAULT NULL,
`linkedid` char(32) DEFAULT NULL,
PRIMARY KEY (`_id`),
KEY `calldate` (`calldate`),
KEY `accountcode` (`accountcode`),
KEY `src_disposition` (`src`(25),`disposition`(4)),
KEY `dst_disposition` (`dst`(25),`disposition`(4)),
KEY `uniqueid` (`uniqueid`(25))
) ENGINE=MyISAM AUTO_INCREMENT=2973 DEFAULT CHARSET=latin1

这是新表:

CREATE TABLE `ast_cdr` (
`_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`calldate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`uniqueid` varchar(32) NOT NULL,
`clid` varchar(80)NOT NULL DEFAULT '',
`src` varchar(30) NOT NULL DEFAULT '',
`dst` varchar(30) NOT NULL DEFAULT '',
`dcontext` varchar(50) NOT NULL DEFAULT '',
`channel` varchar(60) NOT NULL DEFAULT '',
`dstchannel` varchar(60) NOT NULL DEFAULT '',
`lastapp` varchar(30) NOT NULL DEFAULT '',
`lastdata` varchar(80) NOT NULL DEFAULT '',
`duration` mediumint(8) unsigned NOT NULL DEFAULT '0',
`billsec` mediumint(8) unsigned NOT NULL DEFAULT '0',
`disposition` varchar(15) NOT NULL DEFAULT '',
`amaflags` tinyint(3) unsigned NOT NULL DEFAULT '0',
`accountcode` varchar(25) NOT NULL DEFAULT '',
`userfield` varchar(255) NOT NULL DEFAULT '',
`sequence` char(32) DEFAULT NULL,
`linkedid` char(32) DEFAULT NULL,
PRIMARY KEY (`_id`),
KEY `calldate` (`calldate`),
KEY `accountcode` (`accountcode`),
KEY `src_disposition` (`src`(25),`disposition`(4)),
KEY `dst_disposition` (`dst`(25),`disposition`(4)),
KEY `uniqueid` (`uniqueid`(25))
) ENGINE=MyISAM AUTO_INCREMENT=2971;

以下是重要的差异(感谢 #asterisk 上的 wdoekes2):

kleine@mrburns:~/Desktop$ diff -u original.sql new.sql 
--- original.sql 2011-09-02 13:52:55.931004844 +0200
+++ new.sql 2011-09-02 13:53:03.501015948 +0200
@@ -2,7 +2,7 @@
`_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`calldate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`uniqueid` varchar(32) NOT NULL,
- `clid` varchar(80)NOT NULL DEFAULT '',
+ `clid` varchar(80) NOT NULL DEFAULT '',
`src` varchar(30) NOT NULL DEFAULT '',
`dst` varchar(30) NOT NULL DEFAULT '',
`dcontext` varchar(50) NOT NULL DEFAULT '',
@@ -13,7 +13,7 @@
`duration` mediumint(8) unsigned NOT NULL DEFAULT '0',
`billsec` mediumint(8) unsigned NOT NULL DEFAULT '0',
`disposition` varchar(15) NOT NULL DEFAULT '',
- `amaflags` tinyint(3) unsigned NOT NULL DEFAULT '0',
+ `amaflags` int(3) unsigned NOT NULL DEFAULT '0',
`accountcode` varchar(25) NOT NULL DEFAULT '',
`userfield` varchar(255) NOT NULL DEFAULT '',
`sequence` char(32) DEFAULT NULL,
@@ -24,4 +24,4 @@
KEY `src_disposition` (`src`(25),`disposition`(4)),
KEY `dst_disposition` (`dst`(25),`disposition`(4)),
KEY `uniqueid` (`uniqueid`(25))
- ) ENGINE=MyISAM AUTO_INCREMENT=2971;
+ ) ENGINE=MyISAM AUTO_INCREMENT=2973 DEFAULT CHARSET=latin1

现在,重新加载 CDR 自适应 ODBC 模块即可工作:

dev-lt-tk1*CLI> module reload cdr_adaptive_odbc.so
-- Reloading module 'cdr_adaptive_odbc.so' (Adaptive ODBC CDR backend)
== Parsing '/opt/gemeinschaft/etc/asterisk/cdr_adaptive_odbc.conf': == Found
-- Found adaptive CDR table ast_cdr@odbc-voipstat101.
> Found _id column with type 4 with len 10, octetlen 10, and numlen (0,10)
> Found calldate column with type 93 with len 19, octetlen 19, and numlen (0,10)
> Found uniqueid column with type 12 with len 32, octetlen 32, and numlen (0,0)
> Found clid column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found src column with type 12 with len 30, octetlen 30, and numlen (0,0)
> Found dst column with type 12 with len 30, octetlen 30, and numlen (0,0)
> Found dcontext column with type 12 with len 50, octetlen 50, and numlen (0,0)
> Found channel column with type 12 with len 60, octetlen 60, and numlen (0,0)
> Found dstchannel column with type 12 with len 60, octetlen 60, and numlen (0,0)
> Found lastapp column with type 12 with len 30, octetlen 30, and numlen (0,0)
> Found lastdata column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found duration column with type 4 with len 8, octetlen 8, and numlen (0,10)
> Found billsec column with type 4 with len 8, octetlen 8, and numlen (0,10)
> Found disposition column with type 12 with len 15, octetlen 15, and numlen (0,0)
> Found amaflags column with type 4 with len 10, octetlen 10, and numlen (0,10)
> Found accountcode column with type 12 with len 25, octetlen 25, and numlen (0,0)
> Found userfield column with type 12 with len 255, octetlen 255, and numlen (0,0)
> Found sequence column with type 1 with len 32, octetlen 32, and numlen (0,0)
> Found linkedid column with type 1 with len 32, octetlen 32, and numlen (0,0)

关于mysql - 如何通过 Asterisk 1.8.5 中的 cdr_adaptive_odbc.so 模块启用 CDR 日志记录?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7282075/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com