1. We have changed the name of our core product Flashphoner RTMFP SIP Gateway 2.1
to Flashphoner Web Call Server 2.1

2. Preview with WebRTC support –
Flashphoner Web Call Server 3.0 WebRTC HTML5/Websockets preview – has been released.

WebRTC – is a browser technology similar to Adobe Flash Player
featuring VoIP functions. The key difference is that WebRTC doesn’t function as a third-party plug-in
(Adobe Flash Player), but as an integral part of the browser.
To put it in simply, it is Javascript/HTML5 API for VoIP.

WebRTC – is a high-flying, future-oriented technology.
For the moment being, WebRTC stack has been implemented for production usage only in the latest Google Chrome versions.

Please, try out Flashphoner Web Call Server 3.0 WebRTC preview.
This version supports both RTMFP and WebRTC in one browser phone.
We took care to enable simultaneous operation of these options from the same Javascript/CSS interface.

WebRTC protocols are also used as HTML5 Websocket protocol. It means that you have two implementation options: one entirely based on Adobe Flash Player, the other – on Javascript/CSS/HTML5.

Take the following steps to try it out:
1. Download
2. Install
3. Switch on WebRTC and configure the calls on your Asterisk server
4. For further information and limitation of WebRTC use with Flashphoner Web Call Server 3.0, please refer to our WebRTC documentation.

What goes next?

WebRTC performs media streaming via the SAVPF(SRTP+RTCP feedback) with G.711 and VP8 codecs.
Currently, there are few devices and softphones supporting these protocols and codecs.
We are trying on WebRTC connection of a browser with any SIP device no matter whether the third-party device supports SAVPF, VP8 or not.

We hope you find the information useful.
For more information, contact as at the address specified on our website: flashphoner.com

Best regards
Flashphoner team.

If you have any questions, please feel free to contact us via ticket-system and specified emails on the website.
Flashphoner Team

Main improvements:

- Full support of partial reliability for both, server-side and client-side.
Partial reliability minimizes latency and ensures a good quality of audio and video.
- Improved audio and video streaming quality
- Improved server stability

If you already use version 2.0, we would recommend you updating to the released 2.1 version.
The update process will not take long.

You can download the update files and get additional info and instructions here

Principal difference between these two protocols is how they communicate over the network. RTMFP is based on UDP, whereas RTMP utilizes TCP. This change gives a number of specific advantages for audio/video delivery in real-time. While most of the products with similar functionality are still using RTMP, we’ve made the transition and have got some impressive results.

At the beginning we worked a lot with Flash Player and Wowza Media Server. All synthetic tests showed great results, but we encountered a problem in live environment – growing latency. After further investigation and analysis we came to the conclusion that main limiting factor was the RTMP protocol itself. And the reason for it is in underlying TCP which, being a reliable protocol, asks for every packet to be delivered in strict order. So growing latency was the price for perfect TCP reliability which is not required for VoIP communications in general.

What is the latency?

It’s a delay in communication when one user hears another only after seconds. During our tests of RTMP protocol in live environment this delay was reaching 4 seconds in average quality network which ruined the quality of communication. Most of professional VoIP solutions utilize UDP protocol for media streaming to reduce latency. And this latency was the last frontier before creation of a full featured softphone based on Adobe Flash Player, as it already has all other needed features (ability to capture, publish, playback media; mainstream codec support, echo cancellation, jitter buffer).

Now about the products.

Flashphoner RTMFP SIP Gateway

This is the gateway between Flash Player and SIP environment. It allows you to connect to any SIP server (Asterisk,OpenSIPs etc.), make and receive calls from PSTN/mobile phone and from your flash-based browser softphone.

So you will not only be able to call from the Click-to-Call widget to mobile phone, but you can also call FROM mobile phone to the user on the website! You can also send text messages (SMS) here. If your SIP server/provider supports sending and receiving text messages, you can send them from the browser to mobile phone, as well as from the mobile phone to your browser softphone. Usually this functionality is provided by full-featured IP Multimedia System (IMS) based on 3GPP standards.

Flashphoner RTMFP Media Server

This Media server is intended for creation of simple flash-to-flash video chats and video conferences. There are many platforms providing similar functionality out there, but most of them are based on RTMP protocol and, therefore, suffer from growing latency if there are users with imperfect connections. You can see that this issue is quite common for RTMP based chat programs if you visit their support forums. Flashphoner Media Server resolves this issue by using RTMFP protocol based on UDP. Which makes it a better option for professional video chat solutions.

