This iOS sample demonstrates multi-party video conferencing using WebRTC and the XirSys cloud infrastructure.
XSPeerClient, a websocket signaling client. (to be migrated to the XirSys project)PHQuartzVideoView, a video renderer which uses a CALayer to display CGImages.PHSampleBufferRenderer & PHSampleBufferView which render video using AVSampleBufferDisplayLayer.PerchRTC uses CocoaPods 0.37.2 to install its dependencies.
To get started, clone the repo and install its dependencies:
git clone git@github.com:perchco/perchrtc.git PerchRTC
cd PerchRTC
pod installThis demo assumes a single XirSys room, domain, and application. Here's how to configure PerchRTC to use your XirSys account:
PHCredentials.h.Only XirSys v2 accounts are supported. If you wish to use PerchRTC with a XirSys v1 account, please try the 0.1 tag.
From the perspective of our view controller, video chatting isn’t hard at all.
First, we start by creating a PHConnectionBroker instance. This class is going to perform most of the heavy lifting of discovering peers, and negotiating connections with them. For simplicity’s sake, we’ve hardcoded the app to work in a single room, which we ask the broker to join.
XSRoom *room = [[XSRoom alloc] initWithAuthToken:nil username:name andRoomName:roomName];
PHConnectionBroker *connectionBroker = [[PHConnectionBroker alloc] initWithDelegate:self];
[connectionBroker addObserver:self forKeyPath:@"peerConnectionState" options:NSKeyValueObservingOptionOld context:NULL];
[connectionBroker connectToRoom:room];Next, wait for the local stream to become ready. In order to display the video from a stream we need a PHRenderer. Lets create the local renderer immediately, and assign ourselves as its delegate. We also add a tap gesture recognizer so the user can mute and unmute the local feed.
- (void)connectionBroker:(PHConnectionBroker *)broker didAddLocalStream:(RTCMediaStream *)localStream
{
// Prepare a renderer for the local stream.
self.localRenderer = [self rendererForStream:localStream];
UIView *theView = self.localRenderer.rendererView;
UITapGestureRecognizer *tapRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(handleAudioTap:)];
[theView addGestureRecognizer:tapRecognizer];
}As the peer discovery and negotiation process continues, remote streams will become available. Let's add renderers for those as well.
- (void)connectionBroker:(PHConnectionBroker *)broker didAddStream:(RTCMediaStream *)remoteStream
{
// Prepare a renderer for the remote stream.
id<PHRenderer> remoteRenderer = [self rendererForStream:remoteStream];
UIView *theView = remoteRenderer.rendererView;
[self.remoteRenderers addObject:remoteRenderer];
UITapGestureRecognizer *tapToZoomRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(handleZoomTap:)];
tapToZoomRecognizer.numberOfTapsRequired = 2;
[theView addGestureRecognizer:tapToZoomRecognizer];
}
Once a renderer receives its first frame, it's time to show it in our view. As the dimensions of the rendered streams change, we should make sure to keep our layout up to date.
- (void)rendererDidReceiveVideoData:(id<PHRenderer>)renderer
{
if (renderer == self.localRenderer) {
[self showLocalRenderer];
}
...
}
- (void)renderer:(id<PHRenderer>)renderer streamDimensionsDidChange:(CGSize)dimensions
{
[self.view setNeedsLayout];
}As peers come and go, remote streams will be removed from the connection broker's set.
- (void)connectionBroker:(PHConnectionBroker *)broker didRemoveStream:(RTCMediaStream *)remoteStream
{
[self removeRendererForStream:remoteStream];
if ([broker.remoteStreams count] == 0) {
[self showWaitingInterfaceWithDefaultMessage];
}
}That about covers the basics. Things may seem simple on the surface, but that's because the signaling layer, and media engine are making a number of decisions on our behalf. Furthermore, our renderers are dealing with the complexity of drawing decoded frames, abstracting the result into a UIView.
Signaling is a critical part of any WebRTC application, and one that is (by definition) left up to the application developer. While the WebRTC standard defines how connections are established and how media is exchanged, it does not answer the question of “which peers want to connect”. Initially, this might seem like a drawback, but in practice this means that signaling can be customized exactly for your use case.
In this example, we use the XirSys WebSocket signaling server. This server employs a custom JSON-based messaging protocol, and a chat room model to allow for user discovery and communication. For our video conferencing use case we only need to exchange a few different types of messages:
| Message | Payload |
|---|---|
| Offer | A session description offer to connect, or renegotiate an existing connection. |
| Answer | A session description answer created in response to the offer. |
| ICE | A media transport & address/port candidate generated by the ICE agent. |
| Bye | Terminates a connection. |
XSPeerClient performs the role of signaling client, establishing a WebSocket connection to the XirSys signaling server. The client exposes a simple API via the XSPeerClientDelegate, and XSRoomObserver protocols.
@protocol XSRoomObserver <NSObject>
- (void)didJoinRoom:(XSRoom *)room;
- (void)didLeaveRoom:(XSRoom *)room;
- (void)room:(XSRoom *)room didAddPeer:(XSPeer *)peer;
- (void)room:(XSRoom *)room didRemovePeer:(XSPeer *)peer;
- (void)room:(XSRoom *)room didReceiveMessage:(XSMessage *)message;
@endFor a more in depth discussion of the sample code please visit our PerchRTC blog series.