Sigapy: a failed attempt to create a product in Paraguay

A little more than a year ago, I created a service which main intention was to provide my fellow Paraguayans living abroad, an easy way to call home using their smartphones. It was not like Viber or Tango app, you could actually call to land lines and mobile phones, and of course between Sigapy users.

There’s no specialized service like this in Paraguay, and I wanted to fill that void with something new and easy to use, and so Sigapy was born. It was conceived as an academical project but soon it started to appear exploitable as a commercial service, but the environment for this kind of business in Paraguay isn’t the best (actually, it’s horrible) and I had to shut it down for my own juridical sake.

Today, I decided someone else can give it a try, because it’s a more or less mature product and can easily be adapted to someone else’s needs.

Check out the videos and the landing page I created. The videos are in Spanish, but the flow can be understood by anyone.

NGS

NGS

UPDATE: with this project, I won a place in the 4th generation of startups of Wayra Mexico. More updates to come in the future posts :).

NGS, or Next Generation Support, is a project that I created to participate in the TADHack event. It is about improving the user experience we have when we call to customer support, and it takes advantage of the new telco technologies we have today, to create a product that tries to fix a rather common issue which is the bad quality in customer support systems.

What NGS has to offer?

  1. Everyone has a smartphone, and there’s an app for everything, why not for a specialized customer support?
  2. It’s really annoying to navigate through the IVR menus. It’s easier to directly go to the option you want, with a click.
  3. It can be completely free, the only thing you need is an Internet connection.
  4. The customer would be able to call from literally anywhere in the world, using Internet, no toll-free numbers at all.
  5. Call center agents can know exactly who’s calling, where is he located, and what does he want, and with this info a better customer experience can be offered.
  6. The customer can take advantage of the current technology, with HD voice quality, chatting, video calling, screen sharing, etc.
  7. The customer can know exactly who is behind the phone, with a picture, an email, a full name, and he can rate the experience he had with the agent.
  8. In summary, improved customer experience from every angle you can think of.

Opensource communication technologies I used

  1. Kamailio
  2. rptengine: this one belongs to the Kamailio project but deserves special mention because it powers the media relaying. Extremely important
  3. SIPjs
  4. Freeswitch
  5. CSipSimple: compiled in library mode, it allowed me to use PJLIB to create SIP apps for Android.

I posted below, a few screenshots of the software, and I’m planning to add more and release the code during this month.

This is a work in progress. The project has only 3 weeks of being alive, at the time this post was written.

Screenshot_2014-06-05-20-33-52 Screenshot_2014-06-05-20-34-00 Screenshot_2014-06-05-20-34-17 Screenshot_2014-06-05-20-34-21 Screenshot_2014-06-05-20-34-32 Screenshot_2014-06-05-20-34-39 Screenshot_2014-06-05-20-35-59 Screenshot_2014-06-05-20-36-15 Screenshot Screenshot-1

 

 

Install mediaproxy-ng on Debian based systems

This is a variation of my original post on how to install mediaproxy-ng on rpm based operating systems.

This one goes for the Debian/Ubuntu users, which are a plenty out there.

1. Clone the repository

2. Install compilation dependencies

3. Go to mediaproxy-ng directory and build the Debian packages

4. Go back to the parent directory. It should contain a series of .deb files. Install them all

5. If everything went OK, a message similar to this should appear on the console:

That is pretty much it, quick and straightforward, maybe because the Sipwise guys love Debian more than any other Linux distribution ūüėČ

Installing mediaproxy-ng

This is a small guide on how to install mediaproxy-ng from sources on RPM based systems like CentOS.

Naming convention

All these “ng” stuff are really confusing and sometimes it’s hard to distinguish the pieces among them.

  • rtpproxy: it’s a media relaying software for RTP packets. It runs as a service and needs to be controlled and instructed using it’s own protocol.
  • rtpproxy module: it’s the Kamailio module that controls the rtpproxy service, from the configuration scripts.
  • rtpproxy-ng module: it’s the next generation (ng) module for Kamailio, based on the rtpproxy module. It serves as a replacement for that old module on newer systems.
  • mediaproxy: it’s another media relaying software, similar to rtpproxy, but older.
  • mediaproxy-ng: despite of its name, it is not the next-generation mediaproxy, but instead, the next generation of the rtpproxy (the service, not the module). From Kamailio, it can be controlled from both the rtpproxy and the rtpproxy-ng modules.

Before you begin: I’m using a x86 virtual machine. This means that you have to change the package names from i686 to x86_64 when necessary.

1. Kernel upgrade: you may not need to do this, so I recommend skipping this step unless you end up with an error like “undefined symbol” when trying to load the kernel module in the last step. In my particular case, I had to do it with my CentOS 6.0 VM.

2.¬†Install development tools: several tools are needed to perform this step. Instead of manually listing them one by one, I would rather save some typing time by just installing the whole package ūüėČ

3. Download the sources: from github

4. Install kernel development headers: this is going to be a kernel module, we need them.

5. A few other dependencies

6. Install mediaproxy-ng

7. Copy the resulting binary to the PATH: the Makefile doesn’t provide a rule for installing the binary.

8. Compile and install the iptables extension

9. Compile and install the kernel module

10. Finally, if everything went fine, you should be able to see something like this:

Click to Call application using webrtc2sip + asterisk

I’ve been working on this for the last few days and I pleased to say that I managed to get through the series of problems that the learning curve entails and now the app is finally working.

