Voice Interface

Epic Online Services (EOS) Voice helps you create and manage voice chat rooms for your users. You can host EOS Voice chat rooms on Epic's server(s) using EOS Lobbies, or on your back-end server(s). Also, a user can communicate one-on-one or in groups across multiple platforms, during a match, and in your product's lobby.

The connections made with EOS Voice establish only between authenticated users and go through Voice servers without exposing personal information (PI) about the users. EOS handles all the scaling, quality of service, maintenance, multi-region presence, and other machinery of the voice servers.

To use the Voice interface, you should:

1. Review and determine the integration method you want to use with your game.
2. Investigate the Voice sample (C and C#) and learn how to use the Voice interface with your product.
3. Integrate the Voice interface into your applications:
   1. Configure your client policies
   2. Integrate the Voice interface based on your chosen integration method.
4. Review the best practices, voice metrics, and usage limitations for the Voice interface.

You can integrate Voice into your application in two ways:

• Use Voice with Lobbies: Integrate the EOS SDK into your Game Client and let EOS Lobbies take care of room management and authorization. Using the Lobbies Interface only requires a client integration and offers room ownership, search, and invites.

• Use a Trusted Server Application: Integrate the EOS SDK into your Game Client and the SDK or the Web API into a trusted server application. This approach gives developers the most flexibility by allowing them to customize room management and authorization, but requires more integration effort.

When using Voice with Lobbies, integrate the EOS SDK into your Game Client and let Lobbies take on the role of the trusted server application. The lobby generates roomIds, creates tokens for members, and authorizes requests to join, kick, or mute other players.

To secure rooms, lobbies can be made private and require invites.

Configure your client policy for the Game Client with userRequired and allow:

• Lobbies with actions appropriate for that client, such as connect, readLobby, and so on
• Voice with the lobbyConference action

createRoomToken, mute, and kick are intended for server use only and should remain disabled. Otherwise, this would allow Game Clients access to any roomId.

1. The Game Client initializes the SDK and acquires the EOS_HLobby interface as well as the EOS_RTC and EOS_RTCAudio interface.
2. The Game Client authorizes the local user using the Connect interface.
3. The Game Client creates a new Lobby using EOS_Lobby_CreateLobby with the bEnableRTCRoom flag enabled.
4. The Lobby requests room tokens and returns them with the media server URL. The EOS SDK then uses the token to join the voice room.
5. Other users joining the lobby automatically receive the matching room token to join the voice conference.
6. The Lobby owner can send out invites to other players, and public lobbies can be searched for and joined without an invitation.
7. The Lobby owner can mute or kick other players.
8. All clients use the EOS_RTC and EOS_RTCAudio interfaces to manage audio input/output, change the local mute/speaker status, or leave the room.

The EOS SDK Lobbies sample demonstrates this configuration.

For more control over room management and authorization with Voice, you can use the Trusted Server Application integration instead.

Configure your client policy for the Server with:

• userRequired disabled to allow the server to use clientId and client secret for authorization with the Connect interface.
• Voice with createRoomToken, kick, and mute to allow the server to create room tokens for players for any roomId, remove a player and revoke their token, and mute a player, respectively.

1. The Game Client initializes the SDK and asks a trusted application, such as a dedicated server or web application, to enter a voice room.
2. The trusted server authenticates, using its ClientId and Client Secret with the Connect interface.
3. The server generates a roomId and requests a room token on behalf of players for their ProductUserIds and the given roomId from the EOS Voice backend.
   • When using a dedicated server with the EOS SDK, the server initializes the SDK and calls EOS_Platform_GetRTCAdminInterface to get an EOS_HRTCAdmin handle that can call createRoomToken, mute, and kick.
   • A web application can acquire an EOS Client Auth token and use the Voice Web API instead.
4. The trusted server returns the room token and media server URL to each players’ game client applications, using existing communication methods.
   • The communication method between the client and server is up to you and can be accomplished with network replication, messaging, HTTP, or any other existing communication method.
5. The Game Client connects to the media server using EOS_RTC_JoinRoom to join the room with the token provided by the server.
6. Other users can join the room by asking the trusted server for a Token for their ProductUserId of the same room and using it to connect to the media server.
   • The server logic dictates the authorization method used to determine who is allowed to join a given room and mute or kick other users from it. This integration method enables developers to customize this aspect.
   • The Voice Server sample demonstrates this with a password to join the room and with a lock that is shared with the owner and needs to be provided for operations such as kick or mute.
7. All clients use the EOS_RTC and EOS_RTCAudio interfaces to manage audio input/output, change the local mute/speaker status, or leave the room.

The EOS SDK Voice Client & Voice Server Samples (C and C#) demonstrate this configuration.

There are 3 interface handles available for RTC functionality, which you can get from your Platform Interface.

EOS_HRTCAdmin handle

• The Voice backend keeps voice rooms managed by lobbies separate from those managed by developer servers. This means features such as kicking or hard-muting a participant in a lobby conference cannot be accomplished with the EOS_HRTCAdmin interface, but only through the Lobbies interface itself.
• Used for admin functionality such as creating a room token, kicking, or muting.
• Should only be used on trusted server applications, not on game clients or shared community servers.
• Retrieve this handle with EOS_Platform_GetRTCAdminInterface

EOS_HRTC handle

• Used for room level functionality that is not specific to audio/voice, such as notifications when a user leaves or joins a room.
• Obtain this handle with EOS_Platform_GetRTCInterface

EOS_HRTCAudio handle

• A voice-specific subinterface of EOS_HRTC.
• Obtain this handle from the EOS_HRTC handle with EOS_RTC_GetAudioInterface

For Windows, you must pass the EOS_Windows_RTCOptions in the Platform Interface's RTCOptions before creating the platform.

The C SDK example (a code snippet is copied below, but see the Voice Interface - C SDK page for full details) does the following for windows:

• Creates an instance of the EOS_Windows_RTCOptions class called WindowsRtcOptions.
• Configures its attributes.
• Points the value of RtcOptions.PlatformSpecificOptions to the address of WindowsRtcOptions.

The C SDK example code snippet for Windows:

Bidirectional Muting

To comply with various platform requirements such as blocklists, you should use EOS_RTC_BlockParticipant to implement bidirectional muting of players where necessary.

Parental Controls

Consider checking parental control settings before enabling Voice in your sessions.

Voice has interface-specific usage rate limitations. For general information about throttling, usage quotas, and best practices, see Service Usage Limitations.

You can access your Voice operational metrics under Your Product > Game Services > Voice in your Developer Portal from the previous 30 days.

You can filter the data by time interval (5 minutes, 30 minutes, 1 hour, 1 day, 7 days, 14 days, 30 days) and by platform (Windows, PS4, PS5, and so on).

Once you start using the Voice service, data populates the graphs automatically and requires no additional setup from you.

Metrics include:

• Connected Users per Platform: Amount of players connected to the voice service within the selected timeframe, broken down by platform.
• Voice Users Status: A breakdown of voice SDK statuses (i.e. Connected, Error, Disconnected, and so on).
• Join Room: Overall user join error rates.
• Join Room Errors: Detailed information about specific join room errors and their rates.
• Room Sizes: Distribution of room sizes based on participant count across all platforms.
• Errors: Detailed information about errors and their rates.