Filter for Cisco CUBE

[MattMou]

I can see various filters have been written for other systems, Avaya SM, Sonos etc. Would there be any appetite to write one for syslog SIP debug output from a Cisco CUBE?

I raised the question on the Homer Google group and was suggested to post the question here.

Thanks

[lmangani]

We can't comment unless you attach an example - please do so and we'll happily take a look.

[MattMou]

Many thanks for offering to take a look.

I have produced a quick edited debug of a complete call: https://pastebin.com/Y6bqhcvd

Let me know if this provides enough detail.

[lmangani]

Thanks. The messages can be easily parsed, but those logs are pretty useless as they don't specify who's the sender or receiver of any of those SIP messages - extracting those form the signaling is a recipe for disaster. So - Not much we can do with those unless there's a higher debug level.

[MattMou]

Can you give me a steer on what the format needs to be so I can look into what other debugs are available?

When you say "extracting those form the signaling" do you mean the invite/from/to etc?

[lmangani]

In order to turn those logs back into HEP/SIP at the very least we need to know the source/destination IP:PORT of each packet. The traffic doesn't look like its TLS or anything, so why would you want to capture this way?

[MattMou]

The output is the SIP messages that the CUBE exchanges during a call. The example is UDP. Obviously there is no RTP as part of it. If there is a problem you can use the debug to work out what device sent what messages. Cisco have a tool that you can drop that debug into and it arranges it by time stamp, shows the individual messages and produces ladder diagrams. Normally we troubleshoot by reproducing an issue and capturing the debug to look at. It would be nice to have something that is just gathering the debug all the time so we can just go back and look. I was under the impression that it was just a flow of standard SIP messages so I thought this was something that Homer would be able to work with.

[lmangani]

@MattMou perhaps I confused you. homer can work with this just fine, you saw the other log processors converting output back to HEP/SIP but unfortunately for you the CUBE logs don't tell much as of where the messages came/went from a networking perspective so its pretty useless. This said, you can extract the IPs (if there are any) from the FROM/VIA/RURI if you want to and HOMER will display them as they are sent.

[astrakid]

i have also need for this, have not that much knowledge but would like to participate.

[lmangani]

@astrakid thanks! Perhaps you know if the logs have options or can be extended to be more verbose in any way about the sessions they handle, perhaps a DEBUG level?

[astrakid]

no, unfortunately there is no more detailed log level enabled - it is already debug mode.

[lmangani]

This is unfortunate indeed - we can't do this through logs without the network details. How about ERSPAN?

[astrakid]

Cisco doesn't provide that. But we could use the IP addresses of the sip headers (at least for my case it would be really sufficient at a first glance, and rtp is not available in his scenario for homer at all).

Regards Andre

[lmangani]

You absolutely can from a technical standpoint but besides being misleading in case of proxies, what happens when you have a domain name? ;)

[astrakid]

Good point as always. ;-) For my case it is not relevant. It is anyway not the perfect solution because rtp is missing, so I think we can leave with this limitations and have to document it.

[MattMou]

From my point of view the most common use for the Cisco CUBE is to sit between an ITSP and a PBX. You are talking about an exchange between few IP addresses and it is very rare to find domain names used. Cisco provide a tool to parse the log files (as the above example) and it is able to build the call flow. I understand the RTP will give you more but really the SIP messages is what I would use to do initial troubleshooting. 90% of the time we have to turn on debugging and ask the customer to recreate the problem then download the debug and look at it or use the Cisco tool. It would be much easier to have something like Homer where you can lookup all calls and see "oh we got SIP 404 because the customer made a typo on the dialed number". If you can make it work with the debug from Cisco then I think the uptake could be massive. I have configured a port mirror from my CUBE and used heplify to push to Homer, this works great but in an enterprise customers are hesitant about configuring port mirrors and you need to get the 'network guy' rather than just the 'telephony guy' to get things working.

[pierok13]

I did some work on that, I need to push it on git once I'm sure it works as intended and I've made some documentations/comments. I also made one for audiocodes SBC.

[lmangani]

thanks @pierok13 are those implemented as pastash filters?

[pierok13]

thanks @pierok13 are those implemented as pastash filters?

yes, sir

[lmangani]

That;s great! Would love to help out @pierok13 feel free to send a PR to the /plugins folder and we'll publish it

[MattMou]

I did some work on that, I need to push it on git once I'm sure it works as intended and I've made some documentations/comments. I also made one for audiocodes SBC.

Excited to give this a try! Many thanks for your efforts.

[shag12]

I was unable to run this filter. Syslog from Cisco on an input arrives. Pastash generates the following logs, apparently for each line from the syslog:

[Thu, 08 Dec 2022 14:09:07 GMT] ERROR TypeError: Cannot read property '1' of null at FilterAppCisco.process (/usr/local/lib/node_modules/@pastash/filter_app_cisco/filter_app_cisco.js:143:29) at FilterAppCisco. (/usr/local/lib/node_modules/@pastash/pastash/lib/lib/base_filter.js:21:24) at FilterAppCisco.emit (events.js:314:20) at FilterMultiline. (/usr/local/lib/node_modules/@pastash/pastash/lib/agent.js:260:14) at FilterMultiline.emit (events.js:314:20) at FilterMultiline.BaseFilterBuffer.sendMessage (/usr/local/lib/node_modules/@pastash/pastash/lib/lib/base_filter_buffer.js:56:8) at FilterMultiline. (/usr/local/lib/node_modules/@pastash/pastash/lib/lib/base_filter_buffer.js:42:14) at listOnTimeout (internal/timers.js:554:17) at processTimers (internal/timers.js:497:7)