My intention was to learn the fundamentals of webRTC and SIP over websockets and I haven’t found a better solution than the one offered by Doubango Telecom. Their impressive job is transforming the way we communicate and I want to be part of that transformation when it finally hit the “standard technology” label.

The purpose of the application is to demonstrate a new way of doing a click to call service. There are a variety of similar solutions with different approaches being the Java applet the most commonly used amongst them.

Well,¬†although this app doesn’t bring any new thing into the world, it certainly serves the purpose of demonstrating a new way of making things. It’s entirely made using HTML5 with the javascript library that made SIPML5 possible.

The app connects to my lab’s Asterisk, via webrtc2sip which deals with the SIP over WS on one side, and SIP over UDP in the other part. The media is also handled by webrtc2sip by translating the SDP profiles and making transcoding on demand.

You can try it here. It is necessary the latest version of Chrome stable or Firefox Nightly. If you don’t meet the minimum needs, the page will just stay there doing nothing. In case you get an error message it’s probably because my server crashed. Please let me know if that happen.

You can browse the javascript code to see how simple it is. I’m planning to turn the project into something more elaborated and then publish the code. By now, it’s too simple to bother ūüėČ

UPDATE:

For some reason, behind very restrictive firewalls the audio is not working properly. I’m working on this to fix it ASAP. Please let me know if that’s your case.

UPDATE 2:

I temporarily deactivated the demo because my server suffered large amounts of hacking attempts. I knew this was possible but I wasn’t expecting this volume.

C# bindings for DWG2000 SMS API

Yes, it’s done and as I promised in my previous post, I am releasing it to the public.

This project started when a local company hired me to make the API support for Linux. It was a success and the sms-client started to work right away. It was not until 2 or 3 months after finishing the project that the idea of making the source code public came to my mind and despite this project may not be a great contribution to the community, it is the first of (hopefully) many.

This particular branch of the project might be specially useful for writing quick VAS software on top of the gateway. It is much easier to write business logic algorithms in C# than in C and in my case, that’s exactly what happened.

Get a copy from my github account

Dinstar SMS API update

I’ve been working very hard in the past few months that updating my blog was relegated to the least of my priorities. It’s a pity, but I had no choice :(.

Back on the track, I came here to present an update of the Dinstar’s SMS API implementation which I started writing some time ago. I paused the project several times mostly because I had no economic reason to support my time on it , but luckily, the situation changed and today the great majority of the API is implemented and working.

I don’t maintain a changelog other than the one on github commit list, but basically, this is what changed:

– Support for API 1.4 and 2.0
– Support for authentication mechanism. (This is partial, check source code)
– Support for RSSI packages
– Support for Unicode strings
– The project is no longer a standalone application, now is a shared library.
– Several bug fixes

The C# bindings are also ready. I will publish the code probably next week.

Check the repo on github

Opensourcing my Clasipar bot

I’m opensourcing, after two years of continued use (:D), a bot for refreshing ads that were published in a specialized classified ads webpage called Clasipar, which is the most popular webpage for this kind of services here in Paraguay.

When you publish an advert on Clasipar, your announcement has a living period of 24 hours. After that, it gets lost among the thousands of other ads in the category it was published in. If you don’t periodically refresh your ad, in a daily basis for example, it will probably disappear completely¬†unnoticed and whatever business you wanted to do, will never be concreted.

This is where this bot comes in. Once your announcement is online, the bot refreshes it daily so you don’t have to worry about this task anymore. You can even publish 3 copies of the same¬†announcement and configure the bot to automatically refresh them at 9am, 1pm and 5pm, for example. This method allows you to get your ad always in the front page of its category.

On September¬†21¬†of 2010, I wrote a post about this piece of software and here’s the entry.

Check out the code at https://github.com/caruizdiaz/ClasiparBot. For usage, take a look to the README file.

Openvpn

This post is a reminder to my brain who lately likes to forget basic things such an iptable rule to allow VPN clients to access internal LAN.

Yes, this afternoon I spent almost an hour and a half to try to figure out what went wrong with my newly installed openvpn. I was unable to access the LAN behind the server and I literally spent 90 minutes looking in the wrong place because my brain betrayed me and I completely forgot about adding a MASQUERADE rule to my firewall.

In my defense, I had problems with the installation, dependency problems and something close to the DLL hell that Windows has. This situation tricked me a lot because I assumed   this was the cause but when I decided to tcpdump the requests I saw the following:

[bash]

# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
17:27:38.136712 IP 10.8.0.6 > 192.168.0.1: ICMP echo request, id 30234, seq 1, length 64
17:27:39.137333 IP 10.8.0.6 > 192.168.0.1: ICMP echo request, id 30234, seq 2, length 64

[/bash]

What! direct ping from tun to an IP visible only from eth0? Then I realized that I missed the:

[bash]

# iptables -t nat -A POSTROUTING -j MASQUERADE

[/bash]

Voila!

[bash]

# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes

17:39:55.968160 IP 10.8.0.6 > 192.168.0.1: ICMP echo request, id 30234, seq 738, length 64

17:39:55.968757 IP 192.168.0.1 > 10.8.0.6: ICMP echo reply, id 30234, seq 738, length 64

[/bash]

I must have installed openvpn at least 4 times before today, but still wasn’t enough to remember the right thing at the right moment. Won’t happen again, hopefully :D.