PeerConnectionTransport sets restartingIce to true when it builds an ice restart offer. Only setRemoteDescription sets it back to false. After an ordinary resume the server does not send the subscriber a new offer, so the flag stays true for the life of the transport and every candidate after that goes into pendingCandidates instead of the peer connection. The subscriber can no longer take any path the server proposes, so the person is still heard and hears nothing.
The same thing was fixed in the web SDK in livekit/client-sdk-js#2054. The conclusion there was that queueing gains nothing, because the server does not send candidates ahead of the offer that introduces them.
Seen on 2.27.0. The code is unchanged on 2.28.2.
PeerConnectionTransportsetsrestartingIceto true when it builds an ice restart offer. OnlysetRemoteDescriptionsets it back to false. After an ordinary resume the server does not send the subscriber a new offer, so the flag stays true for the life of the transport and every candidate after that goes intopendingCandidatesinstead of the peer connection. The subscriber can no longer take any path the server proposes, so the person is still heard and hears nothing.The same thing was fixed in the web SDK in livekit/client-sdk-js#2054. The conclusion there was that queueing gains nothing, because the server does not send candidates ahead of the offer that introduces them.
Seen on
2.27.0. The code is unchanged on2.28.2.