Too many ICE candidates in SDP crashes application

[miklz]

Hello, first off, thank you for writing the library and making it available.

I was playing with the library and the web application and noted that if the SDP has too many ICE candidates the library crashes, here's the SDP I have sent to cause this issue:

v=0
o=mozilla...THIS_IS_SDPARTA-99.0 5613840343672622141 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 11:36:6C:9B:6B:1E:DB:5F:1D:BA:BF:9B:81:EF:26:29:DA:A3:9B:FE:D2:4E:82:69:FF:6B:36:F8:48:34:C1:D7
a=group:BUNDLE audio
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 9010 UDP/TLS/RTP/SAVP 8
c=IN IP4 <ipv4>
a=candidate:0 1 UDP 2122055935 <ipv4> 33466 typ host
a=candidate:2 1 UDP 2122121471 <ipv6> 46372 typ host
a=candidate:4 1 UDP 2121859327 <ipv4> 35554 typ host
a=candidate:6 1 UDP 2121924863 <ipv6> 60214 typ host
a=candidate:8 1 UDP 2122252543 <ipv4> 44091 typ host
a=candidate:10 1 UDP 2121990399 <ipv4> 52144 typ host
a=candidate:12 1 UDP 2122187007 <ipv4> 40752 typ host
a=candidate:14 1 TCP 2105327871 <ipv4> 9 typ host tcptype active
a=candidate:15 1 TCP 2105393407<ipv6> 9 typ host tcptype active
a=candidate:16 1 TCP 2105131263 <ipv4> 9 typ host tcptype active
a=candidate:17 1 TCP 2105196799 <ipv6> 9 typ host tcptype active
a=candidate:18 1 TCP 2105524479 <ipv4> 9 typ host tcptype active
a=candidate:19 1 TCP 2105262335 <ipv4> 9 typ host tcptype active
a=candidate:20 1 TCP 2105458943 <ipv4> 9 typ host tcptype active
a=candidate:1 1 UDP 1685856255 <ipv4> 9008 typ srflx raddr <ipv4> rport 33466
a=candidate:5 1 UDP 1685659647 <ipv4> 9009 typ srflx raddr <ipv4> rport 35554
a=candidate:9 1 UDP 1686052863 <ipv4> 9010 typ srflx raddr <ipv4> rport 44091
a=candidate:11 1 UDP 1685790719 <ipv4> 9011 typ srflx raddr <ipv4> rport 52144
a=candidate:13 1 UDP 1685987327 <ipv4> 9012 typ srflx raddr <ipv4> rport 40752
a=recvonly
a=end-of-candidates
a=ice-pwd:e8345b5ee4a8314b8262b467dd985b2a
a=ice-ufrag:e22cfd71
a=mid:audio
a=rtcp-mux
a=rtpmap:8 PCMA/8000
a=setup:active
a=ssrc:1084292201 cname:{1c00c787-a4d7-44b0-80d9-dfee02dff86e}

Here's the log dump from the board:

This is not exclusive for ESP, I replicated the issue in my computer also:

I took a coredump from it, and this is the line where the issue happens, it's the same as in the ESP:

If, however, I sent only a few ICE candidates, the issue goes away:

v=0
o=mozilla...THIS_IS_SDPARTA-99.0 2112985685362454698 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 93:9A:CD:ED:15:0C:F3:6A:D5:66:32:D3:BF:29:29:9A:B5:ED:D8:BE:8C:8E:CE:8D:2C:67:68:9F:1C:AA:A9:05
a=group:BUNDLE audio
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 8704 UDP/TLS/RTP/SAVP 8
c=IN IP4 <ipv4>
a=candidate:0 1 UDP 2122187007 93707e22-cb5b-4740-964b-bc7815357a19.local 44708 typ host
a=candidate:2 1 UDP 2122252543 449a4bb4-7b9b-4bcc-b32d-87b63b5da3b5.local 40568 typ host
a=candidate:4 1 TCP 2105458943 93707e22-cb5b-4740-964b-bc7815357a19.local 9 typ host tcptype active
a=candidate:5 1 TCP 2105524479 449a4bb4-7b9b-4bcc-b32d-87b63b5da3b5.local 9 typ host tcptype active
a=candidate:1 1 UDP 1685987327 <ipv4> 8704 typ srflx raddr 0.0.0.0 rport 0
a=candidate:3 1 UDP 1686052607 <ipv6> 40568 typ srflx raddr 0.0.0.0 rport 0
a=recvonly
a=end-of-candidates
a=ice-pwd:798c4ecfb73a72aa0cf6d8c518ca56bf
a=ice-ufrag:572db475
a=mid:audio
a=rtcp-mux
a=rtpmap:8 PCMA/8000
a=setup:active
a=ssrc:3625534856 cname:{4c702394-50cf-4234-b4bf-3b101a2e44ac}

This issue was trick to debug, because it's a timing issue for the web application.