Asterisk CDR failed: INSERT INTO duplicate entry

Asterisk Asterisk Support
1

I’m using the following in the dialplan to call multiple extensions at the same time.

exten => s,n,Dial(SIP/2580&SIP/2581&SIP/2582,60,rt)

This works as expected but it produces a lot of errors relating to CDR.

[2015-02-08 18:34:40] WARNING[28576]: res_odbc.c:666 ast_odbc_prepare_and_execute: SQL Execute error -1! Verifying connection to asterisk-odbc [asterisk-connector]…
[2015-02-08 18:34:40] WARNING[28576]: res_odbc.c:770 ast_odbc_sanity_check: Connection is down attempting to reconnect…
[2015-02-08 18:34:40] NOTICE[28576]: res_odbc.c:1536 odbc_obj_connect: Connecting asterisk-odbc
[2015-02-08 18:34:40] NOTICE[28576]: res_odbc.c:1568 odbc_obj_connect: res_odbc: Connected to asterisk-odbc [asterisk-connector]
[2015-02-08 18:34:40] WARNING[28576]: res_odbc.c:654 ast_odbc_prepare_and_execute: SQL Execute returned an error -1: 23000: [MySQL][ODBC 5.1 Driver][mysqld-5.1.73]Duplicate entry ‘1423420466.5’ for key ‘uniqueid’ (88)

My question is this expected operation because CDR is trying to report three separate calls all with the same details? or does CDR need further development to handle anomaly’s of this kind?

I suspect we only see this for unanswered calls because once answered the other ringing extensions drop off and thus there is no duplication.

Is there a method of ringing multiple extensions which will not generate this level of CDR error?

Thanks

2

More than one CDR can be created for a channel, so you should not make the unique ID field unique on the database.

3

I think it is unique which is why I’m getting the error messages.

My question is there a better way of ringing multiple handsets and be able to log the calls correctly?

4

Alltough the columnname “uniquid” in the cdr table suggests to be UNIQUE this is not the case whenever unaswered calls should be written into the cdr table.
The solution is quite simple: When unanswered calls (e.g. for ringgroups) should be written, the UNIQUE-Constraint for the column UNIQUEID needs to be dropped. Once the column is not defined as UNIQUE, the error will disappear.

5

does this not just push a problem further down the line when you want to run some reports?

Would it not be better for asterisk to deal with multiple calls properly and provide a separate record for each instance?

Thanks

6

Your problem is that it does, although I would note that, at least at one stage, CDRs were deprecated because it was believed there was no way of making them work in non-trivial dialplans.

7

Yes I got the feeling developers had given up on getting CDR to function as expected and provided CEL for people to build their own billing platforms.

Every other commercial PBX manufacture has managed to achieve a working CDR output although they rely on third party software to log and report on it. Asterisk is having trouble with the output part.

8

The problem for Asterisk is that it provides a PABX toolkit, and the developers can’t predict all the ways in which it can be put together. Other PABXes have a much more fixed structure.

9

my issue here is that the cdr output is not consistent and so is not trusted.

I really don’t see why it is so difficult for asterisk to track when a caller joins a call and when they leave. This is pretty basic stuff

10

Since asterisk is openSource and you said is a beasic stuff you always have the chance to edit the codec, submit the new feature or the “basic behavior” and help other to improve the CDR in asterisk.

In the other hand you have CEL to track almost everything.

11

which either way you jump, it’s built it myself. CDR does not provide a reliable output when there is a bridge involved.

This isn’t CDR as I see it compared to commercial systems like Avaya and Cisco.

That’s my personal view

12

Then use Avaya or Cisco. IMO

13

Or bring asterisk up to standard?

OK gripe over.

14

Asterisk is not the same sort of thing as the commercial PABXes so the standards that apply to those are not directly applicable.

15

Fair comment.