This message was deleted.

Hey @plain-crayon-28280, I think the best way to handle this is to have another level of retries in the application. Because the server will remove any and all participant state after a server-side timeout, it won't make a huge difference in terms of continued retries, versus calling

room.connect

again. Now for the audio issue that you mention, what are you running into? it should be possible to close off the existing audio session before attempting to acquire the mic again. If you are seeing issues with that (and it's reproducible), could you file a bug on GH? https://github.com/livekit/client-sdk-swift/

The Audio Issue is nothing the SDK can do about. iOS disallows starting a recording session from the Background eg. iPhone Display is off since iOS 16. Thats why we need to try to keep the Audio Session alive while reconnecting. I tried starting an audio session of my own when reconnecting, but it looks like something in webrtc shuts down all Audio Sessions since my recording also stops when the full reconnect happens.

@dry-elephant-14928 Is there a way to extend this server side timeout?

that's not possible.

@dry-elephant-14928 Bummer. We are doing that, but libwebrtc is killing the audiosession in a full reconnect nonetheless. We might can alter/need to WebRTC for that… (We are not using CallKit, because we want to mix Comms with Music)

I see.. yeesh.. CC: @better-house-11852. should there be a way where libwebrtc leaves the audio session alone?

@dry-elephant-14928 @better-house-11852 Any news? We are still don’t know how to extend the reconnecting time.