A user connected with EnableX session with “Moderator” role has additional privileges over that of a “Participant” for the session. The Moderator exercises his privileges by executing exclusive methods designed to work from his End Point only, are known as Moderator Controls.

Table of Contents

Record a Session

Using EnableX you may get a RTC session recorded as individual streams and later be transcoded through a post-session service to create a single video file which can be retrieved and re-played using any Video Player. Recording can be started in 2 ways, viz.

Auto-Recording

You may define a room to start recording automatically as and when a session starts in the room. You may pass { settings: { auto_recording: true }} in the JSON Payload while creating a room to ensure a session is recorded automatically.

On-Demand Recording

Client API call helps you start and stop recording as and when needed. The available methods are accessible to Moderator only. Therefore, on the Moderator End-Point, you may require to create UI to use the methods to start or stop recording a session.

To start session recording on demand you may use EnxRoom.startRecord() method, and to stop may use EnxRoom.stopRecord() method. On successful initiation of recording and stopping of recording the moderator will be notified using - startRecordingEvent and - stopRecordingEvent delegate methods; also, all other participant swill be notified using - roomRecordOn: and - roomRecordOff: delegate methods respectively.

Class: EnxRoom

Methods:

  • - (void)startRecord – No parameter needed. To start recording
  • - (void)stopRecord – No parameter needed. To stop recording

Delegate Methods:

  • - startRecordingEvent – To moderator to notify that recording has started
  • - stopRecoedingEvent – To moderaor to notify that recording has stopped
  • - roomRecordOn: – To all participant to notify recording is on
  • - roomRecordOn: – To all participant to notify recording is off
[room startRecord]; // To start recording

// To all participants that recording has started
-(void)roomRecordOn:(NSArray*)Data{
	/* Data is 
	[	{
			"msg":"Room Recording On",
			"result":"0"
		},
		"<null>"
	]
	*/
}

// To acknowledge the moderator that recording has started
-(void)startRecordingEvent:(NSArray *)response{
	/* response is 
	[	{
			"result":0,
			"msg":"Success"
		},
		"<null>"
	]
	*/
}


[room stopRecord]; // To stop recording

// To all participants that recording has stopped
 -(void)roomRecordOff:(NSArray*)Data{
	/*Data is 
	[	{
			"msg":"Room Recording Off",
			"result":"0"
		},
		"<null>"
	]
	*/
}

// To acknowledge the moderator that recording has stopped
-(void)stopRecordingEvent:(NSArray *)response{
	/* response is 
	[	{
			"result":0,
			"msg":"Success"
		},
		"<null>"
	]
	*/
}
Error CodeDescription
5007Unauthorized Access. When user with participant role uses startRecord
5008Unauthorized Access. When user with participant role uses stopRecord
5033Start Record request is being processed. When moderator retries startRecord, awaiting confirmation for previous request
5034Session is being recorded. When moderator retries startRecord after recording has started by previous request
5035Stop Record request is being processed. When moderator retries stopRecord, awaiting confirmation for previous request
5036Non-Contextual method call. When moderator tries stopRecord without starting to record

Note:

  • In case of error, <null> is received at 1st Index, and Error Info at 2nd Index.
  • Moderator can start/stop recording any number of time during a session as he wishes.
  • Moderator can stop recording in a room defined with auto-recording feature.

Refer: How to fetch Recordings?

Hard Mute / Unmute Room

Moderator may put the room in a hard-mute state when he wishes no-one else to be audible in the Room. Any new user who joins the room when the room is in hard-mute state will also be inaudible

To put room into hard mute state, you may use EnxRoom.muteAllUser() method; and to disable you may use EnxRoom.unMuteAllUser() method. All participant of the room are notified with   – didHardMutedAll: and – didHardUnMutedAll: delegate methods; whereas the Moderator is notified with - didMutedAllUser: and - didUnMutedAllUser: delegate methods respectively.

Class: EnxRoom

