Does a forwarded participant has access to the events of the room he is forwarded to ?

Thanks for reaching out, Valérian. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Does changing participant state in a room (muting him, changing role etc) reflect this in the room he is forwarded to or its per room

Thanks — I’m responding to your question about whether participant state changes (muting, role changes, etc.) in one room carry over to a room the participant is forwarded to. Short answer: Participant state is per‑room. Changes you make in one room (mute/unmute, role updates, track state, etc.) apply only to that room and do not automatically propagate to another room the participant is forwarded into. Important details: • Each room maintains its own participant state, so the forwarded room starts with its own view of that participant (default permissions, track subscriptions, roles) unless you explicitly apply changes when they join. • If you need the same state in the destination room, you must apply those changes there after the participant joins (for example, update their role or mute their tracks in the new room). • Event delivery and permission checks in the destination room still depend on the participant’s token grants for that room (subscribe/publish/role permissions). If you want, I can help with one of the following: • Show exact steps or code snippets for applying role/permission changes when forwarding a participant (tell me which SDK you’re using: JS, iOS, Android, or server). • Describe a recommended flow to copy state from the source room to the destination room (what to copy and where to apply it). • Suggest how to design tokens so the participant has the correct permissions when joining the new room. Which would you like to do next? Sources: Agent session | LiveKit Documentation | How to set a fixed participant for agent audio processing | LiveKit | SIP Lifecycle Management Agent | LiveKit Documentation

Does forward participant means totally moving him to a new room leaving the initial one or does the participant is in both room ?

Thanks — I’m responding to your question about whether a forwarded participant is moved entirely to the new room or is present in both rooms. Short answer: Forwarding is a move — the participant leaves the original room and is connected to the new destination. A single participant will not be present in both rooms simultaneously. Key points: • For SIP transfers (the common “forward” flow), LiveKit issues a SIP REFER which redirects the caller to the new endpoint. After the transfer, the participant is removed from the current room and connected to the new destination. • Creating a new SIP participant in another room starts a separate call/session; it does not keep the original participant in the source room. • Participant state (mute, role, subscriptions) is per room. When forwarded you stop seeing the source-room state unless you explicitly recreate or reapply it in the destination. If you’d like, I can: • Show the exact API call or code snippet for performing a transfer in your SDK (tell me which SDK you’re using), or • Describe a pattern to replicate a participant’s state into the destination room right after forwarding. Which would help you most? Sources: Handling payments with PCI compliance | LiveKit | Outbound Calling Script | LiveKit Documentation

Pourtant la doc dit Forward participant LiveKit Cloud feature This feature is only available in LiveKit Cloud. You can forward a participant to one or more rooms using the

ForwardParticipant

API. Forwarding allows you to share a participant's tracks with other rooms. For example, if you have a single ingress feed that you want simultaneously share to multiple rooms. A forwarded participant's tracks are shared to destination rooms until the participant leaves the room or is removed from a destination room using

RemoveParticipant

.

Merci — je réponds à votre contradiction entre les deux descriptions. La doc que vous avez citée décrit la fonctionnalité ForwardParticipant de LiveKit Cloud. Pour lever toute ambiguïté : • ForwardParticipant partage les tracks (audio/vidéo) d’un participant vers une ou plusieurs salles de destination. Le participant original reste dans sa salle source pendant que ses tracks sont reproduites dans les salles cibles. • Autrement dit, c’est un partage/simulcast vers d’autres rooms — le participant peut être "présent" simultanément dans plusieurs rooms via ses tracks partagées. • ForwardParticipant s’arrête quand le participant quitte la salle source ou quand on appelle

RemoveParticipant

dans une salle de destination. Important : ceci est différent d’un transfert SIP (par ex.

TransferSIPParticipant

) qui déplace effectivement l’appelant — dans ce cas le participant quitte la salle et est connecté ailleurs (pas de présence simultanée). Si vous voulez, je peux : • Montrer un exemple d’appel API

ForwardParticipant

et comment les tracks apparaissent dans la room de destination (dites quel SDK ou langage vous utilisez), ou • Proposer un flux pour répliquer l’état d’un participant (rôles, mute, metadata) dans les salles cibles si vous avez besoin que l’état soit cohérent dans chaque room. Laquelle préférez-vous ? Sources: How to set a fixed participant for agent audio processing | Company directory phone assistant | LiveKit Documentation

Est ce que du coup le participant peut recevoir les evenements de la room vers laquelle il est forward ?

Merci — je réponds à votre question : « Est‑ce qu’un participant forwardé reçoit les événements de la room vers laquelle il est forward ? » Court et clair : non — un participant dont les tracks sont forwardées vers une ou plusieurs rooms ne devient pas un participant « complet » de ces rooms et ne reçoit pas automatiquement les événements de ces rooms comme s’il y était connecté. ForwardParticipant partage uniquement les pistes (audio/vidéo) vers les salles de destination ; la présence complète (signalisation, évènements Room, contrôle des rôles, etc.) reste attachée à la room source où le participant est réellement connecté. Points importants : • Les tracks forwardées apparaissent dans la room de destination comme provenant d’un participant, mais le participant original ne reçoit pas le flux d’événements destinés aux participants de la room de destination (par ex.

participant_connected

,

room_metadata_changed

émis par la room de destination). • Le participant forwardé conserve ses propres événements côté source (événements émis dans la room source). • Si vous avez besoin que le participant « voie » ou réagisse aux événements d’une room de destination, il faut soit : ◦ connecter réellement le client dans la room de destination (rejoindre la room), soit ◦ implémenter un mécanisme serveur qui relaie les événements pertinents de la room de destination vers le participant (par ex. via une API ou un canal de data custom), soit ◦ créer un agent/bot présent dans la destination qui écoute les événements et exécute des actions ou envoie des messages au participant dans la source. Si vous voulez, je peux : • Montrer un schéma avec l’une de ces options (rejoin vs relais serveur vs agent) ; ou • Proposer un exemple d’implémentation pour relayer des événements (quelle stack/SDK utilisez‑vous ?). Laquelle préférez‑vous ?

