Realization of audio calls from web and mobile clients (RTMP, RTMFP, WebRTC)


Good day, Khabrovchane.

I want to share with the community my experience in implementing audio calls from the web and mobile clients in Cisco UCCX. Perhaps he will help someone in the future or in the present.

So, once, before me the task was to organize audio calls from the web and mobile clients on to Cisco UCCX. Everyone knows excellent services like zingaya, but the customer clearly limited the use of third-party services.
The task boiled down to writing a client, selecting SBC, and forwarding the signal from the client to Cisco Call Manager.

My analysis stopped me on three ways to implement the requirements:
  • RTMP clients written under Adobe AIR and Flash + mod_rtmp to freeswitch as SBC
  • RTMFP clients written under Adobe AIR and Flash + RTMFP2SIP gateway from Flashphoner
  • WebRTC clients written in js + Mobicents SIP Servlets

RTMP client for Freeswitch


  • Deployment Speed
  • Client Development Speed
  • Easy integration with other IP PBX
  • MPL license

I put the description of this option in first place, as the most promising, which was implemented.
For other options, demos were written, but the first one went into production.

Deployment Speed

It is phenomenal, especially for companies that already use Freeswitch in their work. It is enough to uncomment the line endpoints / mod_rtmp in modules.conf, compile the module (make mod_rtmp-install in src),
correct the configuration file in $ FSPATH / conf / autoload_config / rtmp.conf.xml (namely set ip, port, dialplan),
load installed module (load mod_rtmp in fs_cli) and open the port in iptables.
That's it - you can start developing the client.

Client Development Speed

Freeswitch contains a demo client written in ActionScript3 with JS CallBacks (clients / flex).
For this task, an Adobe AIR client was written that implements the NetStream control logic and callbacks from Freeswitch, such as login, logout, call, notify, and more.
In short, the work is as follows:
Freeswitch assigns a uuid channel to each NetStream, and then bridges all calls through itself. The only problem I caught was the inability to use the TTS and ASR (connected via unimrcp) MRCPv2 protocol when calling from an RTMP client.

The time spent on development is a week, two hands (that is, one person or two one-armed encoders).

Thanks to Adobe AIR, the client’s shelf was: desktop-client, tablet-client for iOS and Android, mobile-client for iOS and Android, and Flash-client.
There was only one code, the only difference was in layout and icons, which made me and the customer very happy.


  • Use of TCP and instability of work on 3G channels
  • No noise reduction
  • Support only Speex
  • Communication between two RTMP clients - SIG and RTP goes through Freeswitch

Use of TCP and instability of work on 3G channels

As practice has shown, this client is stable on adsl, lan channels and wifi. On 3G, it behaved unpredictably (as well as MTS 3G coverage). In any case, he kept connections, and the maximum that was corrupted audio.

No noise reduction

Everyone knows the problem, thanks to Putin for this Adobe.
Until they decide for desktop clients, mobile clients use headphones.

Support only Speex

If the remote side is IP PBX, then Freeswitch will take over the transcoding.
But between the RTMP client and Freeswitch while Speex goes.
Mod_rtmp needed to support G.711.

Communication between two RTMP clients - SIG and RTP goes through Freeswitch.

For communication of 2 RTMP clients you always need a server.

RTMFP client for RTMFP2SIP


  • Product Supported
  • There is a free version for 10 audio connections
  • UDP


  • Money of non-Orthodox is worth
  • API implemented in the form of swc, problems with loading to mobile clients

This product was also considered promising until I failed with the
addition of functionality to Adobe AIR Mobile.

For Desktop and Web clients, this product has serious advantages over the first in the list:
1) UDP-based protocol
2) Support for H.264 and G.711.

The behavior of SIG and RTP is absolutely identical to the first option (only UDP instead of TCP).

In general, due to its incomplete suitability for the task, I only had enough for its installation,
configuration and test call. It is quite trivial and well described by the developer.

A demo client was made on Flash - the development period is 3 days.

WebRTC clients written in js + Mobicents SIP Servlets

To be honest, I had the highest hopes for this.

I had sufficient experience with Mobicents, so WebRTC support in version 2.0.0 FINAL was good news for me.
I seriously dreamed about video and audio calls without plug-ins and web browsers, but fate turned out to be cruel.
I will not describe WebRTC technology, it can be easily found in the search for Habr.
I’ll only note one thing that I need to get a tattoo: “Do not use drafts”.
Preferably on the forehead, preferably in the mirror image, so that when shaving in the morning, I would always recall this brilliant idea that came when the implementation of the siprec draft for Broadworks did not work with the implementation of the siprec draft for Cisco (because Broadworks used siprec 04, and Cisco siprec 11) .

If it’s interesting, then only Chrome build 24 worked more or less stably, Firefox refused at night, and experimental Ericsson Bowser gave me both an iPad and my Nexus S.

Therefore, I will write hypothetical advantages and disadvantages.


  • When calling between two WebRTC clients (provided they use the same codecs), SIG goes through the SIP proxy, but RTP directly.
  • No plugins (ideally)
  • The elegance of integration into portals
  • Using JBOSS as an AS for Mobicents


  • Draft
  • Half of browsers do not support
  • The half that supports implemented a couple of codecs

A demo client was made that hung up in Ericsson Bowser and worked only in Chrome build 24 - development period - 3 days.




I hope this article was useful to you and saved you time when choosing one of these technologies.

Also popular now: