Tuesday, 30 May 2017

Extending and enabling BigBlueButton Collaboration Platform for External SIP/Mobile Users

BigBlueButton is a known Open Source multi-party Video Conferencing platform. For all good reasons it made it to my software stack for our Smart Glass based Remote Collaboration platform.

First, some background - It all started couple of years back when BigBlueButton (BBB) was at release 0.9 and they had discontinued the native android client that was developed for 0.8 version of BBB. For the android based Smart Glass platform of ours, native android client was crucial, so i decided to use 0.8 version of BBB and built Smart Glass based client on the same lines as 0.8 version of BBB.

The prototype stage of our product was over soon and time was for serious business. Back in the prototype phase, we didn't worry too much about getting all features - including voice conference to work from the android device.  It was now a must-to-have feature and demanded focused effort.

So got an opportunity to take a deep dive into the architecture of the BBB platform - mainly voice conferencing engine. BBB uses "FreeSWITCH" opensource telephony engine for voice communication across the networks. I basically had couple of options -

1. Get BBB 0.8 voice conference to work from outside/external client
2. Upgrade to BBB 0.9
3. Upgrade to BBB 1.1 ( latest version )

Of these #3 was ruled out since it had moved long long away from 0.8 version and does not have android client from BBB and integrating 0.8 android client with this would have been a huge challenge. So considering the timelines, choice was to be made between #1 and #2.  Considering the newer version and few enhanced abilities in 0.9, decided to give it a try. It was a journey in itself ( and some great experience ) , getting the 0.8 android client to work with 0.9 version of BBB.  Many internal things were changed from 0.8 to 0.9 and finally was able to connect to BBB 0.9 server from Android.

The only thing remaining in this BBB 0.9  with Native Android client was getting voice conference to work from outside/external client. By default, since FreeSWITCH is prone to external attacks, it is usually packaged and run as standalone service and accessible only on the loopback/local IP (127.0.0.1). BBB server apps access FreeSWITCH locally.  Getting it exposed to allow external clients ( AKA SIP Clients ) wasn't trivial. The idea was simple, run the FreeSWITCH service on the public IP. But getting it to work by both - local BBB apps and external mobile/SIP client was not straightforward, and possibly getting this to work on  Amazon Web Services (AWS) was additional challenge.

If one googles on this challenge, there are lot of references, all talking variations of configurations, ideas, thoughts for various versions of BBB and FreeSWITCH, needless to say, nothing worked for me.  But one thing was common - all talked about same set of configuration files.  While no combination of configurations worked entirely, all the way along  i was certain that I was on right track since logically it was sounding correct.  Initially the android client voice connection was "Timing Out", at some point of time, I was getting "Connection Refused", later the client was able to connect, but "automatically disconnecting" after 30 secs, later "one way voice call" and finally it all came through fine. It was able to connect Voice Call from android and have a two way communication.

Several resources and tools helped all the way along, and many thanks to BBB Developer Google Groups. Last, but not the least, was the X-Lite SIP Soft Phone client. The detailed messages captured and logged by X-Lite SIP Soft Phone were really helpful nailing down the last bits of this challenge.

Long story short, I now have a customized BBB Android client that works seamlessly with BBB 0.8 and 0.81. Here are the set of configuration files with settings that worked for me to enable BBB Chat, Audio and Video conferencing (both web and mobile ) on a Ubuntu 10.04 Linux instance inside a Virtual Private Network ( VPC ) on AWS.  I will soon fork the BBB repositories (for Android client) and publish these updates to the community.


-------------------------------------
*******  BBB 0.80  ********
-------------------------------------
Red5 Configuration files
-------------------------------------
/usr/share/red5/webapps/bigbluebutton/WEB-INF/bigbluebutton.properties
> change esl.host = internal ip of the server ( not 127.0.0.1 )

/usr/share/red5/webapps/sip/WEB-INF/bigbluebutton-sip.properties
>  change sip.server.host = internal ip of the server ( not 127.0.0.1 )

FreeSWITCH Configuration files
-----------------------------------------------
/opt/freeswitch/conf/autoload_configs/event_socket.conf.xml
>  change value of "listen-ip" param to internal ip of the server ( not 127.0.0.1 )