Methods:

  • - (void)muteAllUser; – to hard mute room
  • - (void)unMuteAllUser; – to hard unmute room

Delegate Methods:

  • – didHardMutedAll:  – To all participants on hard-muting Room
  • – didHardMutedAll: – To all participants on hard-unmuting Room
  • – didMutedAllUser:– To notify Moderator that Room is hard-muted
  • – didUnMutedAllUser: – To notify Moderator that Room is hard-unmuted
[room muteAllUser]; // To hard-mute Room
[room unMuteAllUser]; // To hard-unmute Room

- (void) didMutedAllUser:(NSArray *Data){
 // You hard-muted Room
}

- (void) didUnMutedAllUser:(NSArray *Data){
 // You hard-unuted Room
}

- (void)didHardMutedAll:(NSArray *Data){
 // Room is hard-muted - to all
} 

- (void)didHardUnMuteAllUser:(NSArray *Data){
 // Room is hard-unmuted - to all
}
Error CodeDescription
5001Unauthorized Access. When a user with participant role uses muteAllUser
5002Unauthorized Access. When a user with participant role uses unMuteAllUser
5037Request to mute Room is in process. When moderator retries muteAllUser
5038Room is in muted state. When moderator uses muteAllUser on a muted Room
5039Room is in unmuted state. When moderator uses unMuteAllUser on a unmuted Room
5040Request to unmute Room is in process. When moderator retries unMuteAllUser

Hard Mute / Unmute Participant

Moderator may enforce hard-mute on any selected participant in the room. The affected participant will not be able to talk or may not be able to publish his video ntil the imposed state is lifted.

iOS Toolkit offers hard muting audio and force dropping the video of selected participant using  EnxStream.hardMuteAudio()  and EnxStream.hardMuteVideo()  methods respectively. You may lift the enforced muting state of Audio or Video using EnxStream.hardUnMuteAudio() and EnxStream.hardUnMuteVideo() methods respectively. The affected participant is notified using related events, viz. - didReceiveHardMutedAudio - didReceiveHardMutedVideo- didReceiveHardUnmutedAudio and - didReceiveHardUnmutedVideo. The Moderator will be acknowledged about the forced-mute status of the affected participant using related events, viz. - didHardMuteAudio, - didHardMuteVideo, - didHardUnMuteAudio, - didHardUnMuteVideo, .

Class: EnxStream

Methods:

  • - (void)hardMuteAudio:(NSString *)clientId – to hard mute audio
  • - (void)hardMuteVideo:(NSString *)clientId – to hard mute video
  • - (void)hardUnMuteAudio:(NSString *)clientId – to hard unmute audio
  • - (void)hardUnMuteVideo:(NSString *)clientId – to hard unmute video

Delegate Methods:

  • - didReceiveHardMutedAudio – To the affected participant to notify about hard-muted audio
  • - didReceiveHardUnmutedAudio – To the affected participant to notify about hard-unmuted audio
  • didReceiveHardMutedVideo – To the affected participant to notify about hard-muted video
  • - didReceiveHardUnmutedVideo – To the affected participant to notify about hard-unmuted video
  • - didHardMuteAudio – To acknowledge moderator on hard-muting user’s audio
  • - didHardUnMuteAudio – To acknowledge moderator on hard-unmuting user’s audio
  • didHardMuteVideo – To acknowledge moderator on hard-muting user’s video
  • - didHardUnMuteVideo – To acknowledge moderator on hard-unmuting user’s video
[stream hardMuteAudio:@”clientId”];	// To hard-mute user's audio

-(void)didReceiveHardMutedAudio:(NSArray *)Data{
	// Your audio is hard-muted
}
-(void)didHardMuteAudio:(NSArray *)Data{
	// You hard-muted user's audio
}

[stream hardUnMuteAudio:@”clientId”];	//To hard un-mute user's audio
-(void)didReceivedHardUnmutedAudio:(NSArray *)Data{
	// Your audio is hard-unmuted
}

