http://www.webrtc.org/reference/architecture

I would like take this opportunity and introduce you to our good friends at Hookflash who have successfully ported all major components of both WebRTC and Open Peer libraries to BlackBerry 10. To provide a brief overview, WebRTC is an open source multimedia & network stack that supports real-time audio & video. The value Open Peer delivers to WebRTC applications is peer-to-peer (P2P) signalling on the wire, Instant Messaging, Federated Identities and multiple mobile platform support.

So why is this so important?  Well, it enables developers to build rich, compelling, real-time communication applications integrating Social Identities with Voice, Video and Messaging using BlackBerry 10 Native SDK. Secondly, WebRTC is free to use if you decide to commercialize your application. What Hookflash has achieved on BlackBerry 10 really exemplifies the power of our BlackBerry 10 Native Platform to deliver the best communications experience.

I would like to further highlight Hookflash team’s experience in porting both WebRTC and Open Peer stack’s over to BlackBerry 10 platform. Check out my interview with Erik Lagerway (Co-founder) & Robin Raymond (Chief Architect) from Hookflash below:

What is Hookflash?

Hookflash is a globally distributed software development team building “Open Peer”, new “open” video, voice and messaging specification and software for mobile platforms and web browsers.  Open Peer enables an important new evolution of communications; Open, for developers and customers to create with. “Over-the-top” on the Internet, where users control their economics and quality of service. “Federated Identity” so user’s connections aren’t limited by service provider’s walled gardens and operating systems. “Integrated”, as communications become a native function in software and applications. Hookflash founders, lead developers and Advisors accomplishments include; creators of the world’s most popular softphones, built audio technology acquired and used by Skype, built GIPS technology acquired and open sourced by Google to create WebRTC, and engaged in WebRTC standards development in the IETF and W3C.

What is Open Peer SDK and how would this empower BlackBerry 10 developers?

Open Peer enables direct integration of social identities, video, voice and messaging communications for developers building native BlackBerry 10 (NDK) applications. Voice, video and messaging flow Over The Top (OTT) via the Internet.

These services are delivered peer-to-peer (P2P) providing extremely strong privacy, security and encryption. Open Peer enables federated identities and allows developers to leverage and integrate whatever identity model they currently have, so their users remain their users!

What features does Open Peer SDK support?

The Open Peer SDKs are built according to the Open Peer specification. Here are a few of the features we have built into the current SDKs…

• HD real-time video
• Wideband voice and messaging
• Peer-to peer signalling & media transport (greater efficiency, reliability & privacy)
• Federated identity for cross-platform communications (not to be confused with Single Sign-On)
• Encrypted & secure communications

Would HTML5/WebWorks developers be able to leverage this in BlackBerry 10?

Yes. The current SDK is for BB10 NDK developers at this time. However, we have an active “opjs” project under development that will allow interaction between a native BB10 application and an HTML5/WebRTC enabled browser thus allowing web applications to communicate directly with native BB10 applications.

Share your experience in cross compiling your code for BlackBerry 10

Like all platforms, there’s is a learning curve relative to what you are used to until you find yourself comfortable in a new environment, and BB10/QNX is no different. The richness to the platform experience is impressive on the BB10 and made iOS feel somewhat dated by comparison.

Since QNX is a POSIX compliant system, it was relatively easy to get a majority of open source code ported to BlackBerry 10. The QNX GCC-compliant mode has helped us as well.

There were a few wrinkles along the way. The documentation and NDK felt young compared to other more established platforms but that kind of level of documentation grows out of community support and interaction.

One major difference between this project and other platforms has been the phenomenal support that Blackberry has provided us as developers, especially as Hookflash is pushing the platform and technology harder than most with real time communications in audio and video. This was refreshing, We’ve never seen such incredible support for their developer community.

Have you ported over the entire webRTC engine to BlackBerry?

Yes, we have ported all major components of webRTC library to BlackBerry. We will be extending what is offered by WebRTC’s library as well.

How long did it take to port the WebRTC and Open Peer code to Blackberry 10?

When you consider the size of the code-base that had to be moved, and the fact we had not worked on QNX /  Blackberry 10 before, it went relatively quickly. The entire move took us approximately 90 days.

Are you going to commit this work back upstream to WebRTC project?

