I am using IceLink library for peer to peer communication. We need to deploy two servers IceLink and WebSync for that as listed here http://docs.frozenmountain.com/icelink2/index.html#class=icelink-getting-started-creating-a-conference-10_ios-macosx But I want to use XMPP instead of WebSync. Following code is used for WebSync now I just want to replace it so that I can use XMPP instead if this WebSync.
[client addOnStreamFailureWithValueBlock:^(FMWebSyncStreamFailureArgs *e)
{
[conference unlinkAll];
}];
// Add a couple event handlers to the conference to send
// generated offers/answers and candidates to a peer.
// The peer ID is something we define later. In this case,
// it represents the remote WebSync client ID. WebSync's
// "notify" method is used to send data to a specific client.
[conference addOnLinkOfferAnswerWithValueBlock:^(FMIceLinkLinkOfferAnswerArgs *e)
{
[client notifyWithNotifyArgs:[FMWebSyncNotifyArgs notifyArgsWithClientId:[FMGuid guidWithG:e.peerId]
dataJson:[e.offerAnswer toJson]
tag:@"offeranswer"]];
}];
[conference addOnLinkCandidateWithValueBlock:^(FMIceLinkLinkCandidateArgs *e)
{
[client notifyWithNotifyArgs:[FMWebSyncNotifyArgs notifyArgsWithClientId:[FMGuid guidWithG:e.peerId]
dataJson:[e.candidate toJson]
tag:@"candidate"]];
}];
// Add an event handler to the WebSync client to receive
// incoming offers/answers and candidates from a peer.
// Call the "receiveOfferAnswer" or "receiveCandidate"
// method to pass the information to the conference.
[client addOnNotifyWithValueBlock:^(FMWebSyncNotifyReceiveArgs *e)
{
NSString *peerId = [e.notifyingClient.clientId toString];
NSObject *peerState = e.notifyingClient.boundRecords;
if ([e.tag isEqualToString:@"offeranswer"])
{
[conference receiveOfferAnswerWithOfferAnswer:[FMIceLinkOfferAnswer fromJsonWithOfferAnswerJson:e.dataJson]
peerId:peerId
peerState:peerState];
}
else if ([e.tag isEqualToString:@"candidate"])
{
[conference receiveCandidateWithCandidate:[FMIceLinkCandidate fromJsonWithCandidateJson:e.dataJson]
peerId:peerId];
}
}];
// Subscribe to a WebSync channel. When another client joins the same
// channel, create a P2P link. When a client leaves, destroy it.
FMWebSyncSubscribeArgs *subscribeArgs = [FMWebSyncSubscribeArgs subscribeArgsWithChannel:@"/mychat"];
[subscribeArgs setOnSuccessBlock:^(FMWebSyncSubscribeSuccessArgs *e)
{
[self writeLine:@"-- Subscribed to %@.", e.channel];
}];
[subscribeArgs setOnFailureBlock:^(FMWebSyncSubscribeFailureArgs *e)
{
[self writeLine:@"-- Could not subscribe to %@. %@", e.channel, e.exception.message];
}];
[subscribeArgs setOnReceiveBlock:^(FMWebSyncSubscribeReceiveArgs *e) { }];
[subscribeArgs setOnClientSubscribeWithOnClientSubscribeBlock:^(FMWebSyncSubscribersClientSubscribeArgs *e)
{
NSString *peerId = [e.subscribedClient.clientId toString];
NSObject *peerState = e.subscribedClient.boundRecords;
[conference linkWithPeerId:peerId peerState:peerState];
}];
[subscribeArgs setOnClientUnsubscribeWithOnClientUnsubscribeBlock:^(FMWebSyncSubscribersClientUnsubscribeArgs *e)
{
NSString *peerId = [e.unsubscribedClient.clientId toString];
[conference unlinkWithPeerId:peerId];
}];
[client subscribeWithSubscribeArgs:subscribeArgs];
There is no question here. At any rate, as a general answer to future readers, you can use literally any method of communication between the clients. You could even email and copy/paste the information that's sent over the signalling channel (something I actually did for my earliest WebRTC stuff, to avoid the complexity of having a signalling server).
You simply must use your signalling channel to exchange the following information (I'm using the C# naming, but other languages should have similar names, but following the language conventions):
OnLinkOfferAnswer
once you callConference.Link
) is sent to the other peer. To callConference.Link
, you need to know the peer ID of who you're connecting to, so may need your signalling server to send this data to us (in my usage, I actually connected to an intermediate server for recording, and thus could use a hardcoded "server" peer ID).OnLinkOfferAnswer
once you register the offer withConference.ReceiveOfferAnswer
) is sent to the first peer (and registered the same way).OnLinkCandidate
callback (multiple times), which must be sent to the other peer and registered withConference.ReceiveCandidate
.Note that this all occurs asynchronously, so the ICE candidates could be generated before the answer is received. That is fine, as IceLink will internally manage them.
You must keep track of which peer this is meant for (the offer/answer and candidates are peer-specific). It's entirely up to your signalling library (XMPP here) to generate some kind of unique peer ID so that you can identify users (you could do it yourself if your signalling library does not).
The data that gets exchanged is JSON, but you shouldn't have to modify it in the typical usage. The
OfferAnswer
andCandidate
objects haveFromJson
andToJson
methods to handle the conversion.