MumbleKit framework expert needed for an existing VOIP iOS App maintenance

We are looking for an expert consultant for the maintenance of our existing iOS app that's using MumbleKit. Following bug is needed to be fixed as POC that needs to be completed in order to be selected for the maintenance project. Following is the POC bug details. Please understand the issue first, ask questions and show you intent to be able to fix it, we will then proceed on further steps for time/cost estimation of this POC fix. Please provide estimate only on expert development skills scenario excluding any learning curve involved. Application The application is Incoming calls only. We cannot make outgoing calls. The calls come from bus drivers. The information about calls comes through socket connection when the app is running and in focus. The notification for calls come through push/voip notification when the app is in the background. The calls can be initiated through postman/fiddler tools and it needs another MumbleKit client setup. Problem: When a call comes, it is attended. The call starts but the audio is not hearable in phone speakers like a normal call. It was working fine and started showing after the iOS13 update. If we connect hands free with the phone then audio can be heard perfectly. The outgoing audio is fine, which means that voice from the phone app is going to the other side fine. We have debugged it in a lot of detail and I hope this can help. If the phone is locked and a phone call is received, the audio can be heard without hands-free like it should. Once we receive one call with the phone locked, then the calls work fine. If we kill the application and start again, it will again start showing the problem and attending a call on a locked phone somehow clears the blockage of audio routing to speakers. Reason: It looks like that when the app launches for the first time, its audio configuration is somehow messed up or it possibly needs some additional privileges or access to be enabled so that it is available by default. Call: When the call comes, the app logs its user into MumbleKit and sends the accepted response back to Java server. The Java server creates the room in Mumble and adds both in the room and hence the call starts.