This post has NOT been accepted by the mailing list yet.
We have a mobile app that allows users to place video conference calls without a user-facing concept of accounts. A user is able to press a button, and then they are sent a generated username, password, and conference number to send up to our FreeSWITCH server to connect their calls. This setup works fine for us under normal circumstances but fails in a puzzling way under the following circumstances:
1: User starts the mobile app
2: User places a call (Call A)
3: User force kills the app
4: User re-opens the app
5: User places a second call (Call B)
Under this scenario, the video is directed correctly to Call B, but the audio is erroneously redirected to Call A which is still alive because the mobile app terminated without sending a BYE request. Additionally, when using a network monitor on the mobile device, we noticed that there are two open connections to FreeSWITCH, one on the local port we expect, and a second incoming connection on the lowest RTP port used by our mobile VoIP library. This only happens on these bad calls, and does not occur under normal circumstances.
We considered the possibility that the VoIP library we've been using on the mobile side could be the problem, but this issue persists even if we reinstall the application or reset the phone. Changing networks from our office Wifi network to LTE between Call A and Call B usually fixes the problem for us, so we suspect that FreeSWITCH has some internal logic to reconnect a caller to a call by IP address, ignoring the fact that when the device reconnects, its username, password, and conference number are different than the call FreeSWITCH is trying to reconnect it to.
Of course, that's speculation on our part. We've combed through the FreeSWITCH logs and can't find anything unusual on call B that suggests any sort of redirection of audio. We would appreciate any advice you could give us.