Filter for Cisco CUBE about pastash HOT 21 OPEN

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.

from pastash.

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.

from pastash.

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

from pastash.

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.

from pastash.

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.

from pastash.

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?

from pastash.

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?

from pastash.

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.

from pastash.

@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.

from pastash.

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

from pastash.

@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?

from pastash.

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

from pastash.

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

from pastash.

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

from pastash.

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

from pastash.

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.

from pastash.

thanks @pierok13 are those implemented as pastash filters?

from pastash.

thanks @pierok13 are those implemented as pastash filters?

yes, sir

from pastash.

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

from pastash.

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.

from pastash.

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)

from pastash.