Hi,
Can someone help me in understanding if we can still listen to AMI events from a newer Asterisk Version on the older Asterisk versions? Is AMI backward compatible?
For example, I can’t listen to AMI events from Asterisk 18 on my Asterisk 1.8.9 version. I see subscribe and notify packets being sent out but there is no response.
Any degree of help would be greatly appreciated 
On Wednesday 20 November 2024 at 07:18:09, hishamjan via Asterisk Community
wrote:
Hi,
Can someone help me in understanding if we can still listen to AMI events
from a newer Asterisk Version on the older Asterisk versions? Is AMI
backward compatible?For example, I can’t listen to AMI events from Asterisk 18 on my Asterisk
1.8.9 version. I see subscribe and notify packets being sent out but there
is no response.
I don’t understand how (or why) you would be trying to get Asterisk itself to
listen to AMI events on another Asterisk server.
Asterisk provides an AMI interface for scripts and external applications to
interact with it (watch events wihch Asterisk generates, send commands to tell
Asterisk to do something).
What do you mean by using Asterisk itself to listen to another server’s AMI
port?
Antony.
–
RTFM may be the appropriate reply, but please specify exactly which FM to R.
Please reply to the list;
please *don't* CC me.
Hi, @Pooh
actually, i have a BLF panel that shows the extension status of people registered on different PBXs which are upgraded to Asterisk 18.22, but, the main BLF panel resides on the server which is old; 1.8.9 version.
I see that latest asterisk servers show the BLF status correctly to each other, but the one on 1.8.9 isn’t recognizing the latest servers’ status…
i hope i made sense…
I think the OP isn’t talking about AMI at all, but about remote presence.
I wasn’t aware that Asterisk had had remote presence over SIP added to any version, although I seem to remember another protocol being partially supported (XMPP).
On Wednesday 20 November 2024 at 10:50:22, hishamjan via Asterisk Community
wrote:
I have a BLF panel that shows the extension status of people registered on
different PBXs which are upgraded to Asterisk 18.22, but, the main BLF panel
resides on the server which is old; 1.8.9 version.
Aha, so you have some application which displays BLF status, and this happens
to be running on one of your rather old Asterisk servers, but it is fetching
status from both that server and others.
So, it is not Asterisk itself which is fetching the AMI data. Good to clarify
that.
what is this BLF application? Is it something well-known such as FOP2, or
is it something you or your companmy have developed independently?
has this application ever displayed correct status for endpoints on
Asterisk 1.8? If it’s a commercial application, does it claim to support such
an old version?
can you do a packet capture on port 5038 on the Asterisk 1.8 server (AMI is
a plain-text protocol, so simple to read for a human) to see whether the
application is connecting without errors, and whether Asterisk 1.8 is sending
any status data?
Antony.
–
“Can you keep a secret?”
“Well, I shouldn’t really tell you this, but… no.”
Please reply to the list;
please *don't* CC me.
okay, so the answeres are as below:
the BLF application is an in-house developed program that works on the URL: https://serverIP/PBX/panel. All the panel PHP files are placed in the /var/www/html/panel directory.
Yes, when the other PBXs were on the older version, i.e, 1.8.9, the BLF displayed and captured AMI events from them to show live status of the extensions happening elsewhere
ss attached:
Screen shots are difficult for us to use and this one just shows that there is some AMI activity, but not what it is.
I believe to have hints from multiple Asterisk instances, you need Distributed Device State, so I’d suggest looking at the various subordinate topics and see if you can identify which ones you are using, and try and debug by comparing configurations.
On Wednesday 20 November 2024 at 17:10:58, david551 via Asterisk Community
wrote:
Screen shots are difficult for us to use
Indeed - and they don’t even come through at all for those of us who interact
with this forum in email mailing-list mode.
Copy-and-pasted text is always preferable to screenshots:
So, everyone who reads this (not just the OP of this thread), please copy and
paste text, don’t use screenshots unless you’re really trying to show
graphics.
Antony.
–
Software development can be quick, high quality, or low cost.
The customer gets to pick any two out of three.
Please reply to the list;
please *don't* CC me.
I apologize for pasting screesnhots, but it’s not something i can copy and paste directly as it involves graphics and for the AMI Logs, i can just attach the file to it, but with that, I cannot redact the sensitive info which I can when pasting a screenshot/picture.
Can you tell me a workaround for this?
Hi @david551
I am not sure about the DDS. I’ll have to look it up but what I know for a fact is, when all servers were on the same software stack, Asterisk, PHP etc, they were all communicating fine through AMI events. But after upgrading some servers to the (almost) latest stack, the server on the old/outdated software stack fails to communicate properly.
On Wednesday 20 November 2024 at 18:06:19, hishamjan via Asterisk Community
wrote:
I apologize for pasting screesnhots, but it’s not something i can copy and
paste directly as it involves graphics
In that case, no need to apologise - if what you need to show is not plain
text, then so be it - a screenshot is the only way.
and for the AMI Logs, i can just attach the file to it, but with that, I
cannot redact the sensitive info
Why not? You copy the text, paste it into a file, edit out the sensitive info,
and post the result…
Antony.
–
Success is a lousy teacher. It seduces smart people into thinking they can’t
lose.
William H Gates III
Please reply to the list;
please *don't* CC me.
okay, here is the file attached.
amicapture.txt (469.0 KB)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.