/opt/freeswitch/conf/vars.xml
>  delete the line that defines value for variable local_ip_v4   i.e.  <X-PRE-PROCESS cmd="set" data="local_ip_v4=127.0.0.1"/>
>  confirm that "external_rtp_ip" and  "external_sip_ip" are set to "stun:stun.freeswitch.org"

/opt/freeswitch/conf/sip_profiles/external.xml
>      change these params to have external_rtp_ip and external_sip_ip respectively.

<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
<param name="ext-sip-ip" value="$${external_sip_ip}"/>





-------------------------------------
*******  BBB 0.81  ********
-------------------------------------
Red5 Configuration files
-------------------------------------
/usr/share/red5/webapps/bigbluebutton/WEB-INF/bigbluebutton.properties
> change freeswitch.esl.host = internal ip of the server ( not 127.0.0.1 )

/usr/share/red5/webapps/sip/WEB-INF/bigbluebutton-sip.properties
>  change bbb.sip.app.ip = internal ip of the server ( not 127.0.0.1 )
>  change freeswitch.ip = internal ip of the server ( not 127.0.0.1 )

FreeSWITCH Configuration files
-----------------------------------------------
/opt/freeswitch/conf/autoload_configs/event_socket.conf.xml
>  change value of "listen-ip" param to internal ip of the server ( not 127.0.0.1 )

/opt/freeswitch/conf/vars.xml
>  delete the line that defines value for variable local_ip_v4   i.e.  <X-PRE-PROCESS cmd="set" data="local_ip_v4=127.0.0.1"/>
>  confirm that "external_rtp_ip" and  "external_sip_ip" are set to the public IP of the server an not "stun:stun.freeswitch.org"

/opt/freeswitch/conf/sip_profiles/external.xml
>      change these params to have external_rtp_ip and external_sip_ip respectively.

<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
<param name="ext-sip-ip" value="$${external_sip_ip}"/>


Next steps, get voice conference to work for BBB 0.9 and await BBB 1.1's awesome HTML5 Client to start supporting two way Camera / Video sharing, again exciting times ahead.

Friday, 10 March 2017

Modern Integrations - Need of ESB like Mule

I recently architected a Smart Glass based AR platform. The idea was cool, build a secure, lightweight, reliable, configurable and performant platform for enabling Smart Glasses to connect with enterprise systems. Idea was to allow business users - hands on task force - to work efficiently, execute business processes while keeping their hands free, from various gadgets, scanners, blue-tooth devices etc.

So the middle ware platform was the key component that could help achieve this goal. As a version 1.0 , I architected the entire solution from scratch, building REST based web application platform with JWT tokens securing the services. Few customization hooks allow easy extension of the platform and there we had, a platform that fulfilled the needs and a demoable solution was in place. By design this lightweight/stateless/cache-enabled platform was also scallable - tested upto 300 concurrent users on 4GB/dual core CPU machine with response times as low as 300ms. Perfect.

As the idea/solution saw light of the day, and more and more enquiries started coming in, a natural progression was initialised to move this platform to a more scalable architecture. An ESB based platform was the way to go. Looking at the popularity, availability of the community version and several other factors, MuleSoft was chosen as platform of chioce.  Idea was to leverage the infrastructural capabilities of the ESB - like scaling, HA, performance etc. and focus on enhancing our platform.

Getting started with Mule was pretty straightforward. Downloaded Anypoint Studio, referred to the excellently documented details with examples, some tutorials, some videos online and first application deployed.Tested, works like a charm. Easy.

Challenge now was to make the ESB runtime part of our existing web app based platform and run Mule as a service in the app container. I plan to write a separate technical blog on this one, but in short, the existing documentation helped to good extent. After some r&d and troubleshooting, I was able to embed the Mule Runtime engine inside our web based platform and was able to execute a simple Mule Flow from within this webapp. Woohoo.

It needed some more focused efforts to release first version of our platform on Mule to a respectable stage. Attaching here initial sample flow/s (not disclosing it entirely of course - IP reasons).



Serious work continues to go in enhancing this Mule based platform, several features in roadmap, deployed quite easily on Mule ESB, features like enhanced logging, audit trails, filtering, polling, scheduling and so on.

Awaiting exciting times to come.