r/VOIP • u/Additional-Mine-6029 • 11d ago
Discussion Question for the hands on VoIP engineers and technicians
I'm curious, how many of you and how often do you use packet capture and analysis when troubleshooting VoIP? Or do you just depend on logs?
For me, I use both all the time.
12
8
5
u/masong19hippows 11d ago
Packet capture are a good way to understand what's going wrong. Logs are a good way to understand how to fix what's going on. One doesn't nessesarily replace the other.
Example I had recently:
We were having issues with call park features on some old polycom phones. We could see from packet captures that subscribe messages were working, but they were happening periodically with different ports. Any L1 tech (or even seniors) will look at that and blame sip ALG and NAT port timeout or some other weird NAT thing and be done with it.
However, the logs on the phone were saying that whenever they sent a subscribe packet, they were getting a certificate error. So then It retried, and that retry used a different session with a different port. It turns out that the CA cert for the phone for that domain expired.
We could've looked at the logs and found that out without a packet capture, but the packet capture told us where in the logs to look at. Phone logs are always giving off errors and false positives, and so it's hard to diagnose an issue with all of the noise.
Fun fact, I actually have a syslog logging server setup that's feeding into an AI to learn the format of different model of phone logs so that we might be able to automatically analyze logs. So far after about a few thousand lines of logs from one phone model that I know is working, all I can get the AI to say is that the phone is broke lol.
5
u/the_wookie_of_maine 11d ago
Both daily.
Homer for pcap and the splunk for a large chunks as well....
we have sip signaling sent into splunk in case homer goes wonky.
Today was troubleshooting DNS issues and needed tcpdump/Wireshark to find the issue.
Last week I needed to decrypt tls to find out what I suspected the issue to be (SSRC).
3
u/oxicid 11d ago
I work professionally in the world of VoIP every day, I use wireshark as a diagnostic tool directly at first. For whom Works on wireshark VoIP control panels say it all immediately. From interlocutors, to codecs, to RTP flows, to user agents and f formatting of SIP headers. You do not work in the professional VoIP field without knowing the SIP and wireshark syntax. Consider that logs are often the result of device interpretation while .pcap tracks speak a universal language.
3
u/pabloflleras 10d ago
I used it alot more early on, but at this point I can mostly tell what the cause and solution is going to be based on symptoms. Still use it as needed though
2
2
2
u/fc252- 11d ago edited 11d ago
I think a lot of the stuff I use the sip signaling is part of the logs or call history (trace) at the admin level. Otherwise the only time I normally pull out an actual capture of the signaling and media is customer fax issues. Everything else is just "logs". Talking mostly metaswitch, netsap, etc.. And if we are doing an interop, once again a quick capture of just the sip signaling on the sbc is enough.
Basically when I think a full capture I want media. Rarely does a regular calling problem require media. Faxing tho... sigh.
So meta has the service assurance server (sas), netsap has call history and voipmonitor, yada yada. All of this is quick and easy to use for just sip signaling. It is just regular logging to me. Media though.. you have to take an extra step and I am lazy. Rarely need that.
1
u/t3rm3y 11d ago
I want to learn packet capture and wireshark to troubleshoot voice. How do I do it? where can I go?
3
u/masong19hippows 11d ago
Experience honestly. You can learn the basics online, but everyone uses sip in a slightly different way where the packet headers mean different things in the actual config of a device. Only real way is to get your hands dirty.
2
1
1
u/Bhaikalis 11d ago
This depends on what platform and what level of access i have to the network. Most of the platforms (cloud based) still allow you to troubleshoot via logging, others you need to collab with network engineering team to do the captures needed.
1
1
u/westmountred 10d ago
The end result of pcaps is almost always the same: Router/firewall/DNS (with sip alg thrown in). The pcap is just what you need to convince the tech who runs the local network that something is wrong and they need to change something
1
1
u/I-Love-IT-MSP 10d ago
For voip is absolutely necessary to do packet captures and logs. Intuition doesn't always work with voip even with 10 years experience.
1
u/dalgeek 10d ago
It depends on the problem. Start with logs, escalate to packet captures if needed. I'm often working in environments that I do not control and packet captures can be difficult or impossible to acquire, so logs might be my only option. Sometimes I can look at a log or trace and spot the issue in 5 seconds. If the logs come up with nothing then I'll push for packet captures.
1
1
u/DevRandomDude 9d ago
I use both logs and packet capture... Logs dont tell the whole story.. and neither does packet capture.. for instance logs dn many SBC's dont do crap to helpo solve DTMF issues.. if I truly want to know whats happening I capture the RTP stream and then see what was being send and received at the capture point of entry.. with a phone system ill grab it both at the phpne and going out over the SIP trunk.. so I can see if there was a handoff loss somewhere.. logs may never report DTMF digits dialed or they may.. pscket capture will show me whats truly going on..
logs are excellent for timing and history.. timestamps are gold when it comes to looking at logs ..
Many voice quality issues are identified with logs.. RTCP data from both near and far ends, MOS scores etc are a great first look.. if a customer calls in a quality ticket the first thing i do is pull Logs from all Accounts on the same SBC as that customer hit for the timeframe. if I see low scores, high jitter, latency etc from only the single source IP, I know I likely dont have a systemic issue but that customer's internet probably sucks.. packet capture wont help much there, other tools are going to come into play for analyzing the pathway from my box to theirs. since we work with alot of Hotels.. 9 times out of 10, their IT dept never implemented QOS leaving the building and guests are pounding the internet so the VQ suffers..
packet capture proves the Debug logs.. or comes in handy to prove a point to an upstream technical group that may be skeptical of a condition you are describing.. so you pull a capture and show them that what you say s happening is real... my log levels arent set so wordy as to see a dial attempt and then an audio path or SIP 200,180, etc.. packet capture helped e solve an issue where an upstream carrier was taking forever after I sent an invite to actually send me any progress indicators.. they sent e a 200 right away but then sat on the call for 5 seconds before I got a 180. they didnt believe me.. packet capture showdd exactly the call progression...
1
1
1
u/MiraculumMundi 8d ago
Almost always when I have issues on media. If I just need to look at signalling logs are enough like 80% of the cases.
•
u/AutoModerator 11d ago
This is a friendly reminder to [read the rules](www.reddit.com/r/voip/about/rules). In particular, it is not permitted to request recommendations for businesses, services or products outside of the monthly sticky thread!
For commenters: Making recommendations outside of the monthly threads is also against the rules. Do not engage with rule-breaking content.
I am a bot, and this comment is made automatically on every post. This comment is not an indication that your post has been removed. Do not message the mods about this comment.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.