Infinite loop in CreateOffer

[jech]

Webrtc is at cddf631.

I've got a reproducible hang in CreateOffer, where hasLocalDescriptionChanged persistently returns true although nothing is changing. Adding a loop to do println(t.Mid()) yields (0, 1). Adding println(desc.SDP) yields:

v=0
o=- 2718194448058297639 1612296369 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 49:2B:D2:53:A6:71:31:7D:70:9A:B5:9E:E5:A7:2D:8A:88:35:D2:5F:57:0D:C4:F7:3A:86:53:A0:C8:5E:E0:B3
a=group:BUNDLE 0
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=setup:actpass
a=mid:0
a=ice-ufrag:KGYfsiPKkRztPQvH
a=ice-pwd:SdJBHmMLpkjuomedoCcusGXqCJNzPqhU
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=ssrc:902986156 cname:zsS95IvrkCqgPy5v3IxScYsNnvesJaXCgOTy
a=ssrc:902986156 msid:zsS95IvrkCqgPy5v3IxScYsNnvesJaXCgOTy e22b328d-aa70-4b24-aa4a-e1f76e6a29fb
a=ssrc:902986156 mslabel:zsS95IvrkCqgPy5v3IxScYsNnvesJaXCgOTy
a=ssrc:902986156 label:e22b328d-aa70-4b24-aa4a-e1f76e6a29fb
a=msid:zsS95IvrkCqgPy5v3IxScYsNnvesJaXCgOTy e22b328d-aa70-4b24-aa4a-e1f76e6a29fb
a=sendrecv
a=candidate:310921987 1 udp 2130706431 192.168.3.100 47255 typ host
a=candidate:310921987 2 udp 2130706431 192.168.3.100 47255 typ host
[... bunch of candidates omitted...]
a=candidate:4031623909 2 udp 2130706431 2a01:[...] 50610 typ host
a=end-of-candidates
m=video 0 UDP/TLS/RTP/SAVPF 0

Yes, I'm positive that it ends just after the m= line.

The sequence of events is as follows. The server (Pion) does pc.AddTrack(t1), where t1 is a TrackLocalStaticRTP. It then performs CreateOffer, which works fine, SetLocalDescription and sends the local description over the signalling channel to the client (browser). The server then performs pc.AddTrack(t2), and notices that negotiation is still in progress, so it waits for the (now obsolete) answer from the client, and does SetRemoteDescription. Now the PC is in a stable signalling state once again, so the server performs CreateOffer again, which hangs.

Just to be clear: the call to pc.AddTrack(t2) happens before SetRemoteDescription, and therefore before the second call to CreateOffer. There are no concurrency issues here, just AddTrack which races with SetRemoteDescription of an obsolete answer.

[jech]

The root issue was that my code was erroneously attempting to negotiate an empty set of video codecs, which resulted in the empty media track section in the SDP cited above. Note that the strange SDP was generated by Pion. I am not sure whether this is the correct behaviour in this case (impossible to satisfy constraints) — other conceivable behaviours would be to fail at AddTrack time, to fail at CreateOffer time, or to negotiate an inactive media track.

My suggestions:

• Avoid infinite loop in CreateOffer #1657 should be applied in any case, since it avoids an infinite loop which could be due to either a bug in Pion or in the client application;
• Fix check for unchanged transceivers in CreateOffer #1658 should be applied if people think it is correct, since it makes CreateOffer somewhat more robust;
• SetRemoteDescription called with multiple conflicting ice-ufrag values #1659 may be closed with no further ado.

[Sean-Der]

Fixed by 1640767