search

Unity-Technologies / com.unity.webrtc

WebRTC package for Unity
Other
738 stars 186 forks source link

[BUG]: Wrong Candidate Pair Generation while establishing ICE Connection #1024

Closed AkMo3 closed 3 months ago

AkMo3 commented 3 months ago

Package version

3.0.0-pre.7

Environment

* OS: Windows
* Unity version: Unity 2022
* Unity WebRTC version: 3.0.0-pre.7

Steps To Reproduce

  1. We are establishing a connection to a mediasoup SFU to send our video stream, but unable to perform it due to ICE connection failure.
  2. The mediasoup SFU is running locally, so I do not require an STUN and do expect STUN ICE Candidates

Note: If you need more information on reproduction, we will provide a detailed step-by-step process. I'm skipping it for now as it is a long process.

Current Behavior

So there are 3 problems that possibly might be connected:

Problem 1: ICE Candidate pairs generated between 2 ice candidates, both having tcptype as passive

  1. We were observing the stats of WebRTC and observed that ICE candidate pairs where created between 2 candidates where both tcptype where passive:

Candidate Pair: image

Local Candidate: image

Remote Candidate: image

Now as per RFC 6544:

When the candidates are paired together, active candidates are always
   paired with passive, and S-O candidates with each other.  When a
   connectivity check is to be made on a candidate pair, each agent
   determines whether it is to make a connection attempt for this pair.

According to this, these candidate pairs should never have been made.

Problem 2:

  1. We observed that the ICE Candidates we are getting after setting the remote description have tcytype set to passive, which is weird because the remote SDP we are setting also has ice candidates where tcptype is passive .

NOTE: Are adding a transceiver with direction of sendonly and a video track initialised.

Local SDP ```v=0 o=- 1199735864450006573 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 a=extmap-allow-mixed a=msid-semantic: WMS 894a7b51-3c91-4b88-901a-2d364bd6ae8a m=video 9 UDP/TLS/RTP/SAVPF 127 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:F+wq a=ice-pwd:ShUi7pcAARVEbn7C9boC9FzY a=ice-options:trickle a=fingerprint:sha-256 63:A4:BE:25:92:F8:40:2A:91:95:7A:DF:BB:11:60:E5:B5:0D:07:3E:05:5F:C0:8F:F2:40:59:47:A5:C0:C4:89 a=setup:actpass a=mid:0 a=extmap:1 urn:ietf:params:rtp-hdrext:toffset a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 urn:3gpp:video-orientation a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=sendonly a=msid:894a7b51-3c91-4b88-901a-2d364bd6ae8a 033ac5f9-0629-4297-aa53-267b2c51ca3a a=rtcp-mux a=rtcp-rsize a=rtpmap:127 VP8/90000 a=rtcp-fb:127 goog-remb a=rtcp-fb:127 transport-cc a=rtcp-fb:127 ccm fir a=rtcp-fb:127 nack a=rtcp-fb:127 nack pli a=fmtp:127 implementation_name=Internal a=ssrc:1522988633 cname:pRg5a1pLr3ksRQc7 a=ssrc:1522988633 msid:894a7b51-3c91-4b88-901a-2d364bd6ae8a 033ac5f9-0629-4297-aa53-267b2c51ca3a ```
Remote SDP ```v=0 o=mediasoup-client 10000 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-lite a=group:BUNDLE 0 a=msid-semantic: WMS * a=fingerprint:sha-224 42:13:50:3C:7A:6C:4C:91:85:FC:4C:9F:D8:4F:0B:A1:25:AC:A1:7B:5F:F4:39:8E:AB:D4:85:52 m=video 7 UDP/TLS/RTP/SAVPF 127 c=IN IP4 127.0.0.1 a=rtcp-mux a=rtcp-rsize a=recvonly a=mid:0 a=setup:passive a=ice-ufrag:4rhsjpismcz01qd5x4al0ezh3xola3q6 a=ice-pwd:mtjqxb86c2t2bkfb7y0zyshz5fqfsxoo a=ice-options:renomination a=candidate:udpcandidate 1 udp 1076302079 127.0.0.1 2008 typ host a=candidate:tcpcandidate 1 tcp 1076276479 127.0.0.1 2014 typ host tcptype passive a=end-of-candidates a=rtpmap:127 VP8/90000 a=fmtp:127 x-google-start-bitrate=1000 a=rtcp-fb:127 transport-cc a=rtcp-fb:127 ccm fir a=rtcp-fb:127 nack a=rtcp-fb:127 nack pli a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:13 urn:3gpp:video-orientation a=extmap:14 urn:ietf:params:rtp-hdrext:offset ```
  1. For these SDP configuration we are receiving the following ice candidates:
candidate:409686127 1 tcp 1518280447 192.168.56.1 62576 typ host tcptype passive generation 0 ufrag F+wq network-id 1, Address: 192.168.56.1:62576, port: 62576, username: F+wq

candidate:3813496624 1 tcp 1518214911 172.21.16.1 62578 typ host tcptype passive generation 0 ufrag F+wq network-id 7, Address: 172.21.16.1:62578, port: 62578, username: F+wq

candidate:1850055128 1 tcp 1518018303 192.168.1.5 62580 typ host tcptype passive generation 0 ufrag F+wq network-id 2 network-cost 10, Address: 192.168.1.5:62580, port: 62580, username: F+wq

candidate:1573183930 1 tcp 1518151935 2401:4900:1c9b:64c5:1df4:5775:4fc3:c504 62582 typ host tcptype passive generation 0 ufrag F+wq network-id 3 network-cost 10, Address: [2401:4900:1c9b:64c5:1df4:5775:4fc3:c504]:62582, port: 62582, username: F+wq

candidate:2340496649 1 tcp 1518086399 2401:4900:1c9b:64c5:a1cd:b0eb:59a5:494b 62583 typ host tcptype passive generation 0 ufrag F+wq network-id 4 network-cost 10, Address: [2401:4900:1c9b:64c5:a1cd:b0eb:59a5:494b]:62583, port: 62583, username: F+wq

We expect these candidates to contain tcptype as active because in Chrome/Chromium, for the identical configuration of local and remote SDP, we get active candidates.

Problem 3: Local candidates are indicated as remote candidates

  1. Looking at the above ICE candidates, you can observer that both the ICE candidates present in problem 1 are local.

Expected Behavior

  1. ICE Candidate pairs only be created between 2 candidates having active-passive tcptype as per the mentioned RFC.
  2. Local candidates not being selected as remote candidates.
  3. We are not yet sure why problem 2 is occurring. Any information on this is appreciated.are

Anything else?

No response

AkMo3 commented 3 months ago

Closing this issue in favour of the future different issue.