-(void)didHardUnMuteAudio:(NSArray *)Data{
	// You hard-unmuted user's audio
}

// Video Hard-Mute/Hard-Unmute will used in the same way as Audio.  
Error CodeDescription
5009Unauthorized Access. When a user with participant role uses hardMuteAudio
5010Unauthorized Access. When a user with participant role uses hardUnMuteAudio
5011Unauthorized Access. When a user with participant role uses hardMuteVideo
5012Unauthorized Access. When a user with participant role uses hardUnMuteVideo

Lock / Unlock Room

Moderator may lock the Room forbidding any new person from joining the Session. To allow subsequent users to join session, Moderator need to unlock the Room.

To put room into Lock State, you use EnxRoom.LockRoom() method; and to unlock the Room you use EnxRoom.unlockRoom() method.

ClassEnxRoom

Methods:

  • - (void)lockRoom; – To lock Room
  • - (void)unlockRoom; – To unlock Room

Delegate Methods:

  • – room:didAckLockRoom:  To acknowledge moderator that the Room has been locked
  • –room:didLockRoom: To notify all participants that the room has been locked
  • –room:didAckUnlockRoom: To acknowledge moderator that the Room has been unlocked
  • –room:didUnlockRoom: To notify all participants that the room has been unlocked
[room lockRoom];

// Moderator is acknowledged that room has been locked 
- (void)room:(EnxRoom *_Nullable)room didAckLockRoom:(NSArray *_Nullable)data;

// Participants are notified that room has been locked
- (void)room:(EnxRoom *_Nullable)room didLockRoom:(NSArray *_Nullable)data;

 
[room unlockRoom];

// Moderator is acknowledged that room has been unlocked 
- (void)room:(EnxRoom *_Nullable)room didAckUnlockRoom:(NSArray *_Nullable)data;

// Participants are notified that room has been unlocked
- (void)room:(EnxRoom *_Nullable)room didUnlockRoom:(NSArray *_Nullable)data;
Error CodeDescription
5115Unauthorized Access. When user with participant role uses lockRoom or unlockRoom
5117Room is already locked. When user with moderator role uses lockRoom on a locked Room
5118Room is already unlocked. When user with moderator role uses unlockRoom on a unlocked Room

Disconnect User

Moderation may wish to disconnect or force-drop a participant from the Session by using EnxRoom.dropUser() method.

Method: -(void)dropUser:(NSArray *_Nonnull)clientIds;

Parameter:

  • ClientIds: Required. Array of CientId to be disconnected.

Delegate Methods:

  • -room:didAckDropUser: To acknowledge that the user has been disconnected
  • -room:didRoomDisconnected: To notify the effected user that he is disconnected from Room with reason.
[room dropUser:@[clientIds]];

// Acknowledgement that the user is dropped
(void)room:(EnxRoom *_Nullable)room didAckDropUser:(NSArray *_Nullable)data; 
Error CodeDescription
5116Unauthorized Access. When user with participant role uses dropUser

Destroy Session

Moderation may wish to conclude an ongoing session by using using EnxRoom.destroy() method. The same method may be used to disconnect all participants and moderators from the Session. When all users are disconnected, the Session is closed automatically.

Method: -(void)destroy;

Delegate Methods:

  • -room:didAckDestroy: To acknowledge that the session has been destroyed
  • -room:didRoomDisconnected: To notify the effected user that he is disconnected from Room with reason.
[room destroy];

// Acknowledgement that the session is destroyed
 (void)room:(EnxRoom *_Nullable)room didAckDestroy:(NSArray *_Nullable)data; 
Error CodeDescription
5116Unauthorized Access. When user with participant role uses destroy

Moderate Participants’ entry to a Session

In a knock-enabled Room, when a participant is connected to a room, he needs to wait until the Moderator grants him access to join the Session. While being awaited, participants will not be able to get remote streams and communicate with others awaited participants or moderators. The Moderator may allow the awaited participants into the room or deny entry.

