Dear All,
I am using Asterisk 16.4.0 and SIP trunk.
While dialing in bulk using AMI interface, CDRs posting is getting delayed significantly.
Also, time in the CDR’s start, end and answer field is not getting reflected correctly(i.e. it is taking delayed time).
Kindly suggest what could be the issue and how same can be fixed.
Regards,
Dinesh
Asterisk CLI and dial plan used for the dialing would be helpful and some CDR sample with the wrong info
Agreed on sanitized CDR samples.
There is also batch=yes option in /etc/asterisk/cdr.conf configuration file to help with slow backend CDR processing.
Dear Ambiorix,
Thank you for sharing your feedback on this issue.
I apologize for being late in sharing details. Kindly see the attached CDR having wrong duration( larger than actual call duration) and wrong start time, end and answer time.
These CDRs were received in the DB very late. This generally happens when I dial number in bulk(50-100k).
I am also attaching my dial plan used for initiating calls using JAVA AMI.
Request your help/suggestion in resolving this issue.
CDR Samples:
| clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | duration | billsec | disposition | amaflags | accountcode | userfield | uniqueid | linkedid | sequence | peeraccount | end | start | answer |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| “” <1725235062> | 1725235062 | 8919001795 | TestCalls | SIP/videocon-000020df | Hangup | 45 | 29 | ANSWERED | 3 | 360^8919001795 | 1562678321 | 1562678321 | 7532 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:48 | ||||
| “” <1725235062> | 1725235062 | 8464023009 | TestCalls | SIP/videocon-000020d3 | Hangup | 46 | 30 | ANSWERED | 3 | 360^8464023009 | 1562678321 | 1562678321 | 7520 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:48 | ||||
| “” <1725235062> | 1725235062 | 8464022877 | TestCalls | SIP/videocon-000020c3 | Hangup | 53 | 36 | ANSWERED | 3 | 360^8464022877 | 1562678321 | 1562678321 | 7504 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:48 | ||||
| “” <1725235062> | 1725235062 | 8184817603 | TestCalls | SIP/videocon-00002047 | Playback | /root/simplePrompt | 60 | 29 | ANSWERED | 3 | 360^8184817603 | 1562678321 | 1562678321 | 7380 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | |||
| “” <1725235062> | 1725235062 | 8919301696 | TestCalls | SIP/videocon-00002088 | Hangup | 60 | 42 | ANSWERED | 3 | 360^8919301696 | 1562678321 | 1562678321 | 7445 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:48 | ||||
| “” <1725235062> | 1725235062 | 9133062856 | TestCalls | SIP/videocon-00002096 | Hangup | 65 | 46 | ANSWERED | 3 | 360^9133062856 | 1562678321 | 1562678321 | 7459 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 8184817995 | TestCalls | SIP/videocon-0000204e | Playback | /root/simplePrompt | 69 | 34 | ANSWERED | 3 | 360^8184817995 | 1562678321 | 1562678321 | 7387 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | |||
| “” <1725235062> | 1725235062 | 8919301694 | TestCalls | SIP/videocon-00002071 | Hangup | 72 | 51 | ANSWERED | 3 | 360^8919301694 | 1562678321 | 1562678321 | 7422 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 8341123535 | TestCalls | SIP/videocon-000020c0 | Hangup | 73 | 52 | ANSWERED | 3 | 360^8341123535 | 1562678321 | 1562678321 | 7501 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 7013210098 | TestCalls | SIP/videocon-00002060 | Hangup | 74 | 49 | ANSWERED | 3 | 360^7013210098 | 1562678321 | 1562678321 | 7405 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 7013210065 | TestCalls | SIP/videocon-0000206b | Hangup | 75 | 48 | ANSWERED | 3 | 360^7013210065 | 1562678321 | 1562678321 | 7416 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 9133060700 | TestCalls | SIP/videocon-00002051 | Playback | /root/simplePrompt | 76 | 37 | ANSWERED | 3 | 360^9133060700 | 1562678321 | 1562678321 | 7390 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | |||
| “” <1725235062> | 1725235062 | 9063300608 | TestCalls | SIP/videocon-0000206c | Hangup | 76 | 48 | ANSWERED | 3 | 360^9063300608 | 1562678321 | 1562678321 | 7417 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 8919197217 | TestCalls | SIP/videocon-000020f1 | Hangup | 75 | 48 | ANSWERED | 3 | 360^8919197217 | 1562678321 | 1562678321 | 7550 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 8919301701 | TestCalls | SIP/videocon-00002073 | Hangup | 76 | 46 | ANSWERED | 3 | 360^8919301701 | 1562678321 | 1562678321 | 7424 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 8919815536 | TestCalls | SIP/videocon-000020bd | Hangup | 76 | 46 | ANSWERED | 3 | 360^8919815536 | 1562678321 | 1562678321 | 7498 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 7660061182 | TestCalls | SIP/videocon-0000205f | Hangup | 76 | 45 | ANSWERED | 3 | 360^7660061182 | 1562678321 | 1562678321 | 7404 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 | ||||
| “” <1725235062> | 1725235062 | 9133061925 | TestCalls | SIP/videocon-00002055 | Hangup | 77 | 44 | ANSWERED | 3 | 360^9133061925 | 1562678321 | 1562678321 | 7394 | 7/9/2019 18:49 | 7/9/2019 18:48 | 7/9/2019 18:49 |
Dial Plan:
[TestCalls]
exten => _XXXXXXXXXX,1,Playback(/root/simplePrompt)
exten => _XXXXXXXXXX,2,Hangup()
Regards,
Dinesh
Thank you for sharing your feedback on this.
Have attached the sample CDRs here for your reference.
Using batch option will further slow down the CDR processing(aggravate my problem).
Requesting your suggestion/help in solving this issue.
Regards,
Dinesh
Your CDR has these 2 fields
Yes, you are right. Billsec will always be greater than duration.
However, here billsec is also larger than the actual call duration(noted on the receiving device and longer than the prompt(playback file) duration).
Also, start time, end time and answer time are wrong and CDR was posted in the DB very late.
Regards,
Dinesh
It sounds like you are overloading the system. I suggest you try it with 5-10 calls at a time and see what happens.
Also that is way too much information in your CDRs as posted – identifying information should be scrubbed/randomized before posting eg. use 5551234, 5551235, 5551236, etc., for clid/src/dst fields. (Although it does look like the context is TestCalls so my apologies in advance if you already cleaned it.)
My requirement is to fully utilize the SIP PRIs attach to the Asterisk box, hence there would be 950 concurrent calls.
I apologize for not posting the sanitize CDR.
Kindly suggest solution if any.
Regards,
Dinesh
What’s as SIP PRI. SIP is VoIP, PRI is circuit switched. They are very different technologies.
I can’t imagine there are many provides who would be happy with 950 simultaneous VoIP calls.
These are VoIP calls, sorry for using a confusing term SIP PRI.
Here, will be using multiple providers. Hence, will be able to generate that 950 simultaneous calls.
Regards,
Dinesh
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.