I have an Asterisk 16.6.1 on CentOS6.
I use realtime PJSIP by odbc.
but in Cdr, I use a MySQL directly(not odbc).
Cdr data is saved on MySQL(cdr table).
but start, answer and end column’s data is strange like this!
That’s all same!
MySQL CDR Data
*************************** 3. row ***************************
sequence: 24
accountcode: 9001
src: 0234669000
dst: 01026694023
dcontext: outbound
clid: “9001” <0234669000>
channel: PJSIP/9001-00000018
dstchannel: PJSIP/GATEWAY-00000019
lastapp: Dial
lastdata: PJSIP/01026694023@GATEWAY,45,tTWC
start: 2019-11-01 09:32:39
answer: 2019-11-01 09:32:39
end: 2019-11-01 09:32:39
duration: 21
billsec: 8
disposition: ANSWERED
amaflags: DOCUMENTATION
userfield: NULL
uniqueid: 1572568359.36
linkedid: 1572568359.36
peeraccount: 9001
at Asterisk CLI…
asteriskcti*CLI> cdr show status
Call Detail Record (CDR) settings
Logging: Enabled
Mode: Simple
Log unanswered calls: No
Log congestion: No
- Registered Backends
csv
Adaptive ODBC
cdr_manager (suspended)
cdr-custom
mysql
asteriskctiCLI> cdr set debug on
CDR debugging enabled
asteriskctiCLI>
== Setting global variable ‘SIPDOMAIN’ to ‘hanilnetworks.co.kr’
0x7f40e0000c60 - Created CDR for channel PJSIP/9001-00000018
0x7f40e0000c60 - Transitioning CDR for PJSIP/9001-00000018 from state NONE to Single
– Executing [01026694023@outbound:1] NoOp(“PJSIP/9001-00000018”, “–Cell Phone–”) in new stack
– Executing [01026694023@outbound:2] ExecIf(“PJSIP/9001-00000018”, “0?Set(CHANNEL(accountcode)=“Local”)”) in new stack
– Executing [01026694023@outbound:3] Set(“PJSIP/9001-00000018”, “Account=9001”) in new stack
– Executing [01026694023@outbound:4] NoOp(“PJSIP/9001-00000018”, “CALLERID=,CALLTYPE=,USERFIELD=,GTYPE=”) in new stack
– Executing [01026694023@outbound:5] AGI(“PJSIP/9001-00000018”, “agi://localhost/Gateway.agi?Account=9001&Auth=CELL&CallType=”) in new stack
– <PJSIP/9001-00000018>AGI Script agi://localhost/Gateway.agi?Account=9001&Auth=CELL&CallType= completed, returning 0
– Executing [01026694023@outbound:6] Set(“PJSIP/9001-00000018”, “CALLERID(num)=0234669000”) in new stack
– Executing [01026694023@outbound:7] UserEvent(“PJSIP/9001-00000018”, "UserDial,caller: 9001,callee: 01026694023,callerid: 0234669000,userfield: ,calltype: P,gateway: GATEWAY,gtype: ") in new stack
– Executing [01026694023@outbound:8] Dial(“PJSIP/9001-00000018”, “PJSIP/01026694023@GATEWAY,45,tTWC”) in new stack
0x7f40e0001560 - Created CDR for channel PJSIP/GATEWAY-00000019
0x7f40e0001560 - Transitioning CDR for PJSIP/GATEWAY-00000019 from state NONE to Single
Dial Begin message for PJSIP/9001-00000018, PJSIP/GATEWAY-00000019: 1572568359.00820218
0x7f40e0000c60 - Processing Dial Begin message for channel PJSIP/9001-00000018, peer PJSIP/GATEWAY-00000019
– Called PJSIP/01026694023@GATEWAY
0x7f40e0000c60 - Updated Party A PJSIP/9001-00000018 snapshot
0x7f40e0000c60 - Updated Party B PJSIP/GATEWAY-00000019 snapshot
0x7f40e0000c60 - Transitioning CDR for PJSIP/9001-00000018 from state Single to Dial
– PJSIP/GATEWAY-00000019 is making progress passing it to PJSIP/9001-00000018
> 0x7f413000d0f0 – Strict RTP learning after remote address set to: 175.124.52.7:19538
> 0x7f4130001160 – Strict RTP learning after remote address set to: 19.19.20.181:10042
Dial End message for PJSIP/9001-00000018, PJSIP/GATEWAY-00000019: 1572568362.00245155
– PJSIP/GATEWAY-00000019 is making progress passing it to PJSIP/9001-00000018
Dial End message for PJSIP/9001-00000018, PJSIP/GATEWAY-00000019: 1572568362.00245285
> 0x7f4130001160 – Strict RTP qualifying stream type: audio
> 0x7f4130001160 – Strict RTP switching source address to 110.12.53.87:10042
> 0x7f413000d0f0 – Strict RTP switching to RTP target address 175.124.52.7:19538 as source
asteriskctiCLI>
> 0x7f4130001160 – Strict RTP learning complete - Locking on source address 110.12.53.87:10042
> 0x7f413000d0f0 – Strict RTP learning complete - Locking on source address 175.124.52.7:19538
– PJSIP/GATEWAY-00000019 answered PJSIP/9001-00000018
0x7f40e0001560 - Set answered time to 1572568372.139119
Dial End message for PJSIP/9001-00000018, PJSIP/GATEWAY-00000019: 1572568372.00139425
0x7f40e0000c60 - Processing Dial End message for channel PJSIP/9001-00000018, peer PJSIP/GATEWAY-00000019
0x7f40e0000c60 - Transitioning CDR for PJSIP/9001-00000018 from state Dial to DialedPending
0x7f40e0000c60 - Set answered time to 1572568372.139519
– Channel PJSIP/GATEWAY-00000019 joined ‘simple_bridge’ basic-bridge
Bridge Enter message for channel PJSIP/GATEWAY-00000019: 1572568372.00152865
0x7f40e0001560 - Updating Party A PJSIP/GATEWAY-00000019 snapshot
0x7f40e0001560 - Processing bridge enter for PJSIP/GATEWAY-00000019
0x7f40e0001560 - Transitioning CDR for PJSIP/GATEWAY-00000019 from state Single to Bridged
– Channel PJSIP/9001-00000018 joined ‘simple_bridge’ basic-bridge
Bridge Enter message for channel PJSIP/9001-00000018: 1572568372.00153496
0x7f40e0000c60 - Updating Party A PJSIP/9001-00000018 snapshot
0x7f40e0000c60 - Processing bridge enter for PJSIP/9001-00000018
0x7f40e0000c60 - Transitioning CDR for PJSIP/9001-00000018 from state DialedPending to Dial
0x7f40e0000c60 - Transitioning CDR for PJSIP/9001-00000018 from state Dial to Bridged
asteriskctiCLI>
asteriskcti*CLI>
> 0x7f413000d0f0 – Strict RTP learning after remote address set to: 49.247.203.195:13594
– Channel PJSIP/GATEWAY-00000019 left ‘simple_bridge’ basic-bridge
Bridge Leave message for PJSIP/GATEWAY-00000019: 1572568380.00857118
0x7f40e0001560 - Processing Bridge Leave for PJSIP/GATEWAY-00000019
0x7f40e0001560 - Transitioning CDR for PJSIP/GATEWAY-00000019 from state Bridged to Finalized
– Channel PJSIP/9001-00000018 left ‘simple_bridge’ basic-bridge
0x7f40e0000c60 - Transitioning CDR for PJSIP/9001-00000018 from state Bridged to Finalized
0x7f40e0001560 - Beginning finalize/dispatch for PJSIP/GATEWAY-00000019
0x7f40e0001560 - Dispatching CDR for Party A PJSIP/GATEWAY-00000019, Party B
Bridge Leave message for PJSIP/9001-00000018: 1572568380.00857181
== Spawn extension (outbound, 01026694023, 8) exited non-zero on ‘PJSIP/9001-00000018’
0x7f40e0000c60 - Beginning finalize/dispatch for PJSIP/9001-00000018
0x7f40e0000c60 - Dispatching CDR for Party A PJSIP/9001-00000018, Party B PJSIP/GATEWAY-00000019
And cdr_mysql.conf file
[global]
hostname=localhost
dbname=asterisk16
table=cdr
user=***
password=***
port=3306
sock=/tmp/mysql.sock
; By default CDRs are logged in the system’s time zone
;cdrzone=UTC ; log CDRs with UTC
;usegmtime=yes ;log date/time in GMT. Default is “no”
;cdrzone=America/New_York ; or use a specific time zone
cdrzone=Asia/Seoul
;
; If your system’s locale differs from mysql database character set,
; cdr_mysql can damage non-latin characters in CDR variables. Use this
; option to protect your data.
;charset=koi8r
;charset=utf8
;
; Older versions of cdr_mysql set the calldate field to whenever the
; record was posted, rather than the start date of the call. This flag
; reverts to the old (incorrect) behavior. Note that you’ll also need
; to comment out the “start=calldate” alias, below, to use this.
;compat=no
;
; ssl connections (optional)
;ssl_ca=
;ssl_cert=
;ssl_key=
;
; You may also configure the field names used in the CDR table.
;
[columns]
;static “” =>
;alias =>
alias start => calldate
;alias clid => <a_field_not_named_clid>
;alias src => <a_field_not_named_src>
;alias dst => <a_field_not_named_dst>
;alias dcontext => <a_field_not_named_dcontext>
;alias channel => <a_field_not_named_channel>
;alias dstchannel => <a_field_not_named_dstchannel>
;alias lastapp => <a_field_not_named_lastapp>
;alias lastdata => <a_field_not_named_lastdata>
;alias duration => <a_field_not_named_duration>
;alias billsec => <a_field_not_named_billsec>
;alias disposition => <a_field_not_named_disposition>
;alias amaflags => <a_field_not_named_amaflags>
;alias accountcode => <a_field_not_named_accountcode>
;alias userfield => <a_field_not_named_userfield>
;alias uniqueid => <a_field_not_named_uniqueid>
I don’t know where to check? is there anything I have to do?
or is this asterisk bug?