When a participant is made to wait, the end points get different delegate method i.e. - room:didRoomAwaited on getting connected to room with a reason in JSON as { "event_type": "knock" }. Read more…

Methods:

  • -approveAwaitedUser:clientID – To allow participant into the Session.
  • -denyAwaitedUser:clientID – To deny user’s entry to room

Parameters:

  • clientID: For the user who is being allowed or denied entry to session

Delegate Methods:

  • -room:diduserAwaited – Moderator is notified about a user is awaited to join room
  • room:didAckForApproveAwaitedUser – Moderator is acknowledged that the awaited user is approved to join the session. Once approved, the approved user will get -room:didConnect delegate method.
  • room:didAckForDenyAwaitedUser – Moderator is acknowledged that the awaited user is denied entry to the session. Once denied, the denied user will get –room:didRoomDisconnect dlegate method with reason.
// Moderator is notified about awaited user
-(void)room:(EnxRoom *_Nullable)room diduserAwaited:(NSArray *_Nullable)data  {
	// Awaited Client Info in the data, e.g.
	// [{"id","String", "name": "String”}] 
	
	[room approveAwaitedUser:id];  // To allow

	[room denyAwaitedUser:id]; // To deny
	 
};

-(void)room:(EnxRoom *_Nullable)room didAckForApproveAwaitedUser:(NSArray *_Nullable)data; 
{	// User has been allowed entry	
}

-(void)room:(EnxRoom *_Nullable)room didAckForDenyAwaitedUser:(NSArray *_Nullable)data {
	// User has been denied entry	
}

To manage awaited users when moderator joins late

If moderator joins later than all the participants in a Knock-enabled Room, then his end-point needs to handle all the waiting participants to allow or deny entry to  the room individually or collectively. To do this, you need to get a list of participants who are waiting for access to the Room using  room.awaitedParticipants. You may need to build UI to allow or deny participant to join Room.

// e.g. room.awaitedParticipants

[
	{	"clientId”: "String", 
		"name": "String" 
	}
]

Floor Access Control in Lecture Mode

In Lecture Mode, only the Moderator publishes a stream to the room whereas all other participants subscribe to see and listen to the Moderator. If participants have questions to ask during the session, the Moderator can grant the floor to the participant to publish his stream.

The following steps to deploy Control Floor Access by moderator:

Request Floor Access

A participant requests for Floor access is forwarded to the Moderator using a notification event.

Class: EnxRoom

Method: - (void)requestFloor; – Participant requests floor access

Delegate Method: - didFloorRequestReceived: – The Moderator receives requests from Participant

[room requestFloor];
 -(void)didFloorRequestReceived:(NSArray )Data{     
 
/*Data is 
      [   {
              "clientId": "XXXX", // Who requested
              "name": "iOS" 
          },
          "<null>"
      ]
      */
  }
Error CodeDescription
5003Unauthorized Access. When a user with moderator role uses requestFloor
5041Request is in process. When participant retries requestFloor, awaiting acknowledgement of previous request
5042Request pending at moderator. When participant retries requestFloor after its registered with moderator
5082Non-Contextual method call. Method not available in group mode Room

Note: In case of error, <null> is received at 1st Index, and Error Info at 2nd Index

Cancel Requested Floor Access

A participant may cancel his request for Floor access which is pending at Moderator Side.

ClassEnxRoom

Method: - (void)cancelFloor; – Participant cancels request floor access

Delegate Method

  • - room:didCancelledFloorRequest: Moderator receives cancellation notification for already posted Floor Access Request from Participant
  • room:didFloorCancelled: Participant receives acknowledgement that his request for Floor Request has been cancelled.
[room cancelFloor];

//Moderator receives cancellation request
 -(void)didCancelledFloorRequest:(NSArray )Data;     
 
/*Data is 
      [   {
              "clientId": "XXXX", // Who requested
              "name": "iOS" 
          },
          "<null>"
      ]
      */
  }

