This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Filtering in VoIP traffic with Wireshark

I want to use a Port Mirroring switch to capture and analyze on a Win10 PC VoIP traffic going to my VoIP phone hooked on the same LAN segment. I attached the phone to port 1 of Netgear GS105E mirroring switch, configured the switch to mirror port 1 to port 2, hooked port 1 of a dual-port network adapter of the PC with Wireshark running to switch port 2 for VoIP capture. Optionally, I hooked port 2 of the adapter to switch port 3 for web browsing, so the web traffic wouldn't interfere with VoIP capture. The switch port 5 WAN is connected to the router.

My problem is, when running Wireshark all day, it collects huge amount of traffic data, and VoIP traffic is a minor share of this entire traffic. It makes it harder and longer to separate and process. Even if traffic from the VoIP phone is mirrored to a dedicated network adapter, there is still fair amount of service traffic passing through it not directly related to VoIP calls.

How do I setup a filter that would capture only RTP and SIP packets directly related to each call, and discard all other traffic through the adapter, including unrelated to calls SIP "keep alive" registration traffic? Its possible, since specialized VoiP Call Monitoring & Recording packages do exactly that, and some (if not all) are based on the same techniques and drivers Wireshark uses.

capture-filter voip

asked 19 Nov '16, 16:06

zamar24
6●3●4●8
accept rate: 0%

edited 20 Nov '16, 07:01

One Answer:

In general, from this point of view, there are two basic categories of traffic:

the one which can be recognized by static scalar values (like IP addresses, ethertype values, TCP or UDP ports). To filter such traffic positively or negatively, you can use a capture filter, and you can use tools which do not maintain context, such as dumpcap or tcpdump, to capture
the one which has to be analysed deeper and within a context (such as RTP whose source and destination ports are changing dynamically, call per call). Only display filter, which depends on existence of context, can be used to filter this category of traffic positively or negatively. Dependence on context means that the capturing application consumes memory and so the amount of traffic it can handle before stalling is limited by the memory available, even if you split the output into several files.

In particular, I would try to find out the following:

does your phone use UDP or TCP (or both) as SIP transport? As you mention REGISTER as "keepalive", it cannot be determined from what you wrote. Periodic re-registrations are not necessarily keepalives, so if more than 5 minutes elapse between REGISTERs, keepalives are either not necessary or done using some other traffic (like UDP packets between the SIP ports but with no actual SIP payload).
the pool of IP addresses your VoIP provider is using for SIP and for RTP. In public VoIP services, it is rare that the RTP would be sent directly between CPEs (VoIP phones) because the CPEs rarely have public IP addresses, so the service provider typically uses a pool of RTP forwarding machines. Also for SIP, there may be a pool, if the provider uses DNS SRV records and other advanced methods. So if you can see that your CPE sends a DNS SRV query and gets a response to it, all the machines to which it may send the REGISTER should be listed in the DNS SRV response. In the response to the REGISTER, there may be a Service-Route header, telling your CPE where to send the initial INVITE; the address may change with each 200 to the REGISTER. Incoming INVITEs will be coming from the address to which the CPE has sent the last REGISTER.

If you cannot determine in advance the whole pool, I would use a capture filter like (host s.s.s.s/24 or r.r.r.r/23) and host p.p.p.p where s.s.s.s is the IP address to/from which the SIP went in the call you've captured manually, r.r.r.r is the IP address to/from which the RTP was going in that call, and p.p.p.p is your phone's IP address. That should filter most of the unwanted traffic away and hopefully still cover at least part of the VoIP provider's farm; you should be able to learn the rest iteratively.

As for filtering out the re-registrations, this is not possible using a capture filter. While a capture filter can recognize the string "REGISTER" in the beginning of TCP or UDP payload, it cannot distinguish the responses to REGISTER because the string "REGISTER" in the CSeq will not be at a fixed offset from the payload beginning. So to get rid of REGISTER traffic, you have to use a display filter !(sip.CSeq.method == "REGISTER") and, therefore, you need to use tshark for capturing, which means the capture cannot run forever. But if you use the capture filter as suggested above, it can run for quite a long time as the context data would grow slowly.

