FB24725948 Please let me know the progress.
Looking over the system log, it looks like you're hitting a limit on the number of simultaneous translation connections, which leads to this error:
2026-09-10 15:50:50.768629+0900 callservicesd: [com.apple.calls.callservicesd:CallTranslation] Failed to start downlink translation <NSError:0x7f246d8f0(SFSpeechErrorDomain:16) - {
NSLocalizedDescription = "Maximum number of simultaneous requests reached";
}>
Note that I think this is a limit on the connections a given process can make, NOT a device-wide limit, which means the limit is fairly low. I haven't tried this, but I think you might hit the limit if you:
- Make a call
- Enable translation
- Hold the call
- Repeat that cycle "a few" times
To be clear, I'm not saying your app is doing anything wrong, just describing my guess as to what the bug is.
In any case, my main concern here is actually this:
Once this occurs, the feature remains unusable until the device itself is rebooted.
How long have you waited before retrying? I'd expect this to self-correct after a few minutes, if not sooner.
In terms of your app’s involvement here, I have a few suggestions:
-
If you're handling multiple calls, you might try enabling/disabling translation based on which call is active.
-
If you're programmatically activating translation, you may want to delay that process briefly as you transition to allow other calls to do their own transitioning.
-
There's a good chance that artificial stress tests where you're rapidly cycling through calls will create this issue. Those tests may still have some value, but I think I'd just leave translation off for those kinds of tests.
Finally, if you do any more testing and can upload logs, there are two things I’d be interested in seeing:
-
A log that captures both the last call where translation worked and the first call where it failed, as that’s most likely to show the actual failure.
-
A log where the calls have been intentionally isolated (only one call happening at a time) with each action on the call spread out over time.
Expanding on that second point, every action you take with a call (Starting, accepting, reporting, etc.) generates a significant amount of logging over a relatively broad time window. That can make it harder to follow exactly what’s occurring in a call, as the logging from one action can easily overlap with the next, particularly with multiple calls involved. Intentional slowing down (by pausing for a second or two before you make any change) and only reporting a single call at a time can make it much easier to interpret the log data.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
