MaxiAmigos and WebRTC: An Interview With Rene Tapia

May 16, 2013

Dating in Brazil has never been more fun, now that MaxiAmigos is using WebRTC.

Dating is one of those markets that just cries out for WebRTC. It made perfect sense for me to reach out to Rene Tapia, CEO of MaxiAmigos.

MaxiAmigos is a dating/social network in Brazil. To me it was the perfect example:

  1. An existing service
  2. A local vendor
  3. A dating site

How great can that be?


Rene TapiaRene Tapia took the time to answer my questions and share their experience of integrating WebRTC into their service.


What is MaxiAmigos all about?

MaxiAmigos is a free site for making new friends and online dating, focused on helping people make true and meaningful friendships in the real world.

If you read the testimonials in our front page, you can find testimonials from users that found their wife or husband at MaxiAmigos, or made a very good friend, or whose circle of friends is now mostly people from MaxiAmigos.

This of course gives us a ton of satisfaction, but we still have many exciting ideas to implement.


What role does voice and video calling have in your service?

Our users communicate primarily though offline messages and instant messaging (IM). However, going back and forth with offline messages can take a lot of time, and a lot of work. And even with IM, there can be many distractions and interruptions since people are usually multitasking while they are IMing. And in the end, when you meet somebody in person, there might not be that much chemistry after all.

But if you could have a voice conversation (without having to give your phone number right away), the tone of voice, the intonation, the way the other person talks, etc, could tell you in a few minutes if there is good chemistry, and if you would like to take this friendship further, and maybe meet this person in real life.

Since our objective is to help people make true friendships in the real world, we are very excited about the addition of voice conversations in MaxiAmigos with WebRTC. We believe this is a big step forward in that direction.

Video is a double-edged sword for dating apps, since some users tend to abuse the video functionality. But we will add video soon by adding controls to enable sending/receiving video before a call is initiated/answered (this is straightforward to do with WebRTC). But we wanted to launch voice calls as soon as possible, and so we opted for voice only calls initially.


You aren’t a new service. Why haven’t you opted for Flash or Skype as your calling technology?

Actually, our first IM solution was Userplane’s Webmessenger, which was based on Flash. But then Userplane removed the free/add supported version of Webmessenger, and since we could not afford the voice/video bandwidth costs, we had to remove Webmessenger.

Given our experience with Userplane’s Webmessenger, we really wanted to eliminate as many dependencies as possible. So we did not want to depend on a closed/proprietary solution like Flash, or another third party service provider like Skype, etc, and we decided to develop our own IM solution based on XMPP, ejjaberd, BOSH  and JSJac.


What made WebRTC different for you?

WebRTC is an open standard, and the vast majority of the voice/video communications are p2p (which means no server bandwidth costs). Besides, it does not require the installation of any plugins, and we already had XMPP in place, which we could use as a signaling mechanism. WebRTC was the perfect solution for adding voice/video communications to the IM in MaxiAmigos.


How are your users reacting to this addition?

Below are 3 comments from our users (translated from Portuguese):

“I loved it, and in this way I communicate with my uncle in the island of Madeira, Portugal, wonderful…”

“I loved making a voice call, it’s very good”

“Wow, you can’t imagine how happy I am knowing that I have more facilities to use MaxiAmigos where I have made many friendships, cheers”

We have also received several requests to add video, and so we will add video very soon.


What have you used for signaling?

We used the existing XMPP infrastructure we already had in place for our IM solution, and we added a simple protocol to synchronize the sequence of steps necessary to establish the WebRTC connection, so that any of the two parties in a IM session could start a WebRTC connection at any time.

We found that it is much easier to synchronize this sequence of steps if, as soon as one of the two parties starts a conversation, we disable the UI of the other party (so that he cannot start another conversation), until the first conversation is either finished or canceled. In case both parties start a conversation simultaneously, a simple criteria can be used to disambiguate, for example highest user id.


Anything you needed to add to your existing backend to support WebRTC?

One of the first issues we ran into while integrating WebRTC, was that we could not make a voice call between two computers on different networks. By reading the discuss-webrtc group, we learned that it is sometimes not possible to establish a direct connection due to strict firewall configurations (10 to 15 % of the cases, according to some tests reported in the discuss-webrtc group). In these cases, a TURN server can act as a relay and successfully establish the connection. However, there are no public TURN servers, because of bandwidth costs, and so we had to deploy our own TURN server in order to support WebRTC.

Fortunately, there are several open source TURN server implementations. In particular, the rfc5766-turn-server is a great implementation. The author is very responsive in the discuss-webrtc group, and has made many additions to make it very easy to use with WebRTC.


Given the opportunity, what would you change in WebRTC?

When you create a WebRTC peer connection in javascript, you pass the credentials to authenticate with your TURN server as follows:

var pc_config = {'iceServers': [{'url': '', 'credential': 'mypwd'}]};

var pc_constraints = …

var pc = new RTCPeerConnection(pc_config, pc_constraints);

The problem is that potentially, somebody can copy your credentials, and use your server to relay calls from another site, incurring in bandwidth costs for your server.

A simple solution for this problem could be to have the WebRTC navigator send the domain from where the WebRTC call is originated. The configuration in the TURN server would have a list of domains allowed to relay calls. If the call is originated from a domain that is not allowed, the call is rejected.

Of course somebody really determined to use your server, could build a modified version of the WebRTC navigator, and hard code one of the allowed domains. This drawback is mitigated, by the fact that doing this modified version is not a trivial task, and most significantly, he would also have to convince all his users to install and use his modified version of the WebRTC navigator. And that would be a much harder task to accomplish.

This could be a solution that is simple to implement, and that would make it easier to deploy a TURN server. However, it might not be feasible to implement because it would not comply with the TURN standard.

Fortunately, some TURN servers have made several great additions to solve this problem. In particular, the author of the rfc5766-turn-server added PostgreSQL and MySQL authentication, short-term credentials, and an authentication mechanism based on short-term credentials and a shared secret.

All these additions have made it fairly easy to deploy a TURN server. And so, solving this issue, would be really just something nice to have in order to make it even easier to deploy a TURN server.


What’s next for MaxiAmigos?

We are very focused on growth right now. Most of our users are from São Paulo, Brazil, and so our short term goal is to become the most popular socializing/dating site in São Paulo, Brazil.

We also have several exciting new features in the works right now, like virtual activities, and live events.

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.

You may also like


Your email address will not be published. Required fields are marked

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}