Display alarm command appears to ignore the field values

[jjschwarz]

I am able to use the fields array in the commands to filter everything so far, except for the display alarms command. If I sent the command string:

[{"acms": ["CM01"],"fields": ["0002ff00", "0004ff00", "0005ff00"],"command": "display alarm"}]

I get back

[{
"acm": "CM01",
"command": "display alarm",
"error": "",
"fields": ["0001ff00", "0002ff00", "0003ff00", "0004ff00", "0005ff00", "000cff00", "000dff00", "4e21ff00", "000eff00", "0006ff00", "0007ff00", "0008ff00", "000fff00", "0009ff00", "000aff00", "000bff00"],
"datas": [
["S000775", "DIG-IP-S", "n", "5428", "WARNING", "OUT", "", "", "06", "14", "17", "20", "00", "00", "00", "00"]
]
}]

I have tried other display commands and they seem to work just fine.

I have also tried the variant:
[{"acms": ["CM01"],"fields": ["0001ff00"],"command": "display alarm"}]
just to test, but I got back the same data set.

Thoughts on what I am missing here?

[53hornet]

Nice find, this appears to be a quirk in Avaya's OSSI protocol. If I bypass Angelshark completely and run this in an OSSI terminal via SAT, I can't control which fields get printed either. It doesn't look like you're missing anything, it appears to be the behavior of the CM.

Unfortunately there isn't a whole lot of documentation on this interface that I could use to warn users of these quirks before hand.

[jjschwarz]

Now the real question become should I even bother to try and open a bug case with Avaya on this.

…

On Jun 15, 2022, at 2:01 PM, Adam Carpenter ***@***.***> wrote: Nice find, this appears to be a quirk in Avaya's OSSI protocol. If I bypass Angelshark completely and run this in an OSSI terminal via SAT, I can't control which fields get printed either. It doesn't look like you're missing anything, it appears to be the behavior of the CM. — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIBX4IXJVGQSVAXCOYCXIDVPILATANCNFSM5Y3IJVOA>. You are receiving this because you authored the thread.

[53hornet]

You bring up a great point. I would bet it all comes down to whose lap your case lands in. Most techs I'd expect would look at your/our custom use of a proprietary, undocumented protocol (OSSI) and just "Close: Unresolved". But maybe there are some who wouldn't.