A software dedicated for VoIP monitoring does essentially the same, except that it does not keep any context for other than VoIP traffic, and that it drops any context related to a call which has already ended (which is what tshark/Wireshark apparently doesn't, lacking any notion of a timeout). This alone allows it to run forever, except if there are too many calls which haven't ended correctly.

answered 20 Nov '16, 02:16

sindy
6.0k●4●8●51
accept rate: 24%

@sindy Thanks for the feedback. Will try to follow through and post back here. An obvious question is, if I don't use any display filter on the dedicated LAN adapter that captures only mirrored VoIP traffic, and not connected to the web, will Wireshark run "forever" or hang anyway at some point?

Another Q is, can Wireshark automatically "drop" from memory the calls that were already captured and processed, i.e. manually saved to files by the user at the day end, or it would require to manually restart the capture after saving traffic?

Did you get your Netgear mirroring switch and have a chance to play with it? What is your verdict? Hopefully, you can try to figure out a proper VoIP filter for your own phone calls captured via the mirror, and share it here, of course without private details. :)

(20 Nov '16, 06:49) zamar24

if I don't use any display filter on the dedicated LAN adapter that captures only mirrored VoIP traffic, and not connected to the web, will Wireshark run "forever" or hang anyway at some point?

The tshark/Wireshark dissectors collect context data regardless whether you use display filters or not. So the more you reduce the amount of traffic by disabling all protocols on the capturing port and by using capture filters, the longer tshark or Wireshark will be able to run, but there is currently no way to make it drop the context of already processed VoIP calls, TCP sessions etc.

can Wireshark automatically "drop" from memory the calls that were already captured and processed, i.e. manually saved to files by the user at the day end, or it would require to manually restart the capture after saving traffic?

A manual restart is necessary.

Did you get your Netgear mirroring switch and have a chance to play with it? What is your verdict?

Yes, and I have commented the relevant question and even the Wiki. As said there - a 1 Gbit/s "hub" is better than nothing, at least in many capturing scenarios. For scenarios with high traffic volume and/or more complex traffic pattern (i.e. where you need to mirror more than a single port), you'd need something more advanced and thus more expensive.

I!ve also commented your other question (regarding traffic loss) with my experience on that subject.

Hopefully, you can try to figure out a proper VoIP filter for your own phone calls captured via the mirror, and share it here, of course without private details. :)

That's what I've already done, isn't it? It is normally sufficient to use a capture filter listing all IPs used by your VoIP provider to get rid of any other traffic, and there is no way to identify responses to REGISTER requests using tcpdump or dumpcap.

But you may try ngrep with -O and -v options and a regexp like "[Cc][Ss]eq: *[0-9]+ *REGISTER" instead, which acts similarly to tcpdump/dumpcap in terms that it does not maintain any context but it can classify packets by applying regular expressions on their contents. Using the -v option you say that only packets not matching the expression should be captured.

(20 Nov '16, 07:33) sindy

For the task clarity, I wonder how exactly Port Mirroring works in case of capturing VoIP traffic on a PC via switch from a standalone phone or ATA? Does the PC adapter only receive bidirectional traffic? Or it also transmits some traffic? What "bidirectional port mirror" would mean in this application, as such port is required by some VoIP Recording packages?

Btw, I found your suggestion to disable IP protocol in Properties of the LAN adapter dedicated to capture the mirrored VoIP traffic to work better than set it to DHCP or different subnet. In case of DHCP, various Windows programs tend to randomly select the adapter of higher priority, thus mixing VoIP and web traffic through same adapter. In case of a different subnet, I couldn't capture any traffic through the adapter. I wonder, how exactly disabling IP protocol affects traffic through an adapter?

(20 Nov '16, 13:48) zamar24

"Does the PC adapter only receive bidirectional traffic? Or it also transmits some traffic? "

I think the answer to that is it depends on the switch as I have seen both kinds.

(20 Nov '16, 22:06) koundi

various Windows programs tend to randomly select the adapter of higher priority

Interesting & good to know. Seems like a bug to me (why should Windows choose an adaptor without an IP address assigned for sending IP traffic), but I guess we have to accept it as a fact.

how exactly Port Mirroring works in case of capturing VoIP traffic on a PC via switch from a standalone phone or ATA?

It's not important whether it is VoIP traffic or any other. What is important is whether you can mirror each direction (ingress, egress) of a given source port to a distinct mirroring port and whether you need it because either the sum of egress and ingress bandwidth exceeds the bandwidth of the mirroring port or the mirroring has problems to handle two source frames starting at the same time.

If mirroring can resolve simultaneous occurrence of frames in both source directions properly (by queueing) and the sum of bandwidths on the source port is lower than the capacity of the mirroring port, you can use a single mirroring port. The only penalty you pay as compared to mirroring each direction separately is lower precision of timestamps (frames which had to wait in the mirroring port's queue will be delayed). At gigabit speeds, the timestamping error caused by this will be negligible compared to the actual jitter caused by WAN, so it won't noticeably affect your jitter analysis.

(21 Nov '16, 02:14) sindy