You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Im building an Video call app which uses Stream sdk where Im working on audioroute functionality. Im not able to settheaudio route.
Steps to Reproduce
So I was trying to change the audio route in IOS. I first getAudioRoutes It gives me [{"name": "Speaker", "selected": true, "type": "Speaker"}, {"name": "iPhone Microphone", "type": "Phone"}].
After that I try to set using await RNCallKeep.setAudioRoute(uuid, routeName); with routeName as name. But this function is not setting the audio route.
We encountered this exact class of issue in an Expo SDK 56 application using React Native 0.85.3.
The route list can expose the built-in input as name: "iPhone Microphone" and type: "Phone". Our local iOS fix handles the Phone route by using AVAudioSession's default output behavior instead of treating the displayed name as an external input route. This made setAudioRoute reliable across physical iPhones.
We also delayed application-level route changes until didActivateAudioSession, because CallKit may not have activated the AVAudioSession yet. Finally, when the native operation failed, we passed e.description as an NSString to reject instead of the NSException object. That last change avoids the current React Native TurboModule crash addressed by PR #845.
This issue is a strong example of why the library should normalize route types and handle the Phone route explicitly.
Activity
octaviotastico commentedon Jul 31, 2026
We encountered this exact class of issue in an Expo SDK 56 application using React Native 0.85.3.
The route list can expose the built-in input as name: "iPhone Microphone" and type: "Phone". Our local iOS fix handles the Phone route by using AVAudioSession's default output behavior instead of treating the displayed name as an external input route. This made setAudioRoute reliable across physical iPhones.
We also delayed application-level route changes until didActivateAudioSession, because CallKit may not have activated the AVAudioSession yet. Finally, when the native operation failed, we passed e.description as an NSString to reject instead of the NSException object. That last change avoids the current React Native TurboModule crash addressed by PR #845.
This issue is a strong example of why the library should normalize route types and handle the Phone route explicitly.