Un participant peut etre dans plusieurs rooms a la fois ?:

Merci — je réponds à votre question : « Un participant peut‑il être dans plusieurs rooms à la fois ? » Court et clair : • Oui et non — cela dépend de ce que vous entendez par « être dans » une room. Détails : • Présence complète (signalisation, événements de room, contrôles de rôle, permissions, etc.) : un client unique (une seule connexion LiveKit) ne peut pas être connecté simultanément comme participant actif dans plusieurs rooms. Pour recevoir les événements d’une room et participer pleinement (publier/consommer tracks, recevoir events Room), il faut être réellement connecté à cette room. • Partage de tracks (ForwardParticipant) : LiveKit Cloud permet de partager les tracks publiées par un participant vers une ou plusieurs rooms de destination. Dans ce cas, les tracks apparaissent dans les rooms cibles comme si elles venaient d’un participant, mais le participant original reste physiquement connecté uniquement à la room source — il ne reçoit pas les événements des rooms de destination. • Sessions distinctes : si vous voulez qu’un même utilisateur soit participant complet dans plusieurs rooms en même temps, il faudrait établir plusieurs connexions (par exemple plusieurs clients ou instances de client avec tokens/identités séparées) — chaque connexion représente une présence complète dans sa room respective. • Transfert SIP (TransferSIPParticipant) : ce mécanisme déplace l’appelant (le participant quitte la room source et est connecté ailleurs) — ce n’est pas une présence simultanée. Que faire selon votre besoin : • Si vous voulez simplement diffuser un flux vers plusieurs audiences → utilisez ForwardParticipant (partage de tracks). • Si vous voulez que le même utilisateur reçoive events et interagisse dans plusieurs rooms → connectez‑le/instanciez‑le dans chaque room (plusieurs connexions), ou mettez en place des agents/bots côté serveur pour relayer infos et commandes entre rooms. • Si vous voulez garder état/permissions synchronisés entre rooms → il faudra répliquer ces états côté serveur ou appliquer les changements dans chaque room quand nécessaire. Souhaitez‑vous un exemple d’architecture pour l’une de ces options (forwarding, multi‑connexion, ou relais d’événements via un agent) ? Indiquez l’SDK/langage que vous utilisez et je fournis un exemple concret.

ya t' il un moyen pour le client de savoir qu' il a ete forward'e ?

Merci — je réponds à votre question : « Y a‑t‑il un moyen pour le client de savoir qu’il a été forwardé ? » Court et clair : Non, il n’existe pas de notification client automatique qui indique qu’un participant a été forwardé via

ForwardParticipant

. Le forward partage uniquement les pistes du participant vers d’autres rooms côté serveur ; le client qui publie les tracks reste connecté à la room source et ne reçoit pas nativement un événement “vous avez été forwardé” depuis LiveKit Cloud. Options pour détecter ou informer le client qu’il a été forwardé • Envoyer une notification côté application / serveur : ◦ Au moment où vous appelez

ForwardParticipant

, votre serveur peut aussi envoyer un message (via votre propre signaling, websocket, HTTP push, ou canal data) au client pour l’informer. • Relais via un data channel côté LiveKit : ◦ Créez un data channel ou utilisez les messages data de LiveKit depuis la room source pour informer le participant que ses tracks sont partagées vers X rooms. • Stocker/consulter un état serveur : ◦ Maintenez l’état de forwarding dans votre backend (par ex. quelles rooms reçoivent les tracks) et exposez une API que le client peut interroger pour vérifier s’il est forwardé. • Agent/bot côté destination : ◦ Si besoin d’un flux inverse (par ex. confirmer réception côté destination), un bot présent dans la room de destination peut envoyer un accusé au serveur qui le relaie ensuite au client source. • Recréation d’un événement personnalisé dans la room source : ◦ Après le forward, publiez un

room_metadata

ou un message data dans la room source indiquant le forwarding — tous les clients de la room qui écoutent verront cette mise à jour. Recommandation pratique • La méthode la plus simple et fiable est d’envoyer une notification directe depuis votre serveur au client au moment où vous effectuez l’appel

ForwardParticipant

. Cela garantit que le client est informé en temps réel sans dépendre d’événements internes à LiveKit. Si vous voulez, je peux : • Fournir un exemple d’implémentation pour votre stack (par ex. JS client + node server) montrant comment notifier le client au moment du forward, ou • Proposer un pattern complet (backend state + notifications + audit) si vous avez besoin de suivre et d’afficher l’état de forwarding pour plusieurs participants. Laquelle préférez‑vous ?