Please note that we are not providing any peer-to-peer solutions currently. From our experience, when we worked on a project similar to Chatroulette, peer-to-peer connections were successful only 10% of the time. All other connections were going through the server. The reason is in the amount of NATs and Firewalls in the global network, which often do not allow P2P connections. So at this moment our server doesn’t not have P2P functionality. But if you need professional flash-based video chat that works through the server, Flashphoner RTMFP Media Server is your best choice!

Among other nice features of our Flashphoner RTMFP Media Server are extensibility and integration options. We are using Java for implementation of server processors which means that you can use all the power of this platform for database integration, communication with third-party web-services, protocols etc.

Specifications

Flashphoner RTMFP SIP Gateway
- Codecs: G.711, G.729, Speex Wideband, H.263, H.264, Sorenson Spark
- Protocols: RTMFP, SIP (RFC3261), RTP
- Instant messaging: RFC 3428
- Transfer, Hold: RFC3515
- Call recording
- Javascript API
- Client application – Javascript Phone (open source, ready for customization)

Flashphoner RTMFP Media Server
- Protocol: RTMFP
- Codecs: G.711, Speex Wideband, Nelly Moser, H.264, Sorenson Spark
- Commands: connect, disconnect, publish, unpublish, play, stop
- Extensibility: ability to use Java on the server side, customized client/server invoke methods

Test results

As we mentioned above, RTMP (TCP based) server will try to maintain a 100% packet delivery rate even if there is a network lag. This may cause a severe latency, since server has to wait for every missing packet before playing the next one. More missing packets – higher accumulated latency in the audio/video stream. If we try to drop packets programmably to keep the stream in real time, we will hear significant sound deterioration. This is confirmed by our tests with different packet loss percentages (“Linux netem” and “IFB” utilities).

Under the same network conditions RTMFP server works without increased latency and very little sound deterioration compared to RTMP server case. In UDP based communications one UDP packet has one audio frame. In this case even a loss of a few packets is not a real threat to overall quality of the stream. Things are a bit different when you are streaming video. In this case some UDP packets carry video key frames and if they get lost it will produce picture “artifacts” during decoding process. But this does not increase the latency and, if the network lag goes away, your picture quality will improve automatically.

Also there are special parameters in the NetStream API of the Adobe Flash Player that allow you to control reliability of the UDP packet delivery for audio, video and data individually.You should always set “reliable=true” for data as it carries all SIP signalling information, instant messages, call control parameters. But for media streams you can variate between true/false depends on the network quality and your requirements for picture/sound clarity. For example, you can set “audioReliable=false” and “videoReliable=true” simultaneously and get acceptable quality communication in majority of the networks. Thus, based on our test results, we can say that RTMFP protocol significantly improves latency/quality ratio of flashVoIP communications. This protocol can be recommended as a platform for development of web-based applications that utilize real-time audio/video communication.We hope that this information gave you a better idea about our products and their functionality. If you have any further questions or willing to give us some feedback, please contact us at support@flashphoner.com

Thanks!

This is new generation of Flashphoner product.
Our team did a great job and made two huge improvements:
1. Support of RTMFP protocol, which allow you make calls from browser with really miniature latency.
2. Run away from Wowza Media Server and came to our own RTMFP Media Server, which makes whole product more compact

Please try our beta version and send your feedbacks to support@flashphoner.com
You can download it here.

Please check it here.

Flashphoner provides Flash-to-SIP gateways for high quality Flash-VoIP communication. Flashphoner provides a gateway between RTMP and RTMFP to SIP. Flashphoner focuses on scalable low latency products.

SoliCall provides products for audio quality improvement on both server-side/network filtering and client-side filtering. SoliCall offers both OEM products and stand-alone plug-and-play products.

“Sound quality and low latency is the key parameters for comfortable web calling. We are excited about partnership with SoliCall experts. Our common aim is to provide best quality sound and maximum low latency web communications”, said Pavel Ismailov, CEO of Flashphoner project.

“This cooperation demonstrates the importance of standardization in VoIP. Standardization was a key enabler to this new offering”, said Moses Benjamin, Director of Marketing for SoliCall. “From this day, Flash-based solutions will enjoy high quality audio, free of echo and noise.”, Mr. Benjamin concluded.