Yes, our code will migrate back to the WebRTC project. Hookflash is extremely busy on a number of fronts making Open Peer widely available with limited resources.  We appreciate help from other developers. Pushing the WebRTC codebase back upstream will be of tremendous value to the Blackberry developer community. Requests to join our Open Peer BB10 github project are always appreciated.

What APIs did you use to build your application on BlackBerry 10?

NDK’s audio, camera and rendering subsystems and Boost are the bulk of the components. We use Cascades/QT for the sample application.

Do you have VP8 Video working on BlackBerry 10?

Yes. We had some difficulty getting the assembly to compile properly but with Blackberry’s support we were successful in porting an optimized version of VP8 to the BB10 platform. Keep in mind we have tested this mostly on Z devices at this time with limited testing done on the Q devices.

How was your experience relative to working with other platforms and BlackBerry 10?

As mentioned earlier, Blackberry feels a bit new in the documentation area and there are still a few bugs to take care of in the platform. Having said that, the platform is forward thinking, flexible and impressively powerful. Blackberry’s support has been beyond anything we could have hoped and even expected.

As more developers are drawn to the platform, documentation and community involvement will improve the access to information on the platform and increase the samples available to draw upon.

For such a new entrant into the market, our team is thoroughly impressed.

How was your experience working with the RIM team?

Bar-none, the best support we’ve ever had from a major platform vendor directly into the project. Kudos to RIM / Blackberry for providing such a spectacular community outreach.

When is Open Peer SDK going to be available for BlackBerry 10?

Our SDK is ready now in beta, developers can get it on Github today. We continue to polish this and our other toolkits, we expect commercialization to begin later this year. Follow us on github and twitter to get the latest news on Hookflash and Open Peer development.

I hope you found this interview informative and useful.  If you have any questions or feedback please leave a comment below or reach out to me directly on Twitter _GurtejSandhu. Kudos to Hookflash team for making this all happen.

In most cases when a carrier partnership agreement is achieved, the billing and/or authentication is done using the cell phone number of the BlackBerry smartphone.  Traditionally, this requirement meant that you’d call Phone.getDevicePhoneNumber(boolean format) to retrieve the user’s BlackBerry smartphone cell number.  However, if the user is using BlackBerry® Mobile Voice System (BlackBerry MVS), getDevicePhoneNumber() will not return their cell phone number, but instead will return the phone number used for BlackBerry MVS.  Uh-oh, did your app just create a support incident?  If you’ve been keeping up with platform features, the answer is no.

When a user is connected to BlackBerry MVS, the whole point is to use it as much as possible, thus getting its maximum benefit.  Thus, the user’s work number / the number associated with BlackBerry MVS now becomes the user’s default phone number – which is exactly what will be returned by getDevicePhoneNumber().  This new default phone number might cause a problem for the billing and/or authentication of your application through the carrier, since your application might be expecting the user’s cell number to be returned – not the BlackBerry MVS number.

So how do you handle this situation?

Option A: Make the user do it.

Since the user does have the ability to manually set which phone number to use, you could take a hard-nosed stance and make the user do all the work.  In order for the user to change this setting, they need to go into the Phone application, select “Options” from the menu, select “Work line,” then select “Line and Network Preferences,” and finally choose the right number using the drop down box labelled “Default line for outgoing calls.”  Save this change and you’re done.  With no change required to your app, getDevicePhoneNumber() now returns the cell number to you.  However, you’ve now just put a ton of onus on the user, reduced the effectiveness of BlackBerry MVS, and likely still generated a support call.

Option B: Take advantage of new platform features and use the new APIs.

Use the following API functionality added in BlackBerry Device Software 5.0:

int[] lineIds = Phone.getLineIds();
String phoneNumber = null;
for( int i=0; i < lineIds.length; i++ ) {
if(Phone.getLineType(lineIds[i]) == Phone.MOBILE_TYPE) {
//found the user’s cell number
phoneNumber = Phone.getLineNumber(lineIds[i]);
} else if Phone.getLineType(lineIds[i] == Phone.PBX_TYPE) {
//found the number used for BlackBerry MVS
}
}

With less than 10 lines of code, your app is more robust, BlackBerry MVS friendly, and can reliably provide the cell phone number to the carrier.  Personally, I like my carrier relationships, so I’ll go with option B.  But the choice is yours!

Have you tried out this tip? Let us know how it went in the comments!