Push to talk channelManager(_:didActivate:) doesn't get called

Question

Created 2w

Replies 1

Boosts 0

Participants 2

I am implementing the new Push to talk framework and I found an issue where channelManager(:didActivate:) is not called after I immediately return a NOT NIL activeRemoteParticipant from incomingPushResult. I have tested it and it could play the PTT audio in foreground and background. This issue is only occurring when I join the PTT Channel from the app foreground, then kill the app. The channel gets restored via channelDescriptor(restoredChannelUUID:). After the channel gets restored, I send PTT push. I can see that my device is receiving the incomingPushResult and returning the activeRemotePartipant and the notification panel is showing that A is speaking - but channelManager(:didActivate:) never gets called. Thus resulting in no audio being played. Rejoining the channel fixes the issue. And reopening the app also seems to fix the issue.

Answered by DTS Engineer in 841573022

I am implementing the new Push to talk framework and I found an issue where channelManager(:didActivate:) is not called after I immediately return a NOT NIL activeRemoteParticipant from incomingPushResult. I have tested it and it could play the PTT audio in foreground and background. This issue is only occurring when I join the PTT Channel from the app foreground, then kill the app. The channel gets restored via channelDescriptor(restoredChannelUUID:). After the channel gets restored, I send PTT push. I can see that my device is receiving the incomingPushResult and returning the activeRemotePartipant and the notification panel is showing that A is speaking - but channelManager(:didActivate:) never gets called.

Having looked a multiple PTT app and MANY CallKit apps (which uses the same underlying audio infrastructure), the only reason I've ever seen this happen is that your app previously activated (or tried to) the audio session itself. The system cannot activate an already active session, so the callback never occurs. The solution is to audit your code, find that "setActive" call and remove it. Keep in mind that some of our higher level APIs also activate the session on their own, so the activation might be implicit, not explicit.

Thus resulting in no audio being played.

FYI, this is typically caused your app triggering it's on playback through "didActivate". Strictly speaking you might have been able to play audio (because your session was technically active), you just "didn't".

Rejoining the channel fixes the issue.

That sounds like your setActive call is part of your app launch sequence but rebuilding your internal infrastructure deactivated your session without activating it again.

And reopening the app also seems to fix the issue.

Sounds like another code path worth looking.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

2w

Accepted Answer

Recommended

I am implementing the new Push to talk framework and I found an issue where channelManager(:didActivate:) is not called after I immediately return a NOT NIL activeRemoteParticipant from incomingPushResult. I have tested it and it could play the PTT audio in foreground and background. This issue is only occurring when I join the PTT Channel from the app foreground, then kill the app. The channel gets restored via channelDescriptor(restoredChannelUUID:). After the channel gets restored, I send PTT push. I can see that my device is receiving the incomingPushResult and returning the activeRemotePartipant and the notification panel is showing that A is speaking - but channelManager(:didActivate:) never gets called.

Having looked a multiple PTT app and MANY CallKit apps (which uses the same underlying audio infrastructure), the only reason I've ever seen this happen is that your app previously activated (or tried to) the audio session itself. The system cannot activate an already active session, so the callback never occurs. The solution is to audit your code, find that "setActive" call and remove it. Keep in mind that some of our higher level APIs also activate the session on their own, so the activation might be implicit, not explicit.