Hi,
Question 1:
Your app gets to choose its own channel UUID when joining a channel. 🎉. A recommended way to do this is via [NSUUID UUID] to create guaranteed unique identifier.
Question 2:
Push to Talk "channels" are totally distinct from other iOS APIs that have a session concept. One distinction is that PTT "channels" can be connected for an indefinite duration, whereas Live Activities have a time limit. Live Activities cannot play audio in response to a push.
Question 3:
It's up to your app to handle conflict resolution when receiving audio from multiple "groups." While the system only allows your app to join/("register") a single channel UUID at a time, you are free to update the channel descriptor if you need to reflect a change in the system user interface to distinguish between the "groups" in your example. You can also adjust the active participant whenever you need to. (If you want, you can play your own custom sound tone or synthesized speech to make the user aware of a change in "groups." You can also make a custom App Intent to allow the user to change the active "group" via Siri. Just make sure to update the channel descriptor whenever the group changes.)
But be careful, as the user will expect that the channel name in the channel descriptor will be the "group" that would hear the outgoing transmission if the user presses the talk button. You don't want the user to accidentally transmit to the wrong group of people...
In short, your app is free to intermediate among multiple "groups", and decide what exact audio should play if there are conflicting/simultaneous incoming transmissions from various "groups", even though only a single channel UUID is registered with the system.
Question 4:
For this part, you bring your own implementation. You'll write your own custom code to handle playing incoming audio and transmitting outgoing audio. You'll send outgoing audio to your custom server, using your choice of serialization, encryption, and networking protocols.
You'll write your own custom code to handle an incoming APNS push. Upon receiving a push, you'll connect to your server to start receiving the stream of audio packets, decrypt them, and play them. When the incoming audio has ended, you'll set the active remote participant to nil. Make sure to use transport level encryption, at the very least, so that audio packets flowing through the internet aren't vulnerable to eavesdropping. (You can add your own end-to-end encryption of the audio packets as well. )
See also:
https://developer.apple.com/forums/thread/707689
