Is it possible to get a log Call-ID (printed as [C-000XXXX] in full log) for the AMI event field LinkedID (like LinkedID: 1627888706.379)? I think there should be a one-2-one correspondence between the two. The idea is to filter log lines for a single call. Asterisk 11.
If you write dialplan to do so, yes. You could use NoOp and the CHANNEL dialplan function[1] to output the linkedid - although it could change later. I don’t know if linkedid works in 11 though, as it’s not documented for there - so it might not.
[1] Asterisk 18 Function_CHANNEL - Asterisk Project - Asterisk Project Wiki
jcolp, thank you for directing me to Function_CHANNEL. It does indeed document the necessary arguments - linkedid & callid. That is the very pair I need. The documentation is for Asterisk 18 though, so NoOp(${CHANNEL(callid)}) gives me an empty string in Asterisk 11.
But when I execute “>core show channel XXX” it dumps the line “Call Identifer: [C-000000ee]” in a " – PBX --" section. So the info is somewhere around. How/where from may I pull this into a dialplan?
Another option I guess is to execute “core show channel” in AMI while the channel is still alive and parse the output? But I’m worried this output might be highly inconsistent between Asterisk versions too.
Asterisk 11 is too old for my knowledge.
I think you should also explain what you’re trying to achieve, because based on your two posts now I’m kind of confused over what exactly you want to achieve.
I’m building an AMI application to present a user with a real-time call progress. You know, Alice calls external party, then transfers it to Bob, Bob’s device redirects it to Charlie, he DTMFs back to Alice and the like. Wanna have a nice graph with statuses and progress edges. Comprehending all those channel masquerades drives me crazy. Seems AMI events are just not enough. Seems there is more info in log. So I want to look into full log for that particular LinkedID(s). Not real-time perhaps, for debugging only. For that I needa map LinkIDs that AMI gives me to CallIDs in fulllog. Or is there a better way around?
Asterisk 12 and above completely altered things in that regard. I don’t remember 11 stuff.
Really doubt about ‘completely altered’. I read an article about Ast12+ channels. Channels do merge and blend, just the other way. BTW, haven’t you seen somebodies’ effort in what I am trying to accomplish? Something like real-time call progress map? Just can’t find anything to get inspiration from…
No, it really did completely alter things and simplify the perspective of how channels are connected both internally and from an AMI perspective. In fact masquerades became an internal implementation detail which is rarely, if ever, exposed publicly.
If I saw anything applicable to 11 or below, that knowledge is long gone.
There is a time machine - git checkout 11.24.1 and you are there. If you know what is where in a source tree.
I know how to get the source code, but the fundamental knowledge of how everything is put together and what the events are like and how to track things are a different story.
Someone else may have that knowledge still, I do not.
To create a dashboard of real time call progress gets messy as you start dealing with transfers, it becomes what you called (drives me crazy.) situation for a programmer.
Also you need to start thinking in terms of channels and not in terms of calls, all events are related to channels, the concept of a “call” inside asterisk only appears at the CDR stage which is too late for a real time dashboard, the uniqueid and linkedid values are still related to channels even though asterisk will use the very first uniqueid in a call as the callid in the CDR.
I believe the best way this could be solved is to query asterisk for the state of calls (because Asterisk internally does hold a very accurate call state table) and use that in combination with the events.
Yes, you are of course right. A ‘call’ is a human concept, and the trick is to translate channel manipulations to human-understandable actions. An example below involves five parties but is a result of a cooperation of nine channels. Here Original Caller initially dials 402/404/405/408 simultaneously, 408 answers, then performs an attended transfer to 405 via dtmf. It is the very moment of a completion of a transfer in a picture.
It seems like the bigger challenge is that every distinct asterisk function manipulates channels in its own way. So you have to train a dashboard to recognize known masquerade patterns to grasp what is going on.
Your proposal to query asterisk sounds promising, especially in its ‘very accurate call state table’ part. What do you mean by query - some CLI commands? Could you please elaborate on that further?
I am still looking into it, in the meantime my dashboard has a function that deletes obsolete/incorrect channel information after a timeout so when a transfer happens
This is the table I was talking about.
serv1*CLI> core show channels verbose
Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgeID
PJSIP/inbound4-000002be from-inbound-to-serv s 4 Up Queue accueil,tTwk,18000 33111111111 00:06:02 a0b41592-a271-436f-8
PJSIP/1009-000002c2 from-agent s 1 Up AppQueue (Outgoing Line) 3123456666 00:04:23 a0b41592-a271-436f-8
2 active channels
1 of 200 max active call ( 0.50% of capacity)
116 calls processed
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.