Channel and capture VoIP traffic on a dedicated NIC?

asked 2017-11-18 17:17:19 +0000

zamar24 gravatar image

updated 2017-11-19 02:57:23 +0000

I'm trying to capture Freephoneline app calls on a dedicated PC NIC by running Wireshark 2.4.2 on a Windows 10 64-bit PC. The captured calls from Freephoneline to an ATA are SIP type, and show up in Wireshark VoIP Calls window. But only when just one PC NIC is enabled. When 2 NICs are enabled, Windows redistributes traffic between them in a way that makes capturing Freephoneline on a single dedicated NIC impossible - regardless of Metric manually set in each NIC Properties or auto assigned.

This happens despite Freephoneline app allows to bind it to a selected adapter at each launch. Apparently, such binding works only for some calls, and even for them handshake goes through an adapter with lower Metric. I also tried using ForceBindIP app to further bind Freephoneline to a certain adapter, yet again not all its traffic went through that adapter, thus preventing capturing it as VoIP call.

Are their other options to completely limit Freephoneline traffic only to one NIC, while several NICs are enabled on the PC? Is there any defect in latest ForceBindIP that prevents it from completely binding a selected app traffic to a certain adapter in both directions? AdapterWatch shows that the app seems to bind traffic OK, but probably some initial SIP packets still pass through the 2nd adapter with lower Metric. While I'm trying to separate all VoIP traffic to one dedicated adapter.

edit retag flag offensive close merge delete


Some info is missing in your description.

First, do you need to limit all the VoIP call related packets to a single NIC just to facilitate capturing or for some other reason? Because Wireshark allows you to capture on several interfaces simultaneously.

Second, if the reason is different, do your NICs have IP addresses from the same subnet or from different ones?

sindy gravatar imagesindy ( 2017-11-18 17:59:58 +0000 )edit

Yes, a VoIP recording app can do it only on one selected adapter at a time. Also, it would allow to separate VoIP traffic through one NIC, and all other network and web traffic through another mic to ensure no interference. Subnet is the same as they are routed through the same gateway, but it can be made different if needed by using 2 gateways. Do you think its the solution - why?

zamar24 gravatar imagezamar24 ( 2017-11-18 18:05:49 +0000 )edit

Is there a way to send you the .pcap file

There is but I guess there is no point in doing that as your issue is not Wireshark-related, as you've said you need to limit the VoIP data exchanges to a single NIC so that a VoIP recording app could work.

The reason why I've asked about IP subnets of the NICs was because the remote ends of SIP and RTP flows of the same call may be on different machines, so if routes to these different machines would use gateways in different subnets, it could explain something; as you say both NICs are in the same subnet, it is purely an issue of the network stack of the OS how it spreads the outgoing data among the two NICs.

If you receive the incoming data where you don't expect them, bear in mind that some systems ...(more)

sindy gravatar imagesindy ( 2017-11-18 18:23:59 +0000 )edit

I can look at ARP requests, but can it be controlled in any way on a Windows PC by a user?

As to whether my Q is Wireskark related, it is in a sense that Wireshark is used for variety of purposes, most of which are not related to finding Wireshark own bugs, but rather to the field of using Wireshark to analyze changes to network traffic, such as directing VoIP traffic through a single NIC rather than giving up to randomized Windows network chaos.

zamar24 gravatar imagezamar24 ( 2017-11-18 18:34:35 +0000 )edit

As to whether my Q is Wireskark related

What I had in mind is that Wireshark tells you exactly what has happened but rarely why it has happened. And the way you've narrowed your question, it is neither from the group "how to do xyz in Wireshark" nor from the other one called "what field xyz means in protocol tuv" any more, because what you need to find out is how to convince your OS (Windows in this particular case) to behave the way you want it to, and this is something with which Wireshark cannot help you. The only point where Wireshark can help here is to confirm my theory regarding the ARP response carrying a MAC address of a "wrong" interface, but even if it confirms that, it cannot help you change that behaviour. What you might be able to do to circumvent such behaviour would be ...(more)

sindy gravatar imagesindy ( 2017-11-18 20:15:07 +0000 )edit

Wireshark is instrumental in this study, and therefore the thread is totally relevant. Meanwhile, it may expose yet another Wireshark shortcoming. :)

The recording app captures traffic based on selected protocol and adapter IP or GUID. Port doesn't seem to be set for SIP, at least in the GUI choices. However, if I mirror the traffic of one (generic) adapter to another (VoIP dedicated) adapter via the switch, we may have an issue here, if Freephoneline is running on the same PC. In this case, the NIC will face bidirectional packets flow from FFL to an external ATA on WAN, plus the missing packets will be coming back via mirror to the same NIC. Not sure whether FFL, the NIC, recording app, and Wireshark will be able to handle this packet mess due to timestamp and sequence differences?

zamar24 gravatar imagezamar24 ( 2017-11-18 22:05:40 +0000 )edit

A better solution may be to find a way to dedicate one NIC to VoIP traffic in Windows. It looks like ForceBindIP doesn't do the trick for whatever reason. Any other ideas?

zamar24 gravatar imagezamar24 ( 2017-11-19 03:03:27 +0000 )edit