// Participant receives acknowledgement
 -(void)didFloorCancelled:(NSArray )Data;     
 
/*Data is 
      [   {
              "clientId": "XXXX", // Who requested
              "name": "iOS" 
          },
          "<null>"
      ]
      */
  } 
Error CodeDescription
5003Unauthorized Access. When a user with moderator role uses cancelFloor
5041Request is in process. When participant retries cancelFloor, awaiting acknowledgement of previous request
5042Request pending. When participant retries cancelFloor after its acknowledged
5082Non-Contextual method call. Method not available in group mode Room

Note: In case of error, <null> is received at 1st Index, and Error Info at 2nd Index

Deny Floor Access

The Moderator may also deny a request for floor access to a participant.

ClassEnxRoom

Method: - (void)denyFloor:(NSString *)clientId; – Moderator denies floor access to a Participant

Delegate Method

  • - didDeniedFloorRequest: – Participant is notified that he is denied floor access
  • - didProcessFloorRequested: – Moderator is acknowledged that he denied floor access to a Participant
[room denyFloor:@”clientId”];   // Moderator denies floor access
 // Participant is notified about denied floor access
 -(void)didDeniedFloorRequest:(NSArray  )Data{     
     
     /* Data is 
     [   {
             "result":4117,
             "msg":"Floor Request Denied",
             "clientId":"XXX" 
         },
         "<null>"
     ] */
 }
Error CodeDescription
5005Unauthorized Access. When a user with participant role uses denyFloor
5045Invalid Client ID. When denyFloor is called with Invalid Client ID
5047Request is in process. When moderator retries denyFloor, awaiting acknowledgement of previous request
5048Non-Contextual Method Call. When moderator uses denyFloor against a user who is already granted Floor Access

Note: In case of error, <null> is received at 1st Index, and Error Info at 2nd Index

Grant Floor Access

Moderator might grant floor access to one or many users one by one. Note that at any given point of time, only one person may be granted floor access. To grant access to others, moderator must release floor access from the participant who is currently granted floor access. Once granted floor access, the designated participant will be notified using an event and he can publish his stream.

Class: EnxRoom

Method: - (void)grantFloor:(NSString *)clientId; – Moderator grants floor access to participant

Delegate Method:

  • - didGrantedFloorRequest: – Participant receives floor access
  • - didProcessFloorRequested: – Moderator is acknowledged that he granted floor access to a Participant
[room grantFloor:@”clientId”];   // Moderator grants floor access
 // Participant receives floor access
 -(void) didGrantedFloorRequest:(NSArray *)Data{
    
     /* Data is 
     [   {
             "result":1708,
             "msg":"Floor Granted",
             "clientId":"XXX" 
         },
         "<null>"
     ] */
 }
Error CodeDescription
5004Unauthorized Access. When a user with participant role uses grantFloor
5045Invalid Client ID. When grantFloor is called with Invalid Client ID
5043Request is in process. When moderator retries grantFloor, awaiting acknowledgement of previous request
5044Floor Access already granted. When moderator retries grantFloor after successfully granting Floor Access on a request
5046Floor Access already granted to another user. When moderator tries grantFloor to another user without releasing the Floor Access from another user
5069Floor Access can’t be granted. When Floor Access is released or being released from the same User or another User

Note: In case of error, <null> is received at 1st Index, and Error Info at 2nd Index

Finish Granted Floor Access

The Participant can finish floor access granted to him by Moderator.

Class: EnxRoom

Method: - (void)finishFloor; – Participant finishes his granted Floor Access

Delegate Method

  • - room:didFinishedFloorRequest: Moderator receives notification that participant has finish granted Floor Access himself.
  • – room:didFloorFinished: Participant receives acknowledgement that he finished granted Floor Access.
[room finishFloor];

//Moderator receives finished floor access
(void)didFinishedFloorRequest:(NSArray )Data;     
 
/*Data is 
      [   {
              "clientId": "XXXX", // Who requested
              "name": "iOS" 
          },
          "<null>"
      ]
      */
  }