***
About SoliCall Ltd.
SoliCall Ltd. is a privately-held company. SoliCall’s goal is to raise the quality and standards of any audio conversation. SoliCall stands for communicating better by improving existing means of communication on any platform.
www.solicall.com

About Flashphoner
Flashphoner project was founded in 2009 by groups of professionals in web development.Flashphoner team has a strong background in the field of design and development web-video platforms and voice browser solutions.
www.flashphoner.com

In this article, we want to explain situation regarding HTML5, SIP, WebRTC phone solution for Windows, iOS, Androind, iPad, iPhone.

Some peoples reads tech news and thinks that future is already here, and HTML5 is a standard, which gives us possibility to create real time audio/video communications in desktop or mobile browsers like iPhone iPad devices.

Unfortunatelly it`s not true.

We would like to explain technologies and describe its perspectives and restrictions for now.
In short – the HTML5 phone is possible to make and it will work everywhere, but not right now.
It will be available in 6-12 months(but not for sure) depending on activity of browser’s vendors.

Several terms:

HTML5 is a new standard for browsers, including some additional tags like audio and video.
SIP – session initiation protocol aka rfc3261
WebRTC – open source framework for browser that is able to send or receive encoded audio and video over network.

So, lets find out what is the “HTML5 phone”, and what technologies do we need to create it.
First of all HTML5 phone is not really “HTML5″, because nobody can create SIP phone using pure HTML5.
Surprised? But it is true.

Media traffic:
1. HTML5 can not encode audio+video.
2. HTML5 can not capture audio+video from microphone and camera.
3. HTML5 can not send audio and video data over TCP or UPD protocol.
4. HTML5 does not support Echo cancellation

What about SIP signaling:
HTML5 can not communicate with any SIP devices by TCP and UDP.

Maybe this list is not full yet, but it is quite enough to understand that HTML5 phone is impossible for now.
Yes, HTML5 standard supports playing video over HTTP and playing audio/video files, but that’s all current standard can do.
It`s not designed for any communications, and we think that the standard will never support real-time features,
because it is just HTML(Hypertext Markup Language) version.

Although… we still can create some type of “HTML5 phone”. But we need to add some technologies.
We will need 2 modules: 1) Signaling module 2) Media module
So, what name should our HTML5 phone have?

In fact, HTML5 will do NOTHING or almost nothing in the phone application.
Everything it will do is playing “din-don” for incoming call. It is just playing a ringtone file.
So… we will put “HTML5″ keyword at the end of our solution name, or even delete it.

Lets check what words do we need to put at first. There are two new technologies:
Websocket and WebRTC. “HTML5 phone” is impossible without it.

Websocket is a protocol designed for Browser-Server communications over stateful TCP connection.
What is the difference between the Websocket protocol and plain HTTP? HTTP is a connectionless protocol. It does not keep connection. Browser creates new connection for every HTTP GET/POST request.
If you need to implement real-time data application, you can use HTTP, but plain HTTP gives VERY high traffic overhead for those applications.

For example, you need to receive stock prices from server every second. In case of plain HTTP protocol, you need to initiate a new HTTP request to get changes every second.
If your requirement is 20 ms latency, HTTP will give you too high overhead in terms of traffic and CPU resources.

Websocket uses 1 persistent TCP connection for all incoming and outgoing traffic.
Websocket works over TCP. This is reliable protocol. So, all the data will be reliably delivered.

Webscocket is the only way to implement low-overhead SIP signaling for browser application. Maybe, you will find solutions, where SIP signaling is implemented over HTTP.
It will be a PHP server that maintains the SIP state machine and receives HTTP requests from web-browser, but it is many times worse than Websockets.
Thus, Adobe Flash Player has RTMP protocol that can do the same. But, in this article we tell about Flash-free application as far as it is.

Websocket protocol is supported in the latest Chrome, Mozilla, Safari, IE 10 browsers and has Javascript API to manipulate websockets.
For example, you can open connection or send/receive data from pure Javascript code.
Thus, to implement SIP signaling we should have Javascript SIP stack, that works over the Websocket protocol.

So, our HTML5 phone solution should be called Javascript SIP Websocket HTML5 phone or shortly: “JS SIP Websocket HTML5 phone”.
Is it all? Not exactly.

Unfortunately, SIP over Websocket protocol is not supported by current VOIP vendors and millions of VoIP switches all over the world.
It means if you made Javascript SIP Websocket HTML5 phone, your phone would not work with 99% of the SIP vendors, because vendors do not implement this
protocol in their products. Why?

