Failed PeerConnection establishment: Navigating the Peer Connection Conundrum

[mglettig]

I'm using aiortc as the offering peer and like to connect it to libdatachannel. The offer contains 2 tracks (a video track and a datachannel). The connection establishment fails. I found the following cause for it in the logs:

STUN remote ufrag check failed, expected="v9e1", actual="knU8"

When I analyzed the SDP offer I noticed that the offer has ice-ufrag and ice-pwd entries per track and not one on the session level. I checked the RFC8839 and found the following information:

The "ice-pwd" and "ice-ufrag" attributes can appear at either the session-level or media-level

So my question is: Does libdatachannel handle the case correctly when the ice-ufrag and ice-pwd are sent per track? Can someone point me to the class where this is implemented or some Unit-Tests covering that topic?

SDP Offer (from aiortc):

v=0
o=- 3903768100 3903768100 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic:WMS *
m=video 43261 UDP/TLS/RTP/SAVPF 97 98 99 100 101 102
c=IN IP4 172.30.112.124
a=recvonly
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=mid:0
a=msid:c316a4de-3aa0-4698-be29-940c0e94c28f 2d3a7ba0-f2ef-4e2b-ad97-6d88bfb6622b
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-mux
a=ssrc-group:FID 84181023 1913491376
a=ssrc:84181023 cname:c299bac0-651d-4f99-a492-1119a71a82aa
a=ssrc:1913491376 cname:c299bac0-651d-4f99-a492-1119a71a82aa
a=rtpmap:97 VP8/90000
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 goog-remb
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=97
a=rtpmap:99 H264/90000
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:100 rtx/90000
a=fmtp:100 apt=99
a=rtpmap:101 H264/90000
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=fmtp:101 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000
a=fmtp:102 apt=101
a=candidate:dde33047531be144d3e127f49d44fe48 1 udp 2130706431 172.30.112.124 43261 typ host
a=candidate:0fabdf8d9d7a7e5c4f392373e27f1cdb 1 udp 1694498815 217.162.232.136 58125 typ srflx raddr 172.30.112.124 rport 43261
a=end-of-candidates
a=ice-ufrag:knU8
a=ice-pwd:DLIRsE1ReYQRORNWZ4M2PU
a=fingerprint:sha-256 BB:B0:78:DA:3C:E5:D6:67:01:82:B8:CE:84:6F:A1:F0:A5:34:C3:2C:5B:27:A7:BE:A2:2F:20:60:F7:09:A0:46
a=setup:actpass
m=application 57152 DTLS/SCTP 5000
c=IN IP4 172.30.112.124
a=mid:1
a=sctpmap:5000 webrtc-datachannel 65535
a=max-message-size:65536
a=candidate:dde33047531be144d3e127f49d44fe48 1 udp 2130706431 172.30.112.124 57152 typ host
a=candidate:0fabdf8d9d7a7e5c4f392373e27f1cdb 1 udp 1694498815 217.162.232.136 58170 typ srflx raddr 172.30.112.124 rport 57152
a=end-of-candidates
a=ice-ufrag:v9e1
a=ice-pwd:IzJ2wCms9XxRxJhyAoASAq
a=fingerprint:sha-256 BB:B0:78:DA:3C:E5:D6:67:01:82:B8:CE:84:6F:A1:F0:A5:34:C3:2C:5B:27:A7:BE:A2:2F:20:60:F7:09:A0:46
a=setup:actpass

SDP answer (from libdatachannel):

v=0
o=rtc 3141384863 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=group:LS 0
a=msid-semantic:WMS *
a=setup:active
a=ice-ufrag:+RzT
a=ice-pwd:ckd8ZpHQRCT6+jgMDZJAcI
a=ice-options:ice2,trickle
a=fingerprint:sha-256 49:01:9A:C9:14:11:E6:74:A9:14:20:BC:3B:9F:CB:2F:C6:A2:37:1E:54:9F:5F:67:F6:E3:46:19:DF:CA:BA:F9
m=video 9 UDP/TLS/RTP/SAVPF 99 101
c=IN IP4 0.0.0.0
a=mid:0
a=sendonly
a=ssrc:42 cname:video-send
a=rtcp-mux
a=rtpmap:99 H264/90000
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:101 H264/90000
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=fmtp:101 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
m=application 9 DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=mid:1
a=sendrecv
a=sctpmap:5000 webrtc-datachannel 65535
a=sctp-port:5000
a=max-message-size:262144

Here are the full logs of the libdatachannel peer: logs_libdatachannel.txt

I observed this behavior with v0.18.5 as well as v0.19.1 of libdatachannel.

Any help is highly appreciated. Keep up the great work on libdatachannel.

[paullouisageneau]

So my question is: Does libdatachannel handle the case correctly when the ice-ufrag and ice-pwd are sent per track? Can someone point me to the class where this is implemented or some Unit-Tests covering that topic?

I looks like libdatachannel simply picks the last attribute it finds, which is an oversight. It should be fixed by #983.

I think it wasn't caught earlier because it requires a very specific scenario: negotiating 2 media or more, with libdatachannel as answerer, and with a remote endpoint generating different ICE ufrag and pwd attributes per media (aiortc is the only implementation that comes to mind).

It looks like aiortc generating setting different ice-ufrag and ice-pwd for each media causes issues with other implementations too, it was reported in aiortc/aiortc#370.

[mglettig]

Woow I'm deeply impressed by the fast response. 🚀 I tested the patch today and my problem is actually resolved. 🎉 Thank you so much @paullouisageneau. Would it make sense to apply this patch also to the v0.18 and v0.19 release branches?

[paullouisageneau]

Great! The patch will be released in v0.19.2.