Integrate XMPP instead of WebSync in IceLink Library

540 Views Asked by At

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];
1

There are 1 best solutions below

0
On

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):

  1. One peer's offer (generated via callback OnLinkOfferAnswer once you call Conference.Link) is sent to the other peer. To call Conference.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).
  2. That peer's answer (generated via callback OnLinkOfferAnswer once you register the offer with Conference.ReceiveOfferAnswer) is sent to the first peer (and registered the same way).
  3. Both peers will generate ICE candidates with the OnLinkCandidate callback (multiple times), which must be sent to the other peer and registered with Conference.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 and Candidate objects have FromJson and ToJson methods to handle the conversion.