There are two reasons:

Draft “SIP over Websocket” is not in RFC state. It is just draft. It is not a standard.
SIP vendors and providers are very conservative. Many SIP providers support only UDP protocol for SIP, and do not support TCP and Websockets.
Register on 10 SIP providers sites and try to SIP register over TCP transport. You will mostly see response “Unavailable”.
So, according to this and other reasons, Websocket protocol is not supported by wide range of SIP engines.
So what is a solution?

We can solve this problem using intermediate server software, that converts Websocket SIP requests/responses to UDP/SIP requests/responses and vice versa.
This solution’s name is Websocket SIP Proxy Server, that supports Websocket+SIP specification and pure SIP specification to get compatibility with
the vendors which does not support Websocket over SIP.

In fact, this proxy server will convert Websocket/TCP based reliable protocol to unreliable UDP. According to SIP rfc3261 specification, proxy server must
handle messages statefully. So our server should not just forward messages, but also it must support separate transactions: Websocket SIP client – Websocket SIP proxy
and Websocket SIP proxy – SIP vendor and provider and maintain the state of transactions.

So, our solution should be called “Js SIP Websocket HTML5 phone + Websocket SIP proxy”.

Ok, we have included signaling and intermediate proxy server to our HTML5 phone solution. Also HTML5 is used in the solution to play sounds. But it is still not working solution, because browser does not support streaming. Streaming is an audio/video capture, encoding, sending over transport protocol, receiving and playback, different codecs, Echo cancellation, bufferization.

Of course, Adobe Flash Player has all these features, required for streaming:

- Audio/video capture and playback
- H.264, Sorenson spark
- G.711, Speex, Nelly Moser
- Acoustic Echo Cancellation
- RTMP/RTMFP transport protocols for media relay
- But we still want to avoid Flash player and get pure browser solution without any browser plugins. So let’s move forward. Alternative streaming technology for Flash Player is the WebRTC. This is streaming framework designed for browser vendors.

At the moment, there is no browser, that officially supports this build-in framework.
That means your users can enable WebRTC function in some browsers, but these settings are turned off by default and experimental for now.
This technology is promoted by Google and Mozilla and has experimental support in Chrome and Firefox browsers. You need to change some settings to enable it.

WebRTC features:

- Audio/Video capture and playback
- iSAC/iLBS audio codec
- VP8 video codec
- SRTP
- Acoustic Echo cancellation
- Video Jitter Buffer
- Similar features represented in Adobe Flash Player 11.

So, what is better: Adobe Flash Player or WebRTC?
Let’s consider pros and cons:

WebRTC

+ iLBS audio codec is VoIP standard
+ VP8 is a well-suited video codec that designed for web video relay in real-time mode
- SRTP – Secure Realtime Transport Protocol is open protocol, that described in RFC. Many vendors does not support Secure RTP. Probably, we need to convert SRTP to RTP and vice versa for vendors, which do not support the SRTP protocol.
- VP8 is not compatible with products of many VoIP vendors. So, we probably will need to implement server-side transcoding between VP8 and H.264(it is VoIP video standard currently).
- WebRTC is not supported by 99% of browsers. Only one browser, that supports this technology, is enabled in experimental browser Chrome Canary.

Adobe Flash Player

- Browser plugin.
If Adobe Flash Player was an open source and positioned like WebRTC,
it would be an excellent solution. But Flash player is a plugin, proprietary plugin for browser.
So, developers, end users have dependency from Adobe while using Flash Player.
- Incompatible protocols.
RTMP and RTMFP is well-suited protocols for media relay, but there are proprietary protocols and we can not communicate over such protocols with any VoIP vendor.
We need Flash-VoIP gateway to send and receive media data between RTMP/RTMFP and RTP(Realtime Transport Protocol).
+ H.264 encoding/decoding playback support, because H.264 is a robust standard for video in VoIP industry, and it gives high compatibility with wide range of VoIP systems.
+ G.711, Speex codecs are standards for VoIP too.
+ High availability. It works on 99% of desktop browsers where Adobe Flash Player is installed and Adobe Flash Player has auto-updates since 11.2 version.
+ Robust transport protocols as RTMP/RTMFP, tested in millions applications.

