I was wondering if it would be possible (or desirable) to "convert" UDP packets to TCP before transmission over a wireless link with interference issues, then "convert" them back to UDP once they are received successfully? Not sure how this would be done in ROS, as a quick look through the NAT and Mangle windows don't show any way to change between TCP and UDP like you can change addresses and ports. But the idea is to be able to retransmit, rather than lose, packets that do not arrive intact over a wireless link due to interference, then change them back to UDP at the far end.

No, you really don't want to do that. If you're dealing with lost packets due to the wireless link, play with these settings instead or fix your link.

No, you really don't want to do that.

Reasons?

If you're dealing with lost packets due to the wireless link, play with these settings instead or fix your link.
[Wireless/Advanced tab]

We routinely set hw-retries and adaptive noise immunity. The link can't be "fixed"; it's a short hop across a couple city blocks in a noisy environment. We're trying to make UDP traffic (in particular, SIP) more reliable across this one link without going to a licensed connection--and without changing all our SIP equipment to use TCP on the off-chance it follows this one link.

UDP packets are usually time sensitive. By the time you've established a TCP connection and dealt with re-transmission timeouts over a lossy link, the data will be so delayed it will be worthless. If you really want to try it, fire up an OpenVPN TCP tunnel over the link and route UDP through that, but results are likely to be extremely poor.

UDP packets are usually time sensitive. By the time you've established a TCP connection and dealt with re-transmission timeouts over a lossy link, the data will be so delayed it will be worthless.

No doubt the link would add jitter according to how lossy it is, but SIP via TCP isn't unheard of.

If you really want to try it, fire up an OpenVPN TCP tunnel over the link and route UDP through that, but results are likely to be extremely poor.

Unfortunately, I think the tunnel itself would contribute a lot of overhead.

As far as i'm aware there is no mechanism to 'convert' UDP to TCP or vice versa as they are fundamentally different protocols. For instance there's no sequence numbers in UDP. So let's assume you did the opposite and wanted to go TCP-UDP-TCP well how do you recreate the sequence numbers on the other end? You can't

The only way to do this is through encapsulation, use a TCP based VPN so the VPN itself will retransmit the lost segments

I agree with the above comments. By the time you re-transmit etc... it will be worthless because then you'll need to buffer further audio leading to worse latency or bad jitter.

I've found iLBC the best voice codec to use over a Wi-Fi link. Even on one with some tolerable interference. It's a very durable codec that uses little bandwidth for voice. Where all the others crack up, iLBC has been faithful for me.

The only problem with iLBC, is that it's not support on all gear or by all VoIP gateway providers. I won't use any other codec over a public Wi-Fi link.

I understand that, for near-real-time applications like SIP, you would need a longer jitter buffer to allow time for retransmission. And yes, you can configure SIP to use TCP, though we don't want to impose that requirement everywhere because of a localized problem.

This question wasn't strictly limited to SIP; that's just where the problem became noticeable first. It seems that the best (only?) way to "convert" UDP data to TCP is to create a TCP-based tunnel across the problematic link, and pass the UDP data through that.

It is not a good idea, because the re-transmit time for TCP is normally quite high because it is designed for end-to-end operation (over potentially many hops).
The re-transmit at WiFi level happens much quicker because it operates over the radio hop only, so it is much more likely to solve the probkem.
When your link has lots of packet loss even with reasonable re-transmit at WiFi level (hw-retries), fixing it at transport layer does not make sense.