Connection issue with a WebRTC p2p call while using a TURN server - webrtc

Question

While trying to test a newly installed TURN server, a strange thing is happening. The turn server is working with a mediasoup based application but it is not working for a simple p2p call between 2 browsers! First browser is firefox with relay only candidate generation setting and other is a regular chrome browser. The p2p call works perfectly fine with srflx candidates without the relay only setting in firefox but it never works with relay only candidates where as candidates are being generated as I can see from the logs. It seems that somehow the relay candidates are not useful to the peer connection when it should be. May be I am missing something here?
The testing method:
I am using latest firefox(102) to test the turn server by switching on the media.peerconnection.ice.relay_only flag to true. This is available in the about:config configuration options in firefox. With this flag switched on, a mediasoup application works fine by using relay-tcp candidate but a simple p2p WebRTC app fails connects. In the about:webrtc section of firefox, it shows a successful candidate negotiation along with the selected candidate pair while using a mediasoup application. While using a simple p2p call, there are no selected candidates being displayed in the about:webrtc section of firefox. It seems that the candidated handshake process is not happening in the simple p2p call.
I tested the turnserver using tricleICE as well in both the modes i.e. generating all possible candidates and generating relay only candidates. The trickleICE test page generates the candidates as expected in both the modes.
In the below mentioned sdps, only the real turn server ip has been masked with xx.xxx.xx.xxx. Nothing else has been changed other than ip masking.
In case you need some more information from my side to understand the problem better, please let me know.
Below are the generated local and remote sdp for your reference.
Local SDP (Offer)
v=0
o=mozilla...THIS_IS_SDPARTA-99.0 464200334888033493 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 53:36:D8:C7:BE:4A:18:8B:66:13:E0:F5:2A:CA:3E:12:D5:C2:5C:3D:49:52:37:69:E3:C5:DE:AB:EB:97:A6:FE
a=group:BUNDLE 0 1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 15203 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 xx.xxx.xx.xxx
a=candidate:2 1 UDP 8265727 xx.xxx.xx.xxx 11212 typ relay raddr xx.xxx.xx.xxx rport 11212
a=candidate:2 2 UDP 8265726 xx.xxx.xx.xxx 13559 typ relay raddr xx.xxx.xx.xxx rport 13559
a=candidate:0 1 UDP 92151807 xx.xxx.xx.xxx 15203 typ relay raddr xx.xxx.xx.xxx rport 15203
a=candidate:0 2 UDP 92151806 xx.xxx.xx.xxx 12659 typ relay raddr xx.xxx.xx.xxx rport 12659
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:543612c020ecbfa091075987638de7de
a=ice-ufrag:19fb9389
a=mid:0
a=msid:{df27f0b0-7ad1-4821-9d5c-100d8b7f46a1} {de00dd52-3713-4828-bf7c-eb6b0fc02830}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:3389249034 cname:{6f1432d9-6700-41e7-8d4e-12b2a58d142b}
m=video 15203 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 xx.xxx.xx.xxx
a=sendrecv
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:125 apt=121
a=fmtp:127 apt=126
a=fmtp:98 apt=97
a=ice-pwd:543612c020ecbfa091075987638de7de
a=ice-ufrag:19fb9389
a=mid:1
a=msid:{df27f0b0-7ad1-4821-9d5c-100d8b7f46a1} {6e402539-71af-4d4d-952f-14c89b1122a4}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:actpass
a=ssrc:2840162245 cname:{6f1432d9-6700-41e7-8d4e-12b2a58d142b}
a=ssrc:1181264584 cname:{6f1432d9-6700-41e7-8d4e-12b2a58d142b}
a=ssrc-group:FID 2840162245 1181264584
Remote SDP (Answer)
v=0
o=- 5898391754541643877 2 IN IP4 127.0.0.1
s=-
t=0 0
a=sendrecv
a=group:BUNDLE 0 1
a=msid-semantic:WMS izy342Js2ivoQo0m43FgE2Q3Y87sZ0NCQlYy
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fingerprint:sha-256 79:83:6F:1A:5B:E4:BD:C7:5D:D3:BD:FA:29:5E:FB:04:88:9D:29:4D:CB:1E:4A:66:C2:52:9A:33:FB:86:E5:B1
a=fmtp:109 maxplaybackrate=0;stereo=0;useinbandfec=1
a=ice-options:trickle
a=ice-pwd:S8EqJvFxFsROgTTfy2c1p+fO
a=ice-ufrag:dylB
a=mid:0
a=msid:izy342Js2ivoQo0m43FgE2Q3Y87sZ0NCQlYy 70e6f101-9697-4f7f-8d35-e10bbfa74958
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:active
a=ssrc:723086318 cname:NSNYU4Lgz+Cpndvm
m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fingerprint:sha-256 79:83:6F:1A:5B:E4:BD:C7:5D:D3:BD:FA:29:5E:FB:04:88:9D:29:4D:CB:1E:4A:66:C2:52:9A:33:FB:86:E5:B1
a=fmtp:124 apt=120
a=fmtp:125 apt=121
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:127 apt=126
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:98 apt=97
a=ice-options:trickle
a=ice-pwd:S8EqJvFxFsROgTTfy2c1p+fO
a=ice-ufrag:dylB
a=mid:1
a=msid:izy342Js2ivoQo0m43FgE2Q3Y87sZ0NCQlYy c481d53b-2e22-4ade-b9c9-a8740c96f309
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:active
a=ssrc:3533905249 cname:NSNYU4Lgz+Cpndvm
a=ssrc:3012959319 cname:NSNYU4Lgz+Cpndvm
a=ssrc-group:FID 3533905249 3012959319

Answer 1

There are some obvious mistakes and this mistake was something like that. I was not listening to the onicecandidate event on the callee side / remote side. Therefore, there was no icecandidates were being sent from the callee to the caller side and it was failing with ICE failure. As soon as I added the onicecandidate listener on the callee side and sent those candidates to the caller as well using my signalling channel, my p2p app started working with TURN. The only strange thing to me is that how it was working with STUN candidates without the onicecandidate listener on the callee side!!
For the future readers, Don't forget to add onicecandidate listener on both caller and callee side!