How to limit/filter/avoid irrelevant events outputted via AMI when ringall logic is used

bosida · June 13, 2024, 8:29pm

As I wait for the Sangoma CRM module to be fixed, I’m experimenting with AMI to see if I could pull events from the system and build something basic so I can at least start working on my CRM side of things. I only need to focus on “post call” events (i.e. missed calls, answered calls, voicemail), I do not need any control on ongoing calls.

My inbound numbers are on a ringall strategy. I’ve limited events to Cdr. The extensions in the ring all may not be answering (ie.e. phone not connected) or do so via Sangoma Talk or Desktop. We have no physical phones.

What happens after the call is that I get a record of all extensions that ring as well as the one which answers. I cannot figure out a way to either:

Not have those generated to start with (ie.e. above “asnwered elsewhere”). Perhaps softphones are not compatible?
Or a logic I could implement to ignore irrelevant “events” so that I can be 100% certain to not miss the true event record I need (i.e. I still need a record if a call actually does not get answered by anyone). I hoped I could somehow pull them using the unique ID (i.e. IF multiple events same ID, chose the one with longest duration), but the IDs seem always different (see below 1718305959 and 1718305958).

I have this enabled:

This is an example of output (I took out Source and Called ID which however display consistently and correctly per event):

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 90340
DestinationContext: zulu-call
Channel: Local/90340@zulu-call-00000012;2
DestinationChannel: Local/90340@zulu-desktop-phone-00000013;1
LastApplication: Dial
LastData: Local/90340@zulu-desktop-phone&Local/90340@zulu-mobile-phone-push,15,HhTtrM(aut
StartTime: 2024-06-13 15:12:39
AnswerTime:
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: NO ANSWER
AMAFlags: DOCUMENTATION
UniqueID: 1718305959.101
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 90340
DestinationContext: zulu-call
Channel: Local/90340@zulu-call-00000012;2
DestinationChannel: Local/90340@zulu-mobile-phone-push-00000014;1
LastApplication: Dial
LastData: Local/90340@zulu-desktop-phone&Local/90340@zulu-mobile-phone-push,15,HhTtrM(aut
StartTime: 2024-06-13 15:12:39
AnswerTime:
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: NO ANSWER
AMAFlags: DOCUMENTATION
UniqueID: 1718305959.101
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 90321
DestinationContext: zulu-call
Channel: Local/90321@zulu-call-00000015;2
DestinationChannel: Local/90321@zulu-desktop-phone-00000016;1
LastApplication: Dial
LastData: Local/90321@zulu-desktop-phone&Local/90321@zulu-mobile-phone-push,15,HhTtrM(aut
StartTime: 2024-06-13 15:12:39
AnswerTime:
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: NO ANSWER
AMAFlags: DOCUMENTATION
UniqueID: 1718305959.107
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 90321
DestinationContext: zulu-call
Channel: Local/90321@zulu-call-00000015;2
DestinationChannel: Local/90321@zulu-mobile-phone-push-00000017;1
LastApplication: Dial
LastData: Local/90321@zulu-desktop-phone&Local/90321@zulu-mobile-phone-push,15,HhTtrM(aut
StartTime: 2024-06-13 15:12:39
AnswerTime:
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: NO ANSWER
AMAFlags: DOCUMENTATION
UniqueID: 1718305959.107
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 340
DestinationContext: from-internal
Channel: Local/340@from-queue-0000000c;2
DestinationChannel: Local/90340@zulu-call-00000012;1
LastApplication: Dial
LastData: Local/90340@zulu-call,,HhtrM(auto-blkvm)Ib(func-apply-sipheaders^s^1)
StartTime: 2024-06-13 15:12:39
AnswerTime:
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: FAILED
AMAFlags: DOCUMENTATION
UniqueID: 1718305959.89
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 321
DestinationContext: from-internal
Channel: Local/321@from-queue-00000010;2
DestinationChannel: Local/90321@zulu-call-00000015;1
LastApplication: Dial
LastData: Local/90321@zulu-call,,HhtrM(auto-blkvm)Ib(func-apply-sipheaders^s^1)
StartTime: 2024-06-13 15:12:39
AnswerTime:
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: FAILED
AMAFlags: DOCUMENTATION
UniqueID: 1718305959.97
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 200
DestinationContext: ext-local
Channel: Local/200@from-queue-00000011;2
DestinationChannel: PJSIP/98200-0000003c
LastApplication: Dial
LastData: PJSIP/98200/sip:[email protected]:46108;transport=WS;x-ast-orig-host=klhtuju4u
StartTime: 2024-06-13 15:12:39
AnswerTime:
EndTime: 2024-06-13 15:12:40
Duration: 0
BillableSeconds: 0
Disposition: NO ANSWER
AMAFlags: DOCUMENTATION
UniqueID: 1718305959.99
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 200
DestinationContext: ext-local
Channel: Local/200@from-queue-00000011;2
DestinationChannel: PJSIP/200-0000003d
LastApplication: Dial
LastData: PJSIP/98200/sip:[email protected]:46108;transport=WS;x-ast-orig-host=klhtuju4u
StartTime: 2024-06-13 15:12:39
AnswerTime: 2024-06-13 15:12:41
EndTime: 2024-06-13 15:12:45
Duration: 6
BillableSeconds: 4
Disposition: ANSWERED
AMAFlags: DOCUMENTATION
UniqueID: 1718305959.99
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 3000
DestinationContext: ext-queues
Channel: PJSIP/Twilio_NA_Virginia-0000003b
DestinationChannel: Local/340@from-queue-0000000c;1
LastApplication: Queue
LastData: 3000,tC,,,,,,,,
StartTime: 2024-06-13 15:12:38
AnswerTime: 2024-06-13 15:12:38
EndTime: 2024-06-13 15:12:40
Duration: 2
BillableSeconds: 1
Disposition: FAILED
AMAFlags: DOCUMENTATION
UniqueID: 1718305958.87
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 3000
DestinationContext: ext-queues
Channel: PJSIP/Twilio_NA_Virginia-0000003b
DestinationChannel: Local/310@from-queue-0000000d;1
LastApplication: Queue
LastData: 3000,tC,,,,,,,,
StartTime: 2024-06-13 15:12:39
AnswerTime: 2024-06-13 15:12:39
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: FAILED
AMAFlags: DOCUMENTATION
UniqueID: 1718305958.87
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 3000
DestinationContext: ext-queues
Channel: PJSIP/Twilio_NA_Virginia-0000003b
DestinationChannel: Local/311@from-queue-0000000e;1
LastApplication: Queue
LastData: 3000,tC,,,,,,,,
StartTime: 2024-06-13 15:12:39
AnswerTime: 2024-06-13 15:12:39
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: FAILED
AMAFlags: DOCUMENTATION
UniqueID: 1718305958.87
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 3000
DestinationContext: ext-queues
Channel: PJSIP/Twilio_NA_Virginia-0000003b
DestinationChannel: Local/320@from-queue-0000000f;1
LastApplication: Queue
LastData: 3000,tC,,,,,,,,
StartTime: 2024-06-13 15:12:39
AnswerTime: 2024-06-13 15:12:39
EndTime: 2024-06-13 15:12:39
Duration: 0
BillableSeconds: 0
Disposition: FAILED
AMAFlags: DOCUMENTATION
UniqueID: 1718305958.87
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 3000
DestinationContext: ext-queues
Channel: PJSIP/Twilio_NA_Virginia-0000003b
DestinationChannel: Local/321@from-queue-00000010;1
LastApplication: Queue
LastData: 3000,tC,,,,,,,,
StartTime: 2024-06-13 15:12:39
AnswerTime: 2024-06-13 15:12:39
EndTime: 2024-06-13 15:12:40
Duration: 1
BillableSeconds: 1
Disposition: FAILED
AMAFlags: DOCUMENTATION
UniqueID: 1718305958.87
UserField:

Event: Cdr
Privilege: cdr,all
AccountCode:
Destination: 3000
DestinationContext: ext-queues
Channel: PJSIP/Twilio_NA_Virginia-0000003b
DestinationChannel: Local/200@from-queue-00000011;1
LastApplication: Queue
LastData: 3000,tC,,,,,,,,
StartTime: 2024-06-13 15:12:39
AnswerTime: 2024-06-13 15:12:39
EndTime: 2024-06-13 15:12:45
Duration: 6
BillableSeconds: 6
Disposition: ANSWERED
AMAFlags: DOCUMENTATION
UniqueID: 1718305958.87
UserField:

I did initially try ring groups and currently they are setup as queue. They seem to behave similarly. Any pointer?

penguinpbx · July 11, 2024, 8:13pm

AMI is probably over-kill for post-call processing.

If you populate AccountCode, then you can get separate CDRs eg.:

/var/log/asterisk/cdr-csv/my-special-code-1.csv
/var/log/asterisk/cdr-csv/my-code-2.csv

etc.

Parse those files periodically from cron for ANSWERED lines in your preferred programming language and feed your CRM appropriately.

bosida · July 11, 2024, 9:08pm

Sounds interesting. I’ll need to go through the csv to understand better if it could work for my user case.

I do have accountcode in use, but my /var/log/asterisk/cdr-csv/ (also checked cdr-custom) is empty. Any pointers on how to fix it?

penguinpbx · July 12, 2024, 2:25pm

Oops, that was more generic/stock Asterisk answer regarding CDR CSVs… Are you able to query the “asteriskcdrdb” MySQL database for your CDRs (as that is where FreePBX puts them by default) ?

dicko · July 12, 2024, 5:28pm

You can use as many back-ends as have had their module loaded, csv’s can be hand built , distribvuted config sample :-

github.com

asterisk/asterisk/blob/master/configs/samples/cdr.conf.sample

;
; Asterisk Call Detail Record engine configuration
;
; CDR is Call Detail Record, which provides logging services via a variety of
; pluggable backend modules.  Detailed call information can be recorded to
; databases, files, etc.  Useful for billing, fraud prevention, compliance with
; Sarbanes-Oxley aka The Enron Act, QOS evaluations, and more.
;

[general]

; Define whether or not to use CDR logging.  Setting this to "no" will override
; any loading of backend CDR modules.  Default is "yes".
;enable=yes

; Define whether or not to use CDR logging on new channels by default.
; Setting this to "no" will disable CDR on channels unless it is explicitly
; enabled. Default is "yes".
;channeldefaultenabled=yes

This file has been truncated. show original

so for getting into AMI

github.com

asterisk/asterisk/blob/master/configs/samples/cdr_manager.conf.sample

;
; Asterisk Call Management CDR
;
[general]
enabled = no

; The "mappings" category can be used to define additional "key: value" pairs
; that will be included in the manager event. (after AccountCode, Source, etc).
;
; Each line like "varname => label" will include a "label: ${CDR(varname)}"
; in the generated event where ${CDR(varname)} its replaced with its value
;
;[mappings]
;rate => Rate
;carrier => Carrier

BlazeStudios · July 12, 2024, 6:08pm

Answered Elsewhere is SIP specific and has no bearing on the disposition of the channel or what is stored in the CDRs by default. It it something that is sent in the Reason header as part of the CANCEL SIP message sent to the devices to inform them the call has been canceled.

You’re not going to see it in the CDR events

bosida · July 19, 2024, 6:01pm

Apologies for the delay in response. I have only a sandbox server and I was working w Sangoma to fix a module.

Ref database, I have verified I have access, accessed a sample. I think this is the best method for what I’m trying to achieve. We don’t have high calls volume, so it should be ok nonetheless, but I guess accessing mysql every few seconds would be more efficient that a CSV or gunning out AMI/AGI calls processed just in time?

A question about Incoming calls
Most of my incoming calls go into queues. “dst” shows the queue number (i.e.3000). In “dstchannel” is could parse the extension (i.e. “200” from a record like “Local/200@from-queue-00000017;1”). What would you say is the most efficient way to get the name of the user associated to 200? Another call to the database (which one?) or say an export of user names/extensions every 24h stored elsewhere?

bosida · July 19, 2024, 6:36pm

Yes, makes sense. Looking at the incoming records, I will code it to look at all rows with same linkedid and see if one has ANSWERED disposition.

system · August 19, 2024, 6:36pm

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.