Thus, WebRTC is perspective technology.This technology can take a place of Flash Player for Browser-VoIP communications in future.
Therefore, we would like to see such features in WebRTC:

- G.711, G.729 audio codecs
- H.264 video codec
- Non-encrypted RTP support
- Compatibility with list of top browsers, such as IE, Chrome, Mozilla, Safary, Opera.
But WebRTC is objectively worse as Browser to VoIP communication platform than Flash Player and is not suitable for production usage for now. This situation will be changed if top browser vendors release WebRTC support. We should wait for a while.

What about mobile devices?
Nothing. There is no difference, where browser is installed – on desktop platform or mobile device.
This browser must support WebRTC for streaming.
There is one browser we know that can do it. It is Chrome Canary.
If you compile Chrome Canary browser with WebRTC support for mobile platform it will work. But we have not tested yet. So, in the world of mobile technologies we have the same situation. We are waiting for mobile browsers with WebRTC support…

So, what name will our solution have in the end?
Solution name is: “Javascript SIP Websocket HTML5 phone + Websocket SIP proxy + WebRTC”.
Too long, isn’t it?
But we can not exclude any element of this name. This is the real name of HTML5 phone. Now, you aware that “HTML5 phone” does not exists, and that HTML5 phone is a complex solution that is based on top of several technologies.

How can we use this solution for production right now?

There is one trick.
We can exclude WebRTC from this scheme and replace WebRTC with Adobe Flash Player application. This application will provide audio and video streaming and other features which supported by WebRTC. Yes, in this case we are Flash-dependent again. But this solution is closer to “HTML5 phone dream” and to production than WebRTC.

Feel free to try our solution below.

We are glad to introduce you Javascript SIP Websocket HTML5 phone + Websocket SIP proxy + Flash solution.

RTMFP is protocol based on UDP, developed by Adobe for low-latency streaming.

Flash platform uses RTMFP for peer to peer connections and media relay between  Adobe Flash Player instances. This feature supported since Flash Player 10.

RTMP protocol is implemented in many streaming solutions like Wowza Media Server, Flash Media Server and other servers designed for streaming and broadcast targets.

RTMP is good and open protocol. You can find RTMP specification on Adobe website. Anybody can talk about lacks and errors of that specification, but anyway it gives good start to understand RTMP and implement own streaming server.

RTMP has one major lack due it’s nature. This is the latency.

If your service just play video stream, you can admit latency 2-3 seconds (up to 10-60 seconds).
This is normal latency for on-demand streaming, but that`s not good for realtime communicating cases.

For example:

A bank has web-camera, which monitor cashpoint of this bank.
We assume that latency is 1 minute.
So, security department watches situation with 1 minute latency.
Somebody can steal cashpoint, but security department will know about stealing just after 1 minute.

Quite critical, isn`t it?
Yes, that case is very synthetic… but many a true word is spoken in jest, right?

Now lets take simple usually call.

You have business conversation and your partner hear you with 2 seconds delay.
Is it suitable? May be. Is it convinient? No.
Comfortable conversation in IP telephony is about 200 ms delay.
That how you hear your friend from your mobile phone.

So, why RTMFP?
Because latency is VERY important for communicating, and RTMFP decreases it greatly.

RTMP vs RTMFP

Lets imagine that you make call over RTMP, and your connection has lags.
Then your webphone will retransmit audio packets which falls in lags, and latency will grow,
because we will send next packet only when previous packet will be delivered well.
That mean if previous packet will fall into a lag, it will be sends again and again,
until it will be delivered well.

Such mechnism guarantee you that ALL packets will be delivered, and exactly in given sequence
as it was sent. This is very good for sending files, but not very good for realtime communicating.

Because, more lags – more latency.
That is how TCP works, and that is how TCP-based RTMP works.

No additional latency here. But packet lost is suitable.
And that is the main differences between RTMP and RTMFP protocol.

What else

• RTMFP is encrypted protocol. It uses AES and other cryptographic algorithm to secure audio and other data going through RTMFP.
• RTMFP is peer-to-peer oriented protocol, but we use it as peer-server-peer in RTMFP to SIP gateway project.

RTMFP alpha is RTMFP to SIP two-way media gateway, which translates Flash RTMFP protocol to
SIP for signaling puporse and RTP for media. So, you can make and receive audio/video calls to/from softhphones,
hardphones, GSM and other SIP endpoints on top RTMFP protocol to get lower latency for professional communications.

You can try it here.