private address cannot be parsed correctly

[nako-ruru]

I met a problem on one of my computer with win 7, the private address cannot be parsed correctly, this result in that all data are transferred by a turn server even both offer and answer side on the same device.

I tested on another computer with win10 in another network, all seems well.

I investigated deeply into codes, the issue is caused by rtpBindAddress at line 608 are different on the two computers, the former is "::ffff:0:0", while the latter is "::", and then the former's ip cannot be parsed because the codes go into the third branch

I tested the issue with lib version 6.06, not sure whether it is fixed in recently commits. Newest commits seems conflict with another lib

[sipsorcery]

Thanks for the info.

Is the problem that an ICE candidate gets produced with a hsot of ::ffff:0:0 and that causes an error somewhere, perhaps on the remote peer?

Could you provife an example of the SDP offer produced and/or the error message that occurs?

[nako-ruru]

Is the problem that an ICE candidate gets produced with a hsot of ::ffff:0:0 and that causes an error somewhere, perhaps on the remote peer?

I found it is caused by the following 2 steps.

1. bindAddress is assigned "::" at NetServices.cs line 385
2. socket's localEndPoint is "::ffff:0:0" after socket binds at NetServices.cs line 337

If I replace "bindAddress = (Socket.OSSupportsIPv6 && SupportsDualModeIPv4PacketInfo) ? IPAddress.IPv6Any : IPAddress.Any;" with "bindAddress = IPAddress.Any;" , then bindAddress is assigned "0.0.0.0", after binding, the socket's localEndPoint is "0.0.0.0", and then p2p connections successfully is established (doesn't use relay server)

Could you provife an example of the SDP offer produced and/or the error message that occurs?

I don't think I could provide any example, as I think it's a special environment that causes the codes are incompatible.

[sipsorcery]

If you execute the line below do you get true or false for doesMap?

var doesMap = IPAddress.IPv6Any.IsIPv4MappedToIPv6

[nako-ruru]

I got false, the image shows detail information

[sipsorcery]

That's a shame. The approach I had in mind won't work then.

Someone else has dealt with it using a rather crude string technique. I guess in the absence of any better ideas that's probably the best approach.

[nako-ruru]

Sorry, I think I made a mistake that I thought rtc connection uses replay in case of ip ffff:0:0

I will confirm whether it uses replay first.

[nako-ruru]

Sorry, I think I made a mistake that I thought rtc connection uses replay in case of ip ffff:0:0

I will confirm whether it uses replay first.

after I test for half an hour, as soon as the connection is established, I can see that the traffic on the turn server becomes higher; on the other hand, as soon as the connection is disconnected, the traffic becomes lower.

So I believe that it uses relay server.

[nako-ruru]

That's a shame. The approach I had in mind won't work then.

Someone else has dealt with it using a rather crude string technique. I guess in the absence of any better ideas that's probably the best approach.

thanks for your replay.

to be honest i'm not familiar with ipv6.

i read some articles yesterday, it is said that ipv6 from ::ffff:0:0 to ::ffff:ffff:ffff means from 0.0.0.0 to 255.255.255.255 respectively.

so is the socket bound to "::ffff:0:0" same with the one bound to "0.0.0.0" ? If so, I think p2p connection should be established for the offer and answer on the same devices. howerver, they uses relay.

[sipsorcery]

The problem here isn't actually IPv6 or IPv4 addresses it's IPv4 "mapped" to IPv6. You'll find the ffff:0:0 address in the list of special IPv6 addresses.

The bug in the sipsorcery library is that the IPv4 Mapped address is getting into the ICE channel logic somehow, or it could be even worse and Windows 7 is doing something even more convoluted when binding to either IPv4.Any or IPv6.Any.

It'll probably take firing up a Win7 VM to track it down but I'm not likely to get to it any time soon.

[lostmsu]

I think I might be hitting something related. My failed connection log on a IPv6 + IPv4 machine (Sipsorcery) that is trying to connect to an IPv4 only machine (web browser WebRTC) has only this line:

Debug: sipsorcery: Adding new candidate pair to checklist for: udp:[::]:51973 (host)->udp:XX.YY.225.206:60680 (srflx)

and no other pair candidates.

Also, the very beginning of the log has

Debug: sipsorcery: CreateRtpSocket attempting to create and bind RTP socket(s) on [::]:0. Debug: sipsorcery: CreateBoundSocket attempting to create and bind socket(s) on [::]:0 using protocol Udp. Debug: sipsorcery: CreateBoundSocket successfully bound on [::]:51973, dual mode True. Debug: sipsorcery: Successfully bound RTP socket [::]:51973 (dual mode True). Debug: sipsorcery: RTPChannel for [::]:51973 started.

And no mention of IPv4 addresses at all.

Is there an option to turn IPv6 off as a workaround?