// Participant receives acknowledgement
 -(void)didFloorFinished:(NSArray )Data;     
 
/*Data is 
      [   {
              "clientId": "XXXX", // Who requested
              "name": "iOS" 
          },
          "<null>"
      ]
      */
  } 
Error CodeDescription
5003Unauthorized Access. When a user with moderator role uses finishFloor
5041Request is in process. When participant retries finishFloor, awaiting acknowledgement of previous request
5042Request pending. When participant retries finishFloor after its acknowledged
5082Non-Contextual method call. Method not available in group mode Room

Note: In case of error, <null> is received at 1st Index, and Error Info at 2nd Index,

Release Floor Access

Moderator may terminate floor access granted to some participant. Upon termination, the user’s stream(s) is unpublished. It is necessary to terminate floor access of a participant before giving out floor access to another participant.

Class: EnxRoom

Method: -(void)releaseFloor:(NSString *)clientId; – Moderator asks participant to release floor

Delegate Method:

  • - didReleasedFloorRequest: – Participant i notified that floor access has been revoked. His stream is automatically unpublished.
  • - didProcessFloorRequested: – Moderator is acknowledged that he released floor access to a Participant
[room releaseFloor:@”clientId”];   // Moderator revokes granted floor access 
 // Participant is notified moderator has revoked floor access 
 -(void)didReleasedFloorRequest:(NSArray )Data{     

    /* Data is 
     [   {
             "result":1712,
             "msg":"Floor Released",
             "clientId":"XXXX"    
         },
         "<null>"
     ] */
 }
Error CodeDescription
5006Unauthorized Access. When a user with participant role uses releaseFloor
5045Invalid Client ID. When releaseFloor is called with Invalid Client ID
5049Request is in process. When moderator retries releaseFloor, awaiting acknowledgement of previous request
5050Non-Contextual Method Call. When moderator uses releaseFloor, without granting floor access to the specified user

Note: In case of error, <null> is received at 1st Index, and Error Info at 2nd Index

Restore Moderator Session

In case the Moderator gets disconnected during a session, the list of received floor requests and participant currently with floor access can be retrieved when connection is restored to the room in the Room-Meta-Data viz.

Structured Data JSON

  • room.roomMetaData[@"raisedHands"]– An Array of Client-Information who requested floor-access
  • room.roomMetaData[@"approvedHands"] – An Array of Client-Information who currently has floor access

Change Participant’s Role

A Moderator can designate a connected Participant to act as a Moderator during the session. Doing so, the promoted Participant would get access to all the rights of the Moderator, i.e. accesses all features listed under Moderator Controls; and the old Moderator becomes a Participant. Similarly, the new Moderator can further grant Moderator Role to other participant if needed.

Class: EnxRoom

Method: - (void)switchUserRole:(NSString *)clientId;

Parameter: ClientId – Client ID of the participant who is being designated as Moderator

Delegate Methods:

  • - room:didSwitchUserRole: – Moderator is acknowledged that he had requested for switch User Role
  • - room:didUserRoleChanged: – The New Moderator is notified that he has been promoted to Moderator Role
// Switching user with ClientId to Moderator Role
[_remoteRoom switchUserRole:@"clientId"];	

- (void)room:(EnxRoom *)room didSwitchUserRole:(NSArray *)data {
	// Modeator is acknowledged 
}

- (void)room:(EnxRoom *)room didUserRoleChanged:(NSArray *)data {
	// New Modeator is notified that 
	// his role is promoted to Moderator
}
Error CodeDescription
5085Unauthorized Access. When user with participant role uses switchUserRole

Start / Stop Live Streaming

EnableX supports forwarding live Video Sessions over RTMP to any live streaming CDNs which support this protocol.

To start forwarding RTMP stream you use EnxRoom.startStreaming() method; and to stop you use EnxRoom.stopStreaming() method.

ClassEnxRoom

Methods:

  • -(void)startStreaming:(NSDictionary *_Nonnull)streamingConfig; – To start forwarding RTMP Stream
  • -(void)stopStreaming:(NSDictionary *_Nonnull)streamingConfig; – To stop forwarding RTMP Stream

Parameters:

  • streamingConfig – Configuration, Options for forwarding streams
    • rtmpDetails.rtmpUrl – Use “RTM-URL/RTMP-KEY” from CDN Provider
    • rtmpDetails.urlDetails.url – Optional. Its RTMP Streaming View URL. If not given, a default Streaming View will be applied.

Delegate Methods:

  • - room:didAckStartStreaming: To acknowledge that a RTMP Streaming has started.
  • - room:didAckStopStreaming: To acknowledge that RTMP Streaming has stopped.
  • - room:didStreamingNotification To notify all on Streaming Event
[enxRoom addPinUsers:[clientID1, clientID2]];	// Pin Users
[enxRoom removePinUsers:[clientID1, clientID2]];// Unpin Users

-(void)room:(EnxRoom *_Nullable)channel didACKAddPinUser:(NSArray *_Nullable)data{
	// Acknowledges that Users are pinned
}

-(void)room:(EnxRoom *_Nullable)channel didACKRemovePinUser:(NSArray *_Nullable)data{
	// Acknowledges that Users are unpinned
}

-(void)room:(EnxRoom *_Nullable)channel didpinnedUsers:(NSArray *_Nullable)data{
	// Notifies with updated pinned user list
}
Error CodeDescription
5121Steaming Start request is in process. When a user with moderator role retries startStreaming, awaiting acknowledgement of previous request
5122Steaming is on. When a user with moderator role retries startStreaming after having started with streaming
5123Steaming Stop request is in process. When a user with moderator role retries stopStreaming, awaiting acknowledgement of previous request
5124Non-Contextual Method Call. When a user with moderator role tries stopStreaming with starting a Stream.
5125Invalid Stream Configuration

Pin User Stream(s)

A Moderator can now pin any user to force EnableX carry his stream to all end-points irrespective of the user talking or not. So, pinned users’ streams will always be available on Active Talker list. Users who are actively talking will be placed first, and then pinned-non-talkers are placed in the Active Talker list. Moderator can pin 1 less user than max_active_talkers configured in the room.

When a user joins a room, he is notified with a room meta information with -room:didConnect: event. In the room meta, a new array is introduced called pinnedUsers, its a array of Client-Ids of users who are currently pinned.

Methods:

  • -(void)pinUsers:(NSArray *_Nonnull)clientIds – To pin one or more user stream(s)
  • -(void)unpinUsers:(NSArray *_Nonnull)clientIds  – To unpin one or more pinned user stream(s)

Parameters:

  • clientIds– Array of Client-Ids of users whose streams will be pinned or unpinned

Delegate Methods:

  • - room:didAckPinUsers – To acknowledge that the users are pinned
  • - room:didAckUnpinUsers – To acknowledge that the users are unpinned
  • - room:didPinnedUsers: To notify all others in the room with an updated list of pinned users
[enxRoom pinUsers:[clientID1, clientID2]];	// Pin Users
[enxRoom unpinUsers:[clientID1, clientID2]];// Unpin Users

-(void)room:(EnxRoom *_Nullable)channel didAckPinUsers:(NSArray *_Nullable)data{
	// Acknowledges that Users are pinned
}

-(void)room:(EnxRoom *_Nullable)channel didAckUnpinUsers:(NSArray *_Nullable)data{
	// Acknowledges that Users are unpinned
}

-(void)room:(EnxRoom *_Nullable)channel didPinnedUsers:(NSArray *_Nullable)data{
	// Notifies with updated pinned user list
}
Error CodeDescription
5003Unauthorized Access. When a user with participant role uses pinUser
5003Unauthorized Access. When a user with participant role uses unpinUser
5126Undefined clientIDs